这是我参与更文挑战的第5天，活动详情查看： 更文挑战
背景
目前前后端分离架构已经非常流行，后端专注于给前端提供REST API接口，对于接口的认证鉴权也非常重要。
目前市场上的主流权限框架有Shiro和Spring Security，但是他们都有瑕疵，比如Shiro不原生支持RESTful，Spring Security深度绑定了Spring，上手难度高。
而sureness框架解决了上述问题，提供一个面向REST API，无框架依赖，可以动态修改权限，多认证策略，更快速度，易用易扩展的认证鉴权框架。
来自sureness官网的各个权限框架的对比：
| ~ | Sureness | Shiro | Spring Security |
|---|---|---|---|
| 多框架支持 | 支持 | 需改动支持 | 不支持 |
| REST API | 支持 | 需改动支持 | 支持 |
| Websocket | 支持 | 不支持 | 不支持 |
| 过滤链匹配 | 优化的字典匹配树 | ant匹配 | ant匹配 |
| 注解支持 | 支持 | 支持 | 支持 |
| Servlet | 支持 | 支持 | 支持 |
| JAX-RS | 支持 | 不支持 | 不支持 |
| 权限动态修改 | 支持 | 需改动支持 | 需改动支持 |
| 性能速度 | 较快 | 较慢 | 较慢 |
| 学习曲线 | 简单 | 简单 | 陡峭 |
资源约定
所谓的资源，就是用户所能访问的最小粒度单位。
对于前后端分离的架构来说，后端给前端提供一系列API接口，这些API接口由资源名称+请求方法组成。
比如对于用户模块，/api/user的get请求意味获取用户，而/api/user的post请求则为创建用户，单独的url没法具体体现业务，必须结合动词。
所以sureness非常创新的把资源+动词（get,post,put,delete...）形成一个整体作为资源来鉴权。
比如上面的获取用户，按sureness的规则，可表示为/api/user===get，创建用户可表示为/api/user===post。
RBAC模型
RBAC基于角色的权限访问控制（Role-Based Access Control）是商业系统中最常见的权限管理技术之一。
在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限，这就极大地简化了权限的管理。
在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。
最经典的RBAC的数据库实现就是五表设计，即三张实体表（用户，角色，权限）加两张关系表（用户-角色，角色-权限，两者都是多对多关系）。
sureness的认证与授权
权限框架一般要解决两个问题：认证与授权。
认证的英文为Authentication，验证用户是不是拥有相应的身份。
授权的英文为Authorization，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限。
sureness框架支持一些简单登录认证方式，如basic auth，jwt等。授权功能也是利用了RBAC的思想来实现的。
如果想了解sureness的功能，可参见官方的手把手教程例子。
在这份教程里，没有过多的自定义功能，更多的是通过文件配置来对认证和授权进行了模拟。
这份配置文件是：
## -- sureness.yml文本数据源 -- ##
# 加载到匹配字典的资源,也就是需要被保护的,设置了所支持角色访问的资源
# 没有配置的资源也默认被认证保护,但不鉴权，例如/api/v1/source2===get
# eg: /api/v1/source1===get===[role2] 表示 /api/v1/source1===get 这条资源支持 role2这一种角色访问
# eg: /api/v2/source2===get===[] 表示 /api/v2/source2===get 这条资源不支持任何角色访问
resourceRole:
- /api/v1/source1===get===[role2]
- /api/v1/source1===delete===[role3]
- /api/v1/source1===put===[role1,role2]
- /api/v2/source2===get===[]
- /api/v1/source2/*/*===get===[role2]
- /api/v2/source3/*===get===[role2]
# 需要被过滤保护的资源,不认证鉴权直接访问
# /api/v1/source3===get 表示 /api/v1/source3===get 可以被任何人访问 无需登录认证鉴权
excludedResource:
- /api/v1/account/auth===post
- /api/v1/source3===get
- /**/*.html===get
- /**/*.js===get
- /**/*.css===get
- /**/*.ico===get
# 用户账户信息
# 下面有 admin root tom三个账户
# eg: admin 拥有[role1,role2]角色,明文密码为admin,加盐密码为0192023A7BBD73250516F069DF18B500
# eg: root 拥有[role1],密码为明文23456
# eg: tom 拥有[role3],密码为明文32113
account:
- appId: admin
# 如果填写了加密盐--salt,则credential为MD5(password+salt)的32位结果
# 没有盐认为不加密,credential为明文
# 若密码加盐 则digest认证不支持
credential: 0192023A7BBD73250516F069DF18B500
salt: 123
role: [role1,role2]
- appId: root
credential: 23456
role: [role1]
- appId: tom
credential: 32113
role: [role3]
除了配置文件，sureness也支持自定义数据源，把角色信息和资源信息全部持久化到数据库里。
另外，sureness也有非常多的扩展点，比如自定义用户对象，自定义认证方式等等，这些我会在后面的文章里继续介绍。
