Shiro基础知识——授权

上一篇博文总结了一下Shiro中的身份认证，本文主要来总结一下Shiro中的权限认证（Authorization）功能，即授权。如下： 
 

授权

授权，也叫访问控制，即在应用中控制谁能访问哪些资源（如访问页面/编辑数据/页面操作等）。在授权中需了解的几个关键对象：主体（Subject）、资源（Resource）、权限（Permission）、角色（Role）。

主体
主体，即访问应用的用户，在 Shiro 中使用 Subject 代表该用户。用户只有授权后才允许访问相应的资源。

资源
在应用中用户可以访问的任何东西，比如访问 JSP 页面、查看/编辑某些数据、访问某个业务方法、打印文本等等都是资源。用户只要授权后才能访问。

权限
安全策略中的原子授权单位，通过权限我们可以表示在应用中用户有没有操作某个资源的权力。即权限表示在应用中用户能不能访问某个资源，如： 访问用户列表页面
查看/新增/修改/删除用户数据（即很多时候都是 CRUD（增查改删）式权限控制）
打印文档等等。。。

如上可以看出，权限代表了用户有没有操作某个资源的权利，即反映在某个资源上的操作允不允许，不反映谁去执行这个操作。所以后续还需要把权限赋予给用户，即定义哪个用户允许在某个资源上做什么操作（权限），Shiro 不会去做这件事情，而是由实现人员提供。

Shiro 支持粗粒度权限（如用户模块的所有权限）和细粒度权限（操作某个用户的权限，即实例级别的），后续部分介绍。

角色
角色代表了操作集合，可以理解为权限的集合，一般情况下我们会赋予用户角色而不是权限，即这样用户可以拥有一组权限，赋予权限时比较方便。典型的如：项目经理、技术总监、CTO、开发工程师等都是角色，不同的角色拥有一组不同的权限。

隐式角色：
即直接通过角色来验证用户有没有操作权限，如在应用中 CTO、技术总监、开发工程师可以使用打印机，假设某天不允许开发工程师使用打印机，此时需要从应用中删除相应代码；再如在应用中 CTO、技术总监可以查看用户、查看权限；突然有一天不允许技术总监查看用户、查看权限了，需要在相关代码中把技术总监角色从判断逻辑中删除掉；即粒度是以角色为单位进行访问控制的，粒度较粗；如果进行修改可能造成多处代码修改。

显示角色：
在程序中通过权限控制谁能访问某个资源，角色聚合一组权限集合；这样假设哪个角色不能访问某个资源，只需要从角色代表的权限集合中移除即可；无须修改多处代码；即粒度是以资源/实例为单位的；粒度较细。

请 google 搜索“RBAC”和“RBAC新解”分别了解“基于角色的访问控制”“基于资源的访问控制(Resource-Based Access Control)”。

授权流程

流程如下：

1. 首先调用 Subject.isPermitted*/hasRole*接口，其会委托给 SecurityManager，而 SecurityManager 接着会委托给 Authorizer；
2. Authorizer 是真正的授权者，如果我们调用如 isPermitted(“user:view”)，其首先会通过 PermissionResolver 把字符串转换成相应的 Permission 实例；
3. 在进行授权之前，其会调用相应的 Realm 获取 Subject 相应的角色/权限用于匹配传入的角色/权限；
4. Authorizer 会判断 Realm 的角色/权限是否和传入的匹配，如果有多个 Realm，会委托给 ModularRealmAuthorizer 进行循环判断，如果匹配如 isPermitted*/hasRole* 会返回 true，否则返回 false 表示授权失败。

ModularRealmAuthorizer 进行多 Realm 匹配流程：

• 首先检查相应的 Realm 是否实现了实现了 Authorizer；
• 如果实现了 Authorizer，那么接着调用其相应的 isPermitted*/hasRole* 接口进行匹配；
• 如果有一个 Realm 匹配那么将返回 true，否则返回 false。

如果 Realm 进行授权的话，应该继承 AuthorizingRealm，其流程是：

• 如果调用 hasRole*，则直接获取 AuthorizationInfo.getRoles() 与传入的角色比较即可；首先如果调用如 isPermitted(“user:view”)，首先通过 PermissionResolver 将权限字符串转换成相应的 Permission 实例，默认使用 WildcardPermissionResolver，即转换为通配符的 WildcardPermission；
• 通过 AuthorizationInfo.getObjectPermissions() 得到 Permission 实例集合；通过 AuthorizationInfo.getStringPermissions() 得到字符串集合并通过 PermissionResolver 解析为 Permission 实例；然后获取用户的角色，并通过 RolePermissionResolver 解析角色对应的权限集合（默认没有实现，可以自己提供）；
• 接着调用 Permission.implies(Permission p) 逐个与传入的权限比较，如果有匹配的则返回 true，否则 false。

Authorizer、PermissionResolver及RolePermissionResolver

Authorizer 的职责是进行授权（访问控制），是 Shiro API 中授权核心的入口点，其提供了相应的角色/权限判断接口，具体请参考其 Javadoc。SecurityManager 继承了 Authorizer 接口，且提供了 ModularRealmAuthorizer 用于多 Realm 时的授权匹配。PermissionResolver 用于解析权限字符串到 Permission 实例，而 RolePermissionResolver 用于根据角色解析相应的权限集合。

基于角色的访问控制

　　也就是说，授权过程是通过判断角色来完成的，哪个角色可以做这件事，哪些角色可以做这件事等等。它有如下API：

方法	作用
hasRole(String roleName)	判断是否有该角色访问权，返回boolen
hasRoles(List<String> roleNames)	判断是否有这些这些角色访问权，返回boolean[]
hasAllRoles(Collection<String> roleNames)	判断是否有这些这些角色访问权，返回boolean

　　对这三个API，做一下简单的说明，第一个很简单，传入一个role即可，判断是否拥有该角色访问权，第二个方法是传入一个role的集合，然后Shiro会根据集合中的每一个role做一下判断，并且将每次的判断结果放到boolean[]数组中，顺序与集合中role的顺序一致；第三个方法也是传入一个role的集合，不同的是，返回boolean类型，必须集合中全部role都有才为true，否则为false。 

        除了这三个API外，Shiro还提供了check的API，与上面不同的是，has-xxx会返回boolean类型的数据，用来判断，而check-xxx不会返回任何东西，如果验证成功就继续处理下面的代码，否则会抛出一个异常，可以用来通过捕获异常来处理。API如下：

方法	作用
checkRole(String roleName)	如果判断失败抛出AuthorizationException异常
checkRoles(String... roleNames)	如果判断失败抛出AuthorizationException异常
checkRoles(Collection<String> roleNames)	如果判断失败抛出AuthorizationException异常

基于权限的访问控制

　　基于权限的访问控制和基于角色的访问控制在原理上是一模一样的，只不过API不同而已，我不再做过多的解释，API如下：

方法	作用
isPermitted(String perm)	判断是否有该权限，返回boolen
isPermitted(List<String> perms)	判断是否有这些这些权限，返回boolean[]
isPermittedAll(Collection<String> perms)	判断是否有这些这些权限，返回boolean
checkPermission(String perm)	如果判断失败抛出AuthorizationException异常
checkPermissions(String... perms)	如果判断失败抛出AuthorizationException异常
checkPermissionsAll(Collection<String> perms)	如果判断失败抛出AuthorizationException异常