restful api 权限设计 - sureness集成springboot样例-数据库计划

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

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

理解sureness提供的数据加载接口

首先咱们先来意识下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提供的默认配置,其新建了一个配置类,创立对应的sureness默认配置bean
sureness默认配置应用了文件数据源sureness.yml作为提供账户权限数据
默认配置反对了jwt, basic auth, digest auth认证

@Configurationpublic 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的个性。
这个自定义配置咱们将本来的默认文件数据源替换为了数据库数据源,配置如下:

@Configurationpublic 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/