sureness - 一个面向restful api保护的权限认证

sureness - 面向restful api的权限认证

仓库地址

Background

目前 java主流的权限框架有 shiro，spring security
下面对于它们的探讨都是我的浅薄之见，接受纠正
shiro对于 restful api原生支持不是太友好,须要改写一些代码,2年前一个项目就是改造 shiro,使其在过滤链就能匹配不一样的 rest请求进行权限校验,项目传送门 booshiro,以后给 shiro commit几回 pr, fix其在过滤链匹配时的危险漏洞, PR传送门 SHIRO-682,总的来讲 shiro很强大但其起源并不是面向 web,对 restful不是很友好
spring security很强大,与 spring深度集成,离开 spring,好比 google的精简 guice,以前用过的 osgi框架 karaf就用不了了
它们都会在链式匹配这块，用请求的url和配置的链一个一个 ant匹配(匹配过程当中会有缓存等提升性能)，但匹配的链过多时仍是比较耗性能
因此想写一个权限包吸收上面的优秀设计,加一些本身的想法

Introduction

sureness 是做者在使用 java权限框架 shiro以后,吸收其良好的设计加上一些本身想法实现的全新认证鉴权项目
面对 restful api的认证鉴权,基于 RABC主要关注于对 restful api的保护
原生支持 restful api, websocket protection
原生支持动态权限(权限配置的动态加载)
原生支持 jwt, Basic Auth ... 可扩展自定义支持的认证方式
基于改进的字典匹配树大大提升性能

sureness的低配置，易扩展，不耦合其余框架，能使开发者对本身的项目多场景快速安全的进行保护

仓库的组成部分:

• sureness的核心代码--sureness-core
• 使用sureness10分钟搭建权限项目--sample-bootstrap
• 使用sureness30分钟搭建权限项目--sample-tom

一些约定

• 基于RABC,但只有(角色-资源)的映射,没有(权限)动做
• 咱们将restful api请求视做一个资源,资源格式为: requestUri===httpMethod
  即请求的路径加上其请求方式(post,get,put,delete...)做为一个总体被视做一个资源
  eg: /api/v2/book===get get方式请求/api/v2/book接口数据
• 用户所属角色--角色拥有资源--用户拥有资源(用户就能访问此api)

使用

maven坐标

<!-- https://mvnrepository.com/artifact/com.usthe.sureness/sureness-core -->
<dependency>
    <groupId>com.usthe.sureness</groupId>
    <artifactId>sureness-core</artifactId>
    <version>0.0.2.3</version>
</dependency>

gradle坐标

compile group: 'com.usthe.sureness', name: 'sureness-core', version: '0.0.2.3'

入口,通常放在拦截全部请求的filter:

SurenessSecurityManager.getInstance().checkIn(servletRequest)

认证鉴权成功直接经过,失败抛出特定异常,捕获异常:

try {
            SubjectSum subject = SurenessSecurityManager.getInstance().checkIn(servletRequest);
        } catch (ProcessorNotFoundException | UnknownAccountException | UnsupportedSubjectException e4) {
            // 帐户建立相关异常 
        } catch (DisabledAccountException | ExcessiveAttemptsException e2 ) {
            // 帐户禁用相关异常
        } catch (IncorrectCredentialsException | ExpiredCredentialsException e3) {
            // 认证失败相关异常
        } catch (UnauthorizedException e5) {
            // 鉴权失败相关异常
        } catch (RuntimeException e) {
            // 其余自定义异常
        }

sureness异常	异常描述
SurenessAuthenticationException	基础认证异常,认证相关的子异常应该继承此异常
SurenessAuthorizationException	基础鉴权异常,鉴权相关的子异常应该继承此异常
ProcessorNotFoundException	认证异常,未找到支持此subject的processor
UnknownAccountException	认证异常,不存在此帐户
UnSupportedSubjectException	认证异常,不支持的请求,未建立出subject
DisabledAccountException	认证异常,帐户禁用
ExcessiveAttemptsException	认证异常,帐户尝试认证次数过多
IncorrectCredentialsException	认证异常,密钥错误
ExpiredCredentialsException	认证异常,密钥认证过时
UnauthorizedException	鉴权异常,没有权限访问此资源

自定义异常须要继承SurenessAuthenticationException或SurenessAuthorizationException才能被最外层捕获

若权限配置数据来自文本,请参考使用sureness10分钟搭建权限项目--sample-bootstrap

若权限配置数据来自数据库,请参考使用sureness30分钟搭建权限项目--sample-tom

HAVE FUN

进阶扩展

若是了解 处理流程,就大概知道sureness提供的扩展点
sureness支持自定义subject，自定义subjectCreator注册，自定义processor处理器等

扩展以前须要了解如下接口:

• Subject: 认证鉴权对象接口,提供访问对象的帐户密钥,请求资源,角色等信息
• SubjectCreate: 建立Subject接口,根据请求内容建立不一样类型的Subject对象
• Processor: Subject处理接口,根据Subject信息,进行认证鉴权
• PathTreeProvider: 资源的数据源接口,实现从数据库,文本等加载数据
• SurenessAccountProvider: 用户的帐户密钥信息接口,实现从数据库,文本等加载数据

sureness大体流程:

graph TD
A(用户请求体进来) --> B(s)
B(subjectCreate根据请求头内容建立不一样的钥匙subject,每把钥匙均可以尝试) --> C(s)
C(不一样的钥匙认证方式即不一样的锁processor来处理进来的钥匙subject) --> D(s)
D(以上一次成功即成功并结束,失败即下一个钥匙锁尝试直到全部尝试结束)

1. 自定义数据源

实现 PathTreeProvider的接口, 加载到DefaultPathRoleMatcher中
实现 SurenessAccountProvider的接口,加载到须要的processor中

1. 自定义subject

实现Subject接口,添加自定义的subject内容
实现SubjectCreate接口方法,建立出自定义的subject
实现Processor接口,支持处理自定义的subject

1. 自定义processor

一个subject固然也能够被不一样的processor处理,因此能够单独自定义processor
实现Processor接口,设置支持的subject,实现处理该subject的逻辑

具体扩展实践请参考 使用sureness30分钟搭建权限项目--sample-tom

高性能匹配

处理流程

转载请注明 from tomsun28