让Apache Shiro保护你的应用
本帖最后由 jeesite 于 2017-1-20 22:40 编辑http://www.infoq.com/cn/articles/apache-shiro
核心概念：Subject，SecurityManager和Realms既然已经描述了Shiro的好处，那就让我们看看它的API，好让你能够有个感性认识。Shiro架构有三个主要概念 - Subject，SecurityManager和Realms。Subject在考虑应用安全时，你最常问的问题可能是“当前用户是谁？”或“当前用户允许做X吗？”。当我们写代码或设计用户界面时，问自己这些问题很平常：应用通常都是基于用户故事构建的，并且你希望功能描述（和安全）是基于每个用户的。所以，对于我们而言，考虑应用安全的最自然方式就是基于当前用户。Shiro的API用它的Subject概念从根本上体现了这种思考方式。Subject一词是一个安全术语，其基本意思是“当前的操作用户”。称之为“用户”并不准确，因为“用户”一词通常跟人相关。在安全领域，术语“Subject”可以是人，也可以是第三方进程、后台帐户（Daemon Account）或其他类似事物。它仅仅意味着“当前跟软件交互的东西”。但考虑到大多数目的和用途，你可以把它认为是Shiro的“用户”概念。在代码的任何地方，你都能轻易的获得Shiro Subject，参见如下代码：清单1. 获得Subject
import org.apache.shiro.subject.Subject;
import org.apache.shiro.SecurityUtils;
...
Subject currentUser = SecurityUtils.getSubject();
一旦获得Subject，你就可以立即获得你希望用Shiro为当前用户做的90%的事情，如登录、登出、访问会话、执行授权检查等 - 稍后还会看到更多。这里的关键点是Shiro的API非常直观，因为它反映了开发者以‘每个用户’思考安全控制的自然趋势。同时，在代码的任何地方都能很轻松地访问Subject，允许在任何需要的地方进行安全操作。SecurityManagerSubject的“幕后”推手是SecurityManager。Subject代表了当前用户的安全操作，SecurityManager则管理所有用户的安全操作。它是Shiro框架的核心，充当“保护伞”，引用了多个内部嵌套安全组件，它们形成了对象图。但是，一旦SecurityManager及其内部对象图配置好，它就会退居幕后，应用开发人员几乎把他们的所有时间都花在Subject API调用上。那么，如何设置SecurityManager呢？嗯，这要看应用的环境。例如，Web应用通常会在Web.xml中指定一个Shiro Servlet Filter，这会创建SecurityManager实例，如果你运行的是一个独立应用，你需要用其他配置方式，但有很多配置选项。一个应用几乎总是只有一个SecurityManager实例。它实际是应用的Singleton（尽管不必是一个静态Singleton）。跟Shiro里的几乎所有组件一样，SecurityManager的缺省实现是POJO，而且可用POJO兼容的任何配置机制进行配置 - 普通的Java代码、Spring XML、YAML、.properties和.ini文件等。基本来讲，能够实例化类和调用JavaBean兼容方法的任何配置形式都可使用。为此，Shiro借助基于文本的INI配置提供了一个缺省的“公共”解决方案。INI易于阅读、使用简单并且需要极少依赖。你还能看到，只要简单地理解对象导航，INI可被有效地用于配置像SecurityManager那样简单的对象图。注意，Shiro还支持Spring XML配置及其他方式，但这里只我们只讨论INI。下列清单2列出了基于INI的Shiro最简配置：清单2. 用INI配置Shiro
cm = org.apache.shiro.authc.credential.HashedCredentialsMatcher
cm.hashAlgorithm = SHA-512
cm.hashIterations = 1024
# Base64 encoding (less text):
cm.storedCredentialsHexEncoded = false
iniRealm.credentialsMatcher = $cm
jdoe = TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJpcyByZWFzb2
asmith = IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbXNoZWQsIG5vdCB
在清单2中，我们看到了用于配置SecurityManager实例的INI配置例子。有两个INI段落：和.段落是配置SecurityManager对象及其使用的其他任何对象（如Realms）的地方。在示例中，我们看到配置了两个对象：
[*]cm对象，是Shiro的HashedCredentialsMatcher类实例。如你所见，cm实例的各属性是通过“嵌套点”语法进行配置的 - 在清单3中可以看到IniSecurityManagerFactory使用的惯例，这种方法代表了对象图导航和属性设置。
[*]iniRealm对象，它被SecurityManager用来表示以INI格式定义的用户帐户。
段落是指定用户帐户静态列表的地方 - 为简单应用或测试提供了方便。就介绍而言，详细了解每个段落的细节并不是重点。相反，看到INI配置是一种配置Shiro的简单方式才是关键。关于INI配置的更多细节，请参见Shiro文档。清单3. 装入shiro.ini配置文件
import org.apache.shiro.SecurityUtils;
import org.apache.shiro.config.IniSecurityManagerFactory;
import org.apache.shiro.mgt.SecurityManager;
import org.apache.shiro.util.Factory;
...
//1.装入INI配置
Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
//2. 创建SecurityManager
SecurityManager securityManager = factory.getInstance();
//3. 使其可访问
SecurityUtils.setSecurityManager(securityManager);
在清单3的示例中，我们看到有三步：
[*]装入用来配置SecurityManager及其构成组件的INI配置文件；
[*]根据配置创建SecurityManager实例（使用Shiro的工厂概念，它表述了工厂方法设计模式）；
[*]使应用可访问SecurityManager Singleton。在这个简单示例中，我们将它设置为VM静态Singleton，但这通常不是必须的 - 你的应用配置机制可以决定你是否需要使用静态存储。
RealmsShiro的第三个也是最后一个概念是Realm。Realm充当了Shiro与应用安全数据间的“桥梁”或者“连接器”。也就是说，当切实与像用户帐户这类安全相关数据进行交互，执行认证（登录）和授权（访问控制）时，Shiro会从应用配置的Realm中查找很多内容。从这个意义上讲，Realm实质上是一个安全相关的DAO：它封装了数据源的连接细节，并在需要时将相关数据提供给Shiro。当配置Shiro时，你必须至少指定一个Realm，用于认证和（或）授权。配置多个Realm是可以的，但是至少需要一个。Shiro内置了可以连接大量安全数据源（又名目录）的Realm，如LDAP、关系数据库（JDBC）、类似INI的文本配置资源以及属性文件等。如果缺省的Realm不能满足需求，你还可以插入代表自定义数据源的自己的Realm实现。下面的清单4是通过INI配置Shiro使用LDAP目录作为应用Realm的示例。清单4. Realm配置示例片段：连接存储用户数据的LDAP
ldapRealm = org.apache.shiro.realm.ldap.JndiLdapRealm
ldapRealm.userDnTemplate = uid={0},ou=users,dc=mycompany,dc=com
ldapRealm.contextFactory.url = ldap://ldapHost:389
ldapRealm.contextFactory.authenticationMechanism = DIGEST-MD5
既然已经了解如何建立一个基本的Shiro环境，下面让我们来讨论，作为一名开发者该如何使用这个框架。认证认证是核实用户身份的过程。也就是说，当用户使用应用进行认证时，他们就在证明他们就是自己所说的那个人。有时这也理解为“登录”。它是一个典型的三步骤过程。
[*]收集用户的身份信息，称为当事人（principal），以及身份的支持证明，称为证书（Credential）。
[*]将当事人和证书提交给系统。
[*]如果提交的证书与系统期望的该用户身份（当事人）匹配，该用户就被认为是经过认证的，反之则被认为未经认证的。
这个过程的常见例子是大家都熟悉的“用户/密码”组合。多数用户在登录软件系统时，通常提供自己的用户名（当事人）和支持他们的密码（证书）。如果存储在系统中的密码（或密码表示）与用户提供的匹配，他们就被认为通过认证。Shiro以简单直观的方式支持同样的流程。正如我们前面所说，Shiro有一个以Subject为中心的API - 几乎你想要用Shiro在运行时完成的所有事情都能通过与当前执行的Subject进行交互而达成。因此，要登录Subject，只需要简单地调用它的login方法，传入表示被提交当事人和证书（在这种情况下，就是用户名和密码）的AuthenticationToken实例。示例如清单5中所示：清单5. Subject登录
//1. 接受提交的当事人和证书：
AuthenticationToken token =
new UsernamePasswordToken(username, password);
//2. 获取当前Subject：
Subject currentUser = SecurityUtils.getSubject();
//3. 登录：
currentUser.login(token);
你可以看到，Shiro的API很容易地就反映了这个常见流程。你将会在所有的Subject操作中继续看到这种简单风格。在调用了login方法后，SecurityManager会收到AuthenticationToken，并将其发送给已配置的Realm，执行必须的认证检查。每个Realm都能在必要时对提交的AuthenticationTokens作出反应。但是如果登录失败了会发生什么？如果用户提供了错误密码又会发生什么？通过对Shiro的运行时AuthenticationException做出反应，你可以控制失败，参见清单6。清单6. 控制失败的登录
//3. 登录：
try {
currentUser.login(token);
} catch (IncorrectCredentialsException ice) {
…
} catch (LockedAccountException lae) {
…
}
…
catch (AuthenticationException ae) {…
}
你可以选择捕获AuthenticationException的一个子类，作出特定的响应，或者对任何AuthenticationException做一般性处理（例如，显示给用户普通的“错误的用户名或密码”这类消息）。选择权在你，可以根据应用需要做出选择。Subject登录成功后，他们就被认为是已认证的，通常你会允许他们使用你的应用。但是仅仅证明了一个用户的身份并不意味着他们可以对你的应用为所欲为。这就引出了另一个问题，“我如何控制用户能做或不能做哪些事情？”，决定用户允许做哪些事情的过程被称为授权。下面我们将谈谈Shiro如何进行授权。
授权授权实质上就是访问控制 - 控制用户能够访问应用中的哪些内容，比如资源、Web页面等等。多数用户执行访问控制是通过使用诸如角色和权限这类概念完成的。也就是说，通常用户允许或不允许做的事情是根据分配给他们的角色或权限决定的。那么，通过检查这些角色和权限，你的应用程序就可以控制哪些功能是可以暴露的。如你期望的，Subject API让你可以很容易的执行角色和权限检查。如清单7中的代码片段所示：如何检查Subject被分配了某个角色：列表7. 角色检查if ( subject.hasRole(“administrator”) ) {
//显示‘Create User’按钮
} else {
//按钮置灰?
} 如你所见，你的应用程序可基于访问控制检查打开或关闭某些功能。权限检查是执行授权的另一种方法。上例中的角色检查有个很大的缺陷：你无法在运行时增删角色。角色名字在这里是硬编码，所以，如果你修改了角色名字或配置，你的代码就会乱套！如果你需要在运行时改变角色含义，或想要增删角色，你必须另辟蹊径。为此，Shiro支持了权限（permissions）概念。权限是功能的原始表述，如‘开门’，‘创建一个博文’，‘删除‘jsmith’用户’等。通过让权限反映应用的原始功能，在改变应用功能时，你只需要改变权限检查。进而，你可以在运行时按需将权限分配给角色或用户。如清单8中，我们重写了之前的用户检查，取而代之使用权限检查。清单8. 权限检查if ( subject.isPermitted(“user:create”) ) {
//显示‘Create User’按钮
} else {
//按钮置灰?
} 该例表明，你可以对你需要的单个资源进行访问控制，甚至深入到非常细粒度的实例级别。如果愿意，你甚至还可以发明自己的权限语法。参见Shiro Permission文档可以了解更多内容。最后，就像使用认证那样，上述调用最终会转向SecurityManager，它会咨询Realm做出自己的访问控制决定。必要时，还允许单个Realm同时响应认证和授权操作。这样，任何具有“user:create”权限的角色或用户都可以点击‘Create User’按钮，并且这些角色和指派甚至可以在运行时改变，这给你提供了一个非常灵活的安全模型。“user:create”字符串是一个权限字符串的例子，它遵循特定的解析惯例。Shiro借助它的WildcardPermission支持这种开箱即用的惯例。尽管这超出了本文的范围，你会看到在创建安全策略时，WildcardPermission非常灵活，甚至支持像实例级别访问控制这样的功能。清单9. 实例级别的权限检查if ( subject.isPermitted(“user:delete:jsmith”) ) {
//删除‘jsmith’用户
} else {
//不删除‘jsmith’
}
页:
[1]