让Apache Shiro保护你的应用

在尝试保护你的应用时，你是否有过挫败感？是否觉得现有的Java安全解决方案难以使用，只会让你更糊涂？本文介绍的Apache Shiro，是一个不同寻常的Java安全框架，为保护应用提供了简单而强大的方法。本文还解释了Apache Shiro的项目目标、架构理念以及如何使用Shiro为应用安全保驾护航。

什么是Apache Shiro？Apache Shiro（发音为“shee-roh”，日语“堡垒（Castle）”的意思）是一个强大易用的Java安全框架，提供了认证、授权、加密和会话管理功能，可为任何应用提供安全保障 - 从命令行应用、移动应用到大型网络及企业应用。

Shiro为解决下列问题（我喜欢称它们为应用安全的四要素）提供了保护应用的API：
相关厂商内容
Windows Azure在中国正式开启在线直付 率先在国内落地的全球化云服务，深度了解Windows Azure 利用开发测试云实现精益创业、快速迭代 Windows Azure自管理服务实现近乎零停机维护 Windows Azure专区上线，全面了解云服务 相关赞助商
 
Windows Azure专区上线，全面了解云服务精彩呈现！

"codetitle">复制代码 代码如下:
import org.apache.shiro.subject.Subject;
import org.apache.shiro.SecurityUtils;
...
Subject currentUser = SecurityUtils.getSubject();

一旦获得Subject，你就可以立即获得你希望用Shiro为当前用户做的90%的事情，如登录、登出、访问会话、执行授权检查等 - 稍后还会看到更多。这里的关键点是Shiro的API非常直观，因为它反映了开发者以‘每个用户'思考安全控制的自然趋势。同时，在代码的任何地方都能很轻松地访问Subject，允许在任何需要的地方进行安全操作。

SecurityManager

Subject的“幕后”推手是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

复制代码 代码如下:
[main]
cm = org.apache.shiro.authc.credential.HashedCredentialsMatcher
cm.hashAlgorithm = SHA-512
cm.hashIterations = 1024
# Base64 encoding (less text):
cm.storedCredentialsHexEncoded = false

iniRealm.credentialsMatcher = $cm

[users]
jdoe = TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJpcyByZWFzb2
asmith = IHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbXNoZWQsIG5vdCB

在清单2中，我们看到了用于配置SecurityManager实例的INI配置例子。有两个INI段落：[main]和[users].

[main]段落是配置SecurityManager对象及其使用的其他任何对象（如Realms）的地方。在示例中，我们看到配置了两个对象：

1. cm对象，是Shiro的HashedCredentialsMatcher类实例。如你所见，cm实例的各属性是通过“嵌套点”语法进行配置的 - 在清单3中可以看到IniSecurityManagerFactory使用的惯例，这种方法代表了对象图导航和属性设置。
2. iniRealm对象，它被SecurityManager用来表示以INI格式定义的用户帐户。

[users]段落是指定用户帐户静态列表的地方 - 为简单应用或测试提供了方便。

就介绍而言，详细了解每个段落的细节并不是重点。相反，看到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的示例中，我们看到有三步：

1. 装入用来配置SecurityManager及其构成组件的INI配置文件；
2. 根据配置创建SecurityManager实例（使用Shiro的工厂概念，它表述了工厂方法设计模式）；
3. 使应用可访问SecurityManager Singleton。在这个简单示例中，我们将它设置为VM静态Singleton，但这通常不是必须的 - 你的应用配置机制可以决定你是否需要使用静态存储。

Realms

Shiro的第三个也是最后一个概念是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

复制代码 代码如下:
[main]
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环境，下面让我们来讨论，作为一名开发者该如何使用这个框架。
认证认证是核实用户身份的过程。也就是说，当用户使用应用进行认证时，他们就在证明他们就是自己所说的那个人。有时这也理解为“登录”。它是一个典型的三步骤过程。
1.收集用户的身份信息，称为当事人（principal），以及身份的支持证明，称为证书（Credential）。
2.将当事人和证书提交给系统。

3.如果提交的证书与系统期望的该用户身份（当事人）匹配，该用户就被认为是经过认证的，反之则被认为未经认证的。
这个过程的常见例子是大家都熟悉的“用户/密码”组合。多数用户在登录软件系统时，通常提供自己的用户名（当事人）和支持他们的密码（证书）。如果存储在系统中的密码（或密码表示）与用户提供的匹配，他们就被认为通过认证。

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 {
    //按钮置灰"codetitle">复制代码 代码如下:
if ( subject.isPermitted(“user:create”) ) {
    //显示‘Create User'按钮
} else {
    //按钮置灰"codetitle">复制代码 代码如下:
if ( subject.isPermitted(“user:delete:jsmith”) ) {
    //删除‘jsmith'用户
} else {
    //不删除‘jsmith'
}

该例表明，你可以对你需要的单个资源进行访问控制，甚至深入到非常细粒度的实例级别。如果愿意，你甚至还可以发明自己的权限语法。参见Shiro Permission文档可以了解更多内容。最后，就像使用认证那样，上述调用最终会转向SecurityManager，它会咨询Realm做出自己的访问控制决定。必要时，还允许单个Realm同时响应认证和授权操作。

以上就是对Shiro授权功能的简要概述。虽然多数安全框架止于授权和认证，但Shiro提供了更多功能。下面，我们将谈谈Shiro的高级会话管理功能。

会话管理在安全框架领域，Apache Shiro提供了一些独特的东西：可在任何应用或架构层一致地使用Session API。即，Shiro为任何应用提供了一个会话编程范式 - 从小型后台独立应用到大型集群Web应用。这意味着，那些希望使用会话的应用开发者，不必被迫使用Servlet或EJB容器了。或者，如果正在使用这些容器，开发者现在也可以选择使用在任何层统一一致的会话API，取代Servlet或EJB机制。

但Shiro会话最重要的一个好处或许就是它们是独立于容器的。这具有微妙但非常强大的影响。例如，让我们考虑一下会话集群。对集群会话来讲，支持容错和故障转移有多少种容器特定的方式？Tomcat的方式与Jetty的不同，而Jetty又和Websphere不一样，等等。但通过Shiro会话，你可以获得一个容器无关的集群解决方案。Shiro的架构允许可插拔的会话数据存储，如企业缓存、关系数据库、NoSQL系统等。这意味着，只要配置会话集群一次，它就会以相同的方式工作，跟部署环境无关 - Tomcat、Jetty、JEE服务器或者独立应用。不管如何部署应用，毋须重新配置应用。

Shiro会话的另一好处就是，如果需要，会话数据可以跨客户端技术进行共享。例如，Swing桌面客户端在需要时可以参与相同的Web应用会话中 - 如果最终用户同时使用这两种应用，这样的功能会很有用。那你如何在任何环境中访问Subject的会话呢？请看下面的示例，里面使用了Subject的两个方法。

清单10. Subject的会话

复制代码 代码如下:
Session session = subject.getSession();
Session session = subject.getSession(boolean create);

如你所见，这些方法在概念上等同于HttpServletRequest API。第一个方法会返回Subject的现有会话，或者如果还没有会话，它会创建一个新的并将之返回。第二个方法接受一个布尔参数，这个参数用于判定会话不存在时是否创建新会话。一旦获得Shiro的会话，你几乎可以像使用HttpSession一样使用它。Shiro团队觉得对于Java开发者，HttpSession API用起来太舒服了，所以我们保留了它的很多感觉。当然，最大的不同在于，你可以在任何应用中使用Shiro会话，不仅限于Web应用。清单11中显示了这种相似性。

清单11. 会话的方法

复制代码 代码如下:
Session session = subject.getSession();
session.getAttribute("key", someValue);
Date start = session.getStartTimestamp();
Date timestamp = session.getLastAccessTime();
session.setTimeout(millis); ...

加密加密是隐藏或混淆数据以避免被偷窥的过程。在加密方面，Shiro的目标是简化并让JDK的加密支持可用。

清楚一点很重要，一般情况下，加密不是特定于Subject的，所以它是Shiro API的一部分，但并不特定于Subject。你可以在任何地方使用Shiro的加密支持，甚至在不使用Subject的情况下。对于加密支持，Shiro真正关注的两个领域是加密哈希（又名消息摘要）和加密密码。下面我们来看看这两个方面的详细描述。

哈希如果你曾使用过JDK的MessageDigest类，你会立刻意识到它的使用有点麻烦。MessageDigest类有一个笨拙的基于工厂的静态方法API，它不是面向对象的，并且你被迫去捕获那些永远都不必捕获的Checked Exceptions。如果需要输出十六进制编码或Base64编码的消息摘要，你只有靠自己 - 对上述两种编码，没有标准的JDK支持它们。Shiro用一种干净而直观的哈希API解决了上述问题。

打个比方，考虑比较常见的情况，使用MD5哈希一个文件，并确定该哈希的十六进制值。被称为‘校验和'，这在提供文件下载时常用到 - 用户可以对下载文件执行自己的MD5哈希。如果它们匹配，用户完全可以认定文件在传输过程中没有被篡改。

不使用Shiro，你需要如下步骤才能完成上述内容：

1.将文件转换成字节数组。JDK中没有干这事的，故而你需要创建一个辅助方法用于打开FileInputStream，使用字节缓存区，并抛出相关的IOExceptions，等等。
2.使用MessageDigest类对字节数组进行哈希，处理相关异常，如清单12所示。
3.将哈希后的字节数组编码成十六进制字符。JDK中还是没有干这事的，你依旧需要创建另外一个辅助方法，有可能在你的实现中会使用位操作和位移动。

清单12. JDK的消息摘要

复制代码 代码如下:
try {
    MessageDigest md = MessageDigest.getInstance("MD5");
    md.digest(bytes);
    byte[] hashed = md.digest();
} catch (NoSuchAlgorithmException e) {
    e.printStackTrace();
}

对于这样简单普遍的需求，这个工作量实在太大了。现在看看Shiro是如何做同样事情的：

String hex = new Md5Hash(myFile).toHex();

当使用Shiro简化所有这些工作时，一切都非常简单明了。完成SHA-512哈希和密码的Base64编码也一样简单。
String encodedPassword = new Sha512Hash(password, salt, count).toBase64();

你可以看到Shiro对哈希和编码简化了不少，挽救了你处理在这类问题上所消耗的脑细胞。
密码加密是使用密钥对数据进行可逆转换的加密算法。我们使用其保证数据的安全，尤其是传输或存储数据时，以及在数据容易被窥探的时候。
如果你曾经用过JDK的Cryptography API，特别是javax.crypto.Cipher类，你会知道它是一头需要驯服的极其复杂的野兽。对于初学者，每个可能的加密配置总是由一个javax.crypto.Cipher实例表示。必须进行公钥/私钥加密？你得用Cipher。需要为流操作使用块加密器（Block Cipher）？你得用Cipher。需要创建一个AES 256位Cipher来保护数据？你得用Cipher。你懂的。

那么如何创建你需要的Cipher实例？您得创建一个非直观、标记分隔的加密选项字符串，它被称为“转换字符串（transformation string）”，把该字符串传给Cipher.getInstance静态工厂方法。这种字符串方式的cipher选项，并没有类型安全以确保你正在用有效的选项。这也暗示没有JavaDoc帮你了解相关选项。并且，如果字符串格式组织不正确，你还需要进一步处理Checked Exception，即便你知道配置是正确的。如你所见，使用JDK Cipher是一项相当繁重的任务。很久以前，这些技术曾经是Java API的标准，但是世事变迁，我们需要一种更简单的方法。

Shiro通过引入它的CipherService API试图简化加密密码的整个概念。CipherService是多数开发者在保护数据时梦寐以求的东西：简单、无状态、线程安全的API，能够在一次方法调用中对整个数据进行加密或解密。你所需要做的只是提供你的密钥，就可根据需要加密或解密。如下列清单13中，使用256位AES加密：

清单13. Apache Shiro的加密API

复制代码 代码如下:
AesCipherService cipherService = new AesCipherService();
cipherService.setKeySize(256);

//创建一个测试密钥：
byte[] testKey = cipherService.generateNewKey();
//加密文件的字节：
byte[] encrypted = cipherService.encrypt(fileBytes, testKey);

较之JDK的Cipher API，Shiro的示例要简单的多：
"codetitle">复制代码 代码如下:
<filter>
    <filter-name>ShiroFilter</filter-name>
    <filter-class>
         org.apache.shiro.web.servlet.IniShiroFilter
    </filter-class>
    <!-- 没有init-param属性就表示从classpath:shiro.ini装入INI配置 -->
</filter>
<filter-mapping>
    <filter-name>ShiroFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

这个过滤器可以读取上述shiro.ini配置，这样不论什么开发环境，你都拥有了一致的配置体验。一旦完成配置，Shiro Filter就会过滤每个请求并且确保在请求期间特定请求的Subject是可访问的。同时由于它过滤了每个请求，你可以执行安全特定的逻辑以保证只有满足一定标准的请求才被允许通过。

URL特定的Filter链

Shiro通过其创新的URL过滤器链功能支持安全特定的过滤规则。它允许你为任何匹配的URL模式指定非正式的过滤器链。这意味着， 使用Shiro的过滤器机制，你可以很灵活的强制安全规则（或者规则的组合） - 其程度远远超过你单独在web.xml中定义过滤器时所获得的。清单15中显示了Shiro INI中的配置片段。

清单15. 路径特定的Filter链

复制代码 代码如下:
[urls]
/assets/** = anon
/user/signup = anon
/user/** = user
/rpc/rest/** = perms[rpc:invoke], authc
/** = authc

如你所见，Web应用可以使用[urls] INI段落。对于每一行，等号左边的值表示相对上下文的Web应用路径。等号右边的值定义了过滤器链 - 一个逗号分隔的有序Servlet过滤器列表，它会针对给出的路径进行执行。每个过滤器都是普通的Servlet过滤器，你看到的上面的过滤器名字（anon，user，perms，authc）是Shiro内置的安全相关的特殊过滤器。你可以搭配这些安全过滤器来创建高度定制的安全体验。你还可以指定任何其他现有的Servlet过滤器。

相比起使用web.xml，在其中先定义过滤器块，然后定义单独分离的过滤器模式块，这种方式带来的好处有多少？采用Shiro的方法，可以很容易就准确知道针对给定匹配路径执行的过滤器链。如果想这么做，你可以在web.xml中仅定义Shiro Filter，在shiro.ini中定义所有其他的过滤器和过滤器链，这要比web.xml简洁得多，而且更容易理解过滤器链定义机制。即使不使用Shiro的任何安全特性，单凭这样小小的方便之处，也值得让你使用Shiro。

JSP标签库

Shiro还提供了JSP标签库，允许你根据当前Subject的状态控制JSP页面的输出。一个有用的常见示例是在用户登录后显示“Hello <username>"文本。但若是匿名用户，你可能想要显示其他内容，如换而显示“Hello! Register Today!”。清单16显示了如何使用Shiro的JSP标签实现这个示例：

清单16. JSP 标签库示例

复制代码 代码如下:
<%@ taglib prefix="shiro" 
   uri="http://shiro.apache.org/tags" %>
...
<p>Hello
<shiro:user>
    <!-- shiro:principal打印出了Subject的主当事人 - 在这个示例中，就是用户名： -->
    <shiro:principal/>!
</shiro:user>
<shiro:guest>
    <!-- 没有登录 - 就认为是Guest。显示注册链接： -->
    ! <a href=”register.jsp”>Register today!</a>
</shiro:guest>
</p>

除了上面例子用到的标签，还有其他标签可以让你根据用户属于（或不属于）的角色，分配（或未分配）的权限，是否已认证，是否来自“记住我”服务的记忆，或是匿名访客，包含输出。

Shiro还支持其他许多Web特性，如简单的“记住我”服务，REST和BASIC认证。当然，如果想使用Shiro原生的企业会话，它还提供透明的HttpSession支持。参见Apache Shiro Web文档可以了解更多内容。

Web会话管理

最后值得一提的是Shiro在Web环境中对会话的支持。

缺省Http会话

对于Web应用，Shiro缺省将使用我们习以为常的Servlet容器会话作为其会话基础设施。即，当你调用subject.getSession()和subject.getSession(boolean)方法时，Shiro会返回Servlet容器的HttpSession实例支持的Session实例。这种方式的曼妙之处在于调用subject.getSession()的业务层代码会跟一个Shiro Session实例交互 - 还没有“认识”到它正跟一个基于Web的HttpSession打交道。这在维护架构层之间的清晰隔离时，是一件非常好的事情。

Web层中Shiro的原生会话

如果你由于需要Shiro的企业级会话特性（如容器无关的集群）而打开了Shiro的原生会话管理，你当然希望HttpServletRequest.getSession()和HttpSession API能和“原生”会话协作，而非Servlet容器会话。如果你不得不重构所有使用HttpServletRequest和HttpSession API的代码，使用Shiro的Session API来替换，这将非常令人沮丧。Shiro当然从来不会期望你这么做。相反，Shiro完整实现了Servlet规范中的Session部分以在Web应用中支持原生会话。这意味着，不管何时你使用相应的HttpServletRequest或HttpSession方法调用，Shiro都会将这些调用委托给内部的原生会话API。结果，你无需修改Web代码，即便是你正在使用Shiro的‘原生'企业会话管理 - 确实是一个非常方便（且必要）的特性。

附加特性

Apache Shiro框架还包含有对保护Java应用非常有用的其他特性，如：

• 为维持跨线程的Suject提供了线程和并发支持（支持Executor和ExecutorService）；
• 为了将执行逻辑作为一种特殊的Subject，支持Callable和Runnable接口；
• 为了表现为另一个Subject的身份，支持“Run As”（比如，在管理应用中有用）；
• 支持测试工具，这样可以很容易的对Shiro的安全代码进行单元测试和集成测试。

框架局限

常识告诉我们，Apache Shiro不是“银弹” - 它不能毫不费力的解决所有安全问题。如下是Shiro还未解决，但是值得知道的：

• 虚拟机级别的问题：Apache Shiro当前还未处理虚拟机级别的安全，比如基于访问控制策略，阻止类加载器中装入某个类。然而，Shiro集成现有的JVM安全操作并非白日做梦 - 只是没人给项目贡献这方面的工作。
• 多阶段认证：目前，Shiro不支持“多阶段”认证，即用户可能通过一种机制登录，当被要求再次登录时，使用另一种机制登录。这在基于Shiro的应用中已经实现，但是通过应用预先收集所有必需信息再跟Shiro交互。这个功能在Shiro的未来版本中非常有可能得到支持。
• Realm写操作：目前所有Realm实现都支持“读”操作来获取验证和授权数据以执行登录和访问控制。诸如创建用户帐户、组和角色或与用户相关的角色组和权限这类“写”操作还不支持。这是因为支持这些操作的应用数据模型变化太大，很难为所有的Shiro用户强制定义“写”API。

未来的特性

Apache Shiro社区每天都在壮大，借此，Shiro的特性亦是如此。在即将发布的版本中，你可能会看到：

• 更干净的Web过滤机制，无需子类化就可支持更多的插件式过滤器。
• 更多可插拔的缺省Realm实现，优先采用组合而非继承。你可以插入查找认证和授权数据的组件，无需实现为Shiro Realm的子类；
• 强健的OpenID和OAuth（可能是混合）客户端支持；
• 支持Captcha；
• 针对纯无状态应用的配置简化（如，许多REST环境）；
• 通过请求/响应协议进行多阶段认证；
• 通过AuthorizationRequest进行粗粒度的授权；
• 针对安全断言查询的ANTLR语法（比如，(‘role(admin) && (guest || !group(developer))'）

总结

Apache Shiro是一个功能齐全、健壮、通用的Java安全框架，你可以用其为你的应用护航。通过简化应用安全的四个领域，即认证、授权、会话管理和加密，在真实应用中，应用安全能更容易被理解和实现。Shiro的简单架构和兼容JavaBean使其几乎能够在任何环境下配置和使用。附加的Web支持和辅助功能，比如多线程和测试支持，让这个框架为应用安全提供了“一站式”服务。Apache Shiro开发团队将继续前进，精炼代码库和支持社区。随着持续被开源和商业应用采纳，可以预期Shiro会继续发展壮大。

资源

• Apache Shiro的主页。
• Shiro的下载页面，包含面向Maven和Ant+Ivy用户的额外信息。
• Apache Shiro的文档页面，包含指南和参考手册。
• Apache Shiro演讲视频和幻灯，项目的PMC主席Les Hazlewood提供。
• 其他关于Apache Shiro的文章和幻灯
• Apache Shiro的邮件列表和论坛。
• Katasoft - 提供Apache Shiro专业支持和应用安全产品的公司。

关于作者

Les Hazlewood是Apache Shiro PMC主席以及Katasoft的CTO和合伙创办人，该公司是专注于应用安全产品以及提供Apache Shiro专业支持的创业公司。作为专业Java开发人员及企业架构师，以及之前Bloomberg，Delta Airlines和JBoss的高级角色，Les拥有10年的的经验。Les积极从事开源开发已有9年时间，提交或做出贡献的项目有Spring框架、Hibernate、JBoss，OpenSpaces，当然还有JSecurity，Apache Shiro的前身。Les目前居住在加州的圣马特奥，不编程时，他会练习剑道和学习日语。

查看英文原文： Application Security With Apache Shiro

感谢胡键对本文的审校。