Apache Shiro Realms
Realm 是可以访问程序特定的安全数据如用户、角色、权限等的一个组件。Realm会将这些程序特定的安全数据转换成一种shiro可以理解的形式,shiro就可以依次提供容易理解的Subject程序API而不管有多少数据源或者程序中你的数据如何组织。
Realm 通常和数据源如数据库、LDAP目录、文件系统或者其它类似的数据源是一对一的关系,所以,可以用数据源相应的API如JDBC、File IO、 Hibernate 或者JPA以及其它的API来实现Realm接口,从而获取授权的相关数据(角色、权限等)。
realm本质上就是一个指定安全的DAO。
因为大部分这类数据源通常都会同时存储认证数据(如密码)和授权数据(如角色和权限),所以每一个Shiro Realm都可以同时执行认证和授权操作。
Realm Configuration
如果使用shiro的ini配置文件,你可以在[main]区域内像配置其它对象一样定义和引用Realms,但是Realm在secrityManager上的配置有两种方式:明确方式和隐含方式。
明确指定
在迄今所知的INI配置文件的相关知识中,这是一种显示的配置方式。在定义一个或多个Realm后,再将它们在securityManager上进行统一配置。
例如:
fooRealm = com.company.foo.Realm
barRealm = com.company.another.Realm
bazRealm = com.company.baz.Realm
securityManager.realms = $fooRealm, $barRealm, $bazRealm
明确设置是确定性的,你可以非常确切地知道哪个realm在使用并且知道它们执行的顺序。可以查看认证章节的Authentication Sequence 了解Realm的执行顺序的影响效果。
不明确指定
不是首选的
不明确指定时,如果你改变了realm定义时的顺序可能引起未可知的动作,建议你避免使用这种方式而使用明确指定的方式,不明确指定将来会从shiro的版本中去除。
如果你真的有理由不想明确配置securityManager.realms属性,你可以让Shiro自行去发现所有配置的realm并且直接将它们指定给securityManager。
使用这种方法,realm按照定义的顺序指定给securityManager实例。
也就是说,对于下面shiro.ini的例子:
blahRealm = com.company.blah.Realm
fooRealm = com.company.foo.Realm
barRealm = com.company.another.Realm
# no securityManager.realms assignment here
本质上和加上下面这行效果相同:
securityManager.realms = $blahRealm, $fooRealm, $barRealm
然而,要明白使用不明确的指定方法,realm定义的顺序直接影响其在验证和授权尝试中执行的顺序,如果你改变了定义顺序,你必须改变Authenticator的验证序列函数。
因此,为了确保行为的确定性,我们建议使用明确指定的方式代替不明确的指定方式。
Realm验证
一旦理解了shiro主要的认证流程,你应该知道非常重要的一点:尝试进行认证时Realm和Authenticator之间究竟发生了什么。
支持AuthenticationTokens
正如在验证序列中提到的,在一个realm执行一个验证尝试之前,它的“支持”方法被调用。只有在返回值为true的时候它的getAuthenticationInfo(token) 方法才会执行。
通常情况下,一个realm将检查提交的令牌类型(接口或类)确定自己是否可以处理它,例如,一个处理生物特性数据的Realm可能一点也不理解UsernamePasswordTokens,在这种情况下它将从支持函数中返回false。
处理支持的验证令牌
如果一个Realm支持提交的验证令牌,验证将调用Realm的getAuthenticationInfo(token)方法,这是Realm使用后台数据进行验证的一次有效尝试,顺序执行以下动作:
1.检查主要身份令牌(用户身份信息);
2.基于主要信息,在数据源中查找对应的用户数据;
3.确定令牌支持的凭证数据和存储的数据相符;
4.如果凭证相符,返回一个AuthenticationInfo实例,里面封装了Shiro可以理解的用户数据。
5.如果证据不符,抛出AuthenticationException 异常。
这是所有Realm getAuthenticationInfo 实现的最高级别工作流,Realm在这个过程中可以自由做自己想做的事情,比如记录日志,修改数据,以及其他,只要对于存储的数据和验证尝试来讲是合理的就行。
仅有一件事情是必须的,如果证据和给定的主要信息匹配,需要返回一个非空的AuthenticationInfo实例,用来表示来自数据源的用户信息。
节约时间
直接实现Realm接口也许需要时间并容易出错,大部分用户选择继承AuthorizingRealm虚拟类,这个类实现了常用的验证和授权工作流,这会节省你的时间而且不易出错。
凭证匹配
在上述realm验证工作流中,一个Realm必须较验Subject提交的凭证(如密码)是否与存储在数据中的证书相匹配,如果匹配,验证成功,系统保留已证实的终端用户身份。
Realm凭证匹配
检查提交的凭证是否与后台存储数据相匹配是每一个Realm的责任而不是Authenticator的责任,每一个Realm都具备与凭证形式及存储密切相关的技能,可以执行详细的证明比对,而Authenticator只是一个普通的工作流组件。
凭证匹配的过程在所有程序中基本上是一样的,通常只是对比数据方式不同。要确保这个过程在必要时是可插拔和可定制的,AuthenticatingRealm以及它的子类支持用CredentialsMatcher来执行一个凭证对比。
在找到用户数据之后,它和提交的 AuthenticationToken一起传递给一个 CredentialsMatcher ,后者用来检查提交的数据和存储的数据是否相匹配。
Shiro某些CredentialsMatcher实现可以使你开始out of the box,比如 SimpleCredentialsMatcher和HashedCredentialsMatcher实现,但如果你想配置一个自定义的实现来完成特定的对比逻辑,你可以这样做:
Realm myRealm = new com.company.shiro.realm.MyRealm();
CredentialsMatcher customMatcher = new com.company.shiro.realm.CustomCredentialsMatcher();
myRealm.setCredentialsMatcher(customMatcher);
或者,使用Shiro的INI配置文件
[main]
...
customMatcher = com.company.shiro.realm.CustomCredentialsMatcher
myRealm = com.company.shiro.realm.MyRealm
myRealm.credentialsMatcher = $customMatcher
...
简单证明匹配
所有Shiro的out-of-the-box Realm默认使用一个 SimpleCredentialsMatcher(简单证明匹配), SimpleCredentialsMatcher对存储的用户凭证和从AuthenticationToken提交的用户凭证直接执行相等的检查。
例如,如果提交了一个UsernamePasswordToken,SimpleCredentialsMatcher检查提交的密码与存储的密码是否完全相等。
SimpleCredentialsMatcher 不仅仅对字符串执行相同对比,它可以对大多数常用类型,如字符串、字符数组、字节数组、文件和输入流等执行对比,查看JavaDoc获取更多的信息。
Hashing凭证:
取代将凭证按它们原始形式存储并执行原始数据的对比,存储终端用户的凭证(如密码)更安全的办法是在存储数据之前,先进行hash运算。
这确保终端用户的凭证不会以他们原始的形式存储,没有人能知道其原始值。与明文原始比较相比这是一种更为安全的做法,有安全意识的程序会更喜欢这种方法。
要支持这种加密的hash策略,Shiro为Realm配置提供了一个HashedCredentialsMatcher实现替代之前的 SimpleCredentialsMatcher。
Hashing 凭证以及hash迭代的好处超出了该Realm文档的范围,可以在HashedCredentialsMatcher JavaDoc更详细地了解这些主要内容。
Hashing以及相符合的匹配
对于一个使用Shiro的程序,如何配置才能简单地做到这些?
Shiro提供了多个HashedCredentialsMatcher子类实现,你必须在你的Realm上配置指定的实现来匹配你的凭证所使用的hash算法。
例发,假设你的程序使用用户名/密码对来进行验证,基于上述hash凭证的好处,你希望当创建用户时以SHA-265方式加密用户的密码,你可以加密用户输入的明文密码并保存加密值:
import org.apache.shiro.crypto.hash.Sha256Hash;
import org.apache.shiro.crypto.RandomNumberGenerator;
import org.apache.shiro.crypto.SecureRandomNumberGenerator;
...
//We'll use a Random Number Generator to generate salts. This
//is much more secure than using a username as a salt or not
//having a salt at all. Shiro makes this easy.
//
//Note that a normal app would reference an attribute rather
//than create a new RNG every time:
RandomNumberGenerator rng = new SecureRandomNumberGenerator();
Object salt = rng.nextBytes();
//Now hash the plain-text password with the random salt and multiple
//iterations and then Base64-encode the value (requires less space than Hex):
String hashedPasswordBase64 = new Sha256Hash(plainTextPassword, salt, 1024).toBase64();
User user = new User(username, hashedPasswordBase64);
//save the salt with the new account. The HashedCredentialsMatcher
//will need it later when handling login attempts:
user.setPasswordSalt(salt);
userDAO.create(user);
由于你使用SHA-256加密你的密码,你需要告诉Shiro使用相应的 HashedCredentialsMatcher来检查你的hashing值,在这个例子中,我们为了加强安全创建了一个随机的salt并且执行1024 Hash迭代(查看HashedCredentialsMatcher JAVADoc了解为什么),下面的Shiro INI 配置来做这件工作。
[main]
...
credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
# base64 encoding, not hex in this example:
credentialsMatcher.storedCredentialsHexEncoded = false
credentialsMatcher.hashIterations = 1024
# This next property is only needed in Shiro 1.0. Remove it in 1.1 and later:
credentialsMatcher.hashSalted = true
...
myRealm = com.company.....
myRealm.credentialsMatcher = $credentialsMatcher
...
SaltedAuthenticationInfo
确保正常运行的最后一件要做的事情是你的Realm实现必须返回一个 SaltedAuthenticationInfo 实例而不是普通的AuthenticationInfo,SaltedAuthenticationInfo 接口确保你在创建用户帐户时使用的salt(如上面调用的 user.setPasswordSalt(salt);)能被HashedCredentialsMatcher引用。
HashedCredentialsMatcher需要使用salt来对提交的AuthenticationToken执行相同的hashing技术来对比提交的令牌是否与存储的数据相匹配,所以如果你对用户密码使用salting(你应该这么做),确保你的Realm实现在返回SaltedAuthenticationInfo 实例时引用它。
禁用验证
如果有理由,你不希望某个Realm对某个资源执行验证(或者因为你只想Realm去执行授权检查),你可以完全禁用Realm的验证支持,方法就是在Realm的支持方法中始终返回False,这样,你的realm将在整个验证过程中不再被使用。
当然如果你想验证Subject,至少要配置一个支持AuthenticationTokens 的Realm。
Realm 授权
待决定。