Apache Shiro 基于权限授权

授权即是访问控制，是对资源访问的管理过程。它将判断用户在应用程序中是否对资源有相应的访问权限。

基于角色的访问控制

在谈到应用程序的安全性时，大家都熟悉一个概念：角色。角色代表了一组行为或责任，角色通常被分配给用户，然后通过关联代表用户可以‘做’各种归因于角色的事情。

但现在很多程序都使用隐式的角色进行访问控制，定义一个角色来代表一系列的操作。当需要对某一操作进行授权验证时，只需判断是否拥有该角色即可。

行为已被一个单独的名字所蕴含。这种角色权限相对简单、模糊，不利于扩展。

比如：定义一个角色“项目经理”，这只是一个普通的字符串名称，但它包含了一系列的行为（添加或删除员工到项目，生成项目报告等等）。这个角色所包含的含义根据项目来自己定义，你可能并不清楚这个角色究竟代表什么含义。当需要判断时一般开发人员都要这么写：

if (user.hasRole("项目经理") ) {
//显示项目报告按钮
} else {
//不显示按钮
}

当安全策略发生变更时，这种授权方式非常脆弱。比如，需要新增一个角色“部门经理”也能查看项目报告的话，开发人员就需要修改代码：

if (user.hasRole("项目经理") || user.hasRole("部门经理") ) {
//显示项目报告按钮
} else {
//不显示按钮
}

这种方式无法支持程序在运行时动态地创建或删除角色。

基于资源的访问控制

访问控制的本质是保护哪些资源以及检查用户对这些资源是否具有相应的行为，当你把它分解到这个最原始的水平时候，你就可以将安全策略描述在一个更细粒度的和更加弹性的方式。

修改一下上面的代码：

if (user.isPermitted("项目报告:查看:12345")) {
//显示项目报告按钮
} else {
//不显示按钮
}

项目报告是资源，查看是行为，12345是项目报告的ID（即资源的属性）。这种实现方式显式地表明了资源与行为之间的关系，并能明确地定义特定资源实例的操作行为实现了实例级的访问控制。这样代码在做安全性检查时不需要知道行为是如何关联的，并可以在程序运行过程中依据安全策略改变这些关联。

Wildcard Permissions

在Shiro中如果你想检查一个Subject 是否被允许做某事，你可以调用各种isPermitted*方法。检查权限主要有两个方式——基于对象的权限实例或代表权限的字符串。

例如：

subject.isPermitted("queryPrinter")
subject.isPermitted( new WildcardPermission("queryPrinter"))

权限分为三个部分：资源，行为和资源属性。三部分之间用冒号分隔，各子部分又可以用逗号分隔，支持星号作为通配符。
示例：

printer:query
printer:query:lp7200
printer:print,query
printer:query,print:lp7200
printer:print:*
printer:*:*
printer:*

printer:print 等于 printer:print:*
printer 等于 printer:*:*
printer:lp7200 不等于 printer:*:lp7200

判断权限是在org.apache.shiro.authz.permission.WildcardPermission类的implies方法中实现的，支持了通配符规则。

关联角色与权限

对于习惯了基于角色的访问控制方式，你也可以直接给角色分配权限。可以定义一个显式角色，一个显式角色本质上是一个授权声明的命名集合。
授权验证时，需要判断当前角色是否拥有该权限。这种角色权限可以对该角色进行详细的权限描述，适合更复杂的权限设计。