关于java:restful-api-权限设计-sureness集成springboot样例数据库方案

6次阅读

共计 5996 个字符，预计需要花费 15 分钟才能阅读完成。

在之前的文章 restful api 权限设计 – 疾速搭建权限我的项目中，咱们具体一步一步模式的形容了从零开始应用 sureness 集成 springboot 搭建一个领有残缺认证鉴权性能的权限我的项目后盾，这个疾速搭建的后盾是基于配置文件的，也就是说并没有走数据库，用户信息和资源信息和对应的权限信息都写在了配置文件中。然而在惯例的企业应用后盾中，这些数据信息都是存在数据库中，明天咱们就来详细描述下应用数据库作为数据源来集成 sureness，springboot 搭建一个企业级的残缺性能的认证鉴权后盾我的项目。

对 surenss 来说，无论是配置文件计划还是数据库计划，其都是替换了不同的数据源而已，咱们齐全能够在之前搭建好的基于配置文件的我的项目进行批改替换，替换成数据库作为数据源。

首先咱们先来意识下 sureness 提供的两个用户信息和资源权限信息的接口，用户能够实现这些接口自定义从不同的数据源给 sureness 提供数据。当咱们把我的项目从配置文件模式切换成数据库模式时，也只是简略的替换了这些接口的实现类而已。

一. PathTreeProvider 资源权限配置信息的数据源接口, 咱们能够实现从数据库, 文本等加载接口想要的资源权限配置数据

public interface PathTreeProvider {Set<String> providePathData();

    Set<String> provideExcludedResource();}

此接口次要是须要实现下面这两个办法，providePathData 是加载资源权限配置信息，也就是咱们配置文件模式下 sureness.yml 的 resourceRole 信息列，provideExcludedResource 是加载哪些资源能够被过滤不认证鉴权，也就是 sureness.yml 下的 excludedResource 信息列，如下。

resourceRole:
  - /api/v2/host===post===[role2,role3,role4]
  - /api/v2/host===get===[role2,role3,role4]
  - /api/v2/host===delete===[role2,role3,role4]
  - /api/v2/host===put===[role2,role3,role4]
  - /api/mi/**===put===[role2,role3,role4]
  - /api/v1/getSource1===get===[role1,role2]
  - /api/v2/getSource2/*/*===get===[role2]

excludedResource:
  - /api/v1/source3===get
  - /api/v3/host===get
  - /**/*.css===get
  - /**/*.ico===get
  - /**/*.png===get

而当咱们应用数据库模式时，实现这些信息从数据库关联读取就 ok 了，标准返回 eg: /api/v2/host===post===[role2,role3,role4] 格局的数据列，具体的数据库实现类参考类 – DatabasePathTreeProvider

二. SurenessAccountProvider这第二个相干的接口就是用户的账户密钥信息提供接口, 咱们须要实现从数据库或者文本等其余数据源那里去加载咱们想要的用户的账户信息数据，这些数据提供给 sureness 让他进行用户的认证。

public interface SurenessAccountProvider {SurenessAccount loadAccount(String appId);
}

此接口次要须要实现下面这个 loadAccount 办法，通过用户的惟一标识 appid 来从数据库或者 redis 缓存中查找到用户的账户信息返回即可。用户账户信息类 SurenessAccount 如下：

public class DefaultAccount implements SurenessAccount {

    private String appId;
    private String password;
    private String salt;
    private List<String> ownRoles;
    private boolean disabledAccount;
    private boolean excessiveAttempts;
}

比较简单，次要是须要提供用户的明码相干信息即可，供 sureness 认证时密钥判断正确与否。
这个具体的数据库接口实现可参考类 – DatabaseAccountProvider

在之前的简略样例中，咱们应用的是 sureness 提供的默认配置，其新建了一个配置类，创立对应的 sureness 默认配置 bean
sureness 默认配置应用了文件数据源 sureness.yml 作为提供账户权限数据
默认配置反对了 jwt, basic auth, digest auth 认证

@Configuration
public class SurenessConfiguration {

    /**
     * sureness default config bean
     * @return default config bean
     */
    @Bean
    public DefaultSurenessConfig surenessConfig() {return new DefaultSurenessConfig();
    }

}

自定义配置 sureness 之前咱们再来理解下 sureness 的大抵流程，这样让咱们更容易了解之后的自定义 sureness 配置。流程如下：

如下面的流程所讲，Subject 被 SubjectCreate 依据申请体所发明，不同的认证鉴权处理器 Processor 来进去所反对的 Subject
而后这里咱们就来不应用默认配置，应用自定义配置来配置 sureness 的个性。
这个自定义配置咱们将本来的默认文件数据源替换为了数据库数据源，配置如下：

@Configuration
public class SurenessConfiguration {

    @Bean
    ProcessorManager processorManager(SurenessAccountProvider accountProvider) {
        // 处理器 Processor 初始化
        List<Processor> processorList = new LinkedList<>();
        // 应用了默认的反对 NoneSubject 的处理器 NoneProcessor 
        NoneProcessor noneProcessor = new NoneProcessor();
        processorList.add(noneProcessor);
        // 应用了默认的反对 JwtSubject 的处理器 JwtProcessor  
        JwtProcessor jwtProcessor = new JwtProcessor();
        processorList.add(jwtProcessor);
        // 应用了默认的反对 PasswordSubject 的处理器 PasswordProcessor  
        PasswordProcessor passwordProcessor = new PasswordProcessor();
        // 这里留神，PasswordProcessor 须要对用户账户明码验证，所以其须要账户信息提供者来给他提供想要的账户数据，// 这里的 SurenessAccountProvider accountProvider bean 就是这个账户数据提供源，// 其实现 bean 是下面讲到的 DatabaseAccountProvider bean, 即数据库实现的账户数据提供者。passwordProcessor.setAccountProvider(accountProvider);
        processorList.add(passwordProcessor);
        return new DefaultProcessorManager(processorList);
    }

    @Bean
    TreePathRoleMatcher pathRoleMatcher(PathTreeProvider databasePathTreeProvider) {
        // 这里的 PathTreeProvider databasePathTreeProvider 就是通过数据库来提供资源权限配置信息 bean 实例
        // 上面咱们再实例化一个通过文件 sureness.yml 提供资源权限配置信息的提供者
        PathTreeProvider documentPathTreeProvider = new DocumentPathTreeProvider();
        // 上面咱们再实例化一个通过注解模式 @RequiresRoles @WithoutAuth 提供资源权限配置信息的提供者
        AnnotationPathTreeProvider annotationPathTreeProvider = new AnnotationPathTreeProvider();
        // 设置注解扫描包门路，也就是你提供 api 的 controller 门路 annotationPathTreeProvider.setScanPackages(Collections.singletonList("com.usthe.sureness.sample.tom.controller"));
        // 开始初始化资源权限匹配器，咱们能够把下面三种提供者都退出到匹配器中为其提供资源权限数据，匹配器中的数据就是这三个提供者提供的数据汇合。t
        DefaultPathRoleMatcher pathRoleMatcher = new DefaultPathRoleMatcher();
        pathRoleMatcher.setPathTreeProviderList(Arrays.asList(
                documentPathTreeProvider,
                annotationPathTreeProvider,
                databasePathTreeProvider));
        // 应用资源权限配置数据来建设对应的匹配树
        pathRoleMatcher.buildTree();
        return pathRoleMatcher;
    }

    @Bean
    SubjectFactory subjectFactory() {
        // 咱们之前晓得了能够有各种 Processor 来解决对应的 Jwt，那这 Subject 怎么失去呢，就须要不同的 SubjectCreator 来依据申请信息创立对应的 Subject 对象供之后的流程应用
        SubjectFactory subjectFactory = new SurenessSubjectFactory();
        // 这里咱们注册咱们须要的 SubjectCreator
        subjectFactory.registerSubjectCreator(Arrays.asList(
                // 留神! 强制必须首先增加一个 noSubjectCreator
                new NoneSubjectServletCreator(),
                // 注册用来创立 PasswordSubject 的 creator
                new BasicSubjectServletCreator(),
                // 注册用来创立 JwtSubject 的 creator
                new JwtSubjectServletCreator(),
                // 当然你能够本人实现一个自定义的 creator，实现 SubjectCreate 接口即可
                new CustomPasswdSubjectCreator()));
        return subjectFactory;
    }

    @Bean
    SurenessSecurityManager securityManager(ProcessorManager processorManager,
                                            TreePathRoleMatcher pathRoleMatcher, SubjectFactory subjectFactory) {
        // 咱们把下面初始化好的配置 bean 整合到一起初始化 surenessSecurityManager 
        SurenessSecurityManager securityManager = SurenessSecurityManager.getInstance();
        // 设置资源权限匹配者
        securityManager.setPathRoleMatcher(pathRoleMatcher);
        // 设置 subject 创立工厂
        securityManager.setSubjectFactory(subjectFactory);
        // 设置处理器 processor 管理者
        securityManager.setProcessorManager(processorManager);
        return securityManager;
    }

}

这下面的 SurenessConfiguration 配置具体的阐明了每个配置的用处，咱们这里再来总结一下。
SubjectCreator 创立 Subject，Processor 来解决对应的 Subject。

processorManager 办法就是提供咱们配置反对的 processor，每个 processor 须要的依赖不一样，比方 PasswordProcessor 须要对用户的账户明码信息做比照认证，所以其须要注入账户信息提供者来给他提供想要的账户数据，下面咱们就注入了数据库形式账户信息提供者。

pathRoleMatcher 办法就是提供资源门路和对应所反对角色的匹配器，此匹配器当然也须要对应的资源权限数据来撑持，所以下面咱们提供了三种资源权限数据提供者(数据库，文件，注解模式)，将其提供的配置数据都塞入到匹配器中应用。

subjectFactory 办法就是 subject 工厂，咱们须要注册不同类型的 subject 创立形式 - 即 SubjectCreator 到工厂中，供不同的申请创立对应的 Subject 来应用

securityManager 办法就是将下面的所有配置整合到一个管理器中。

这个具体的配置案例能够参考类 SurenessConfiguration

下面介绍了通过替换文件数据源为数据库数据源，来实现认证鉴权我的项目。然而数据库的表结构设计，怎么通过设计好的表数据关联提供出 sureness 想要的数据提供接口格局。这个能够参考 sureness 集成 springboot 样例(数据库计划) 外面提供了一个残缺的数据库样例实现和对应的表设计和数据。

更多自定义请拜访 sureness 官方网站文档：https://su.usthe.com/

正文完