之前在Authentication和Authorization中也提到Realm。

无论是身份验证还是权限验证，无论数据以什么方式存在，我们都需要访问一些数据并将其转换为Shiro可以识别的格式。

通常一个数据源对应一个Realm。因此，实现一个Realm时会用到该数据源相关的API。

通常一个数据源中会同时保存身份相关数据与权限相关数据。因此，一个Realm实现类可以进行认证和授权两种操作。

可以将Realm简单地理解为DAO。

(虽然IDEA生成的type hirarchy diagram很漂亮，但是太大了...还是用回eclipse截图..)

如果使用.ini配置，我们可以在[main]部分定义N个Realm，但我们可以用显式(explicit)和隐式(implicit)两种方式为securityManager指定Realm(有点IOC容器的意思)。

显示指定就是常见的方式，即定义Realm后再为securityManager按需要的顺序指定Realm。

fooRealm = com.company.foo.RealmbarRealm = com.company.another.RealmbazRealm = com.company.baz.RealmsecurityManager.realms = $fooRealm, $barRealm, $bazRealm

显示指定的方式相对较为明确，即使不改变Realm的定义，我们仍可以让验证和授权按我们给securityManager指定的顺序的Realm来执行。

如果因为某些原因(可能是定义的Realm太多?)不想为securityManager.realms指定，我们也可以使用隐式方式。

也就是说，把上面的配置改成如下形式就是隐式方式了：

blahRealm = com.company.blah.RealmfooRealm = com.company.foo.RealmbarRealm = com.company.another.Realm

隐式方式其实就是不指定，只定义(define)，Shiro会搜索配置中所有的Realm并将它们一一指定给securityManager。

使用隐式方式时只要稍微改一下Realm的定义，Shiro就可能会给我们来个惊喜。

在介绍Authentication的文章中，说的是当一个验证请求出现时Shiro框架的工作流程。

在这里具体记录一下Realm负责的工作(虽然说securiyManager验证开始的地方，但从数据源取数据并作比较的工作是由Realm来进行的)。

以ModularRealmAuthenticator为例：

   protected AuthenticationInfo doMultiRealmAuthentication(Collection<Realm> realms, AuthenticationToken token) {        AuthenticationStrategy strategy = getAuthenticationStrategy();        AuthenticationInfo aggregate = strategy.beforeAllAttempts(realms, token);        if (log.isTraceEnabled()) {            log.trace("Iterating through {} realms for PAM authentication", realms.size());        }        for (Realm realm : realms) {            aggregate = strategy.beforeAttempt(realm, token, aggregate);            if (realm.supports(token)) {                log.trace("Attempting to authenticate token [{}] using realm [{}]", token, realm);                AuthenticationInfo info = null;                Throwable t = null;                try {                    info = realm.getAuthenticationInfo(token);                } catch (Throwable throwable) {                    t = throwable;                    if (log.isDebugEnabled()) {                        String msg = "Realm [" + realm + "] threw an exception during a multi-realm authentication attempt:";                        log.debug(msg, t);                    }                }                aggregate = strategy.afterAttempt(realm, token, info, aggregate, t);            } else {                log.debug("Realm [{}] does not support token {}.  Skipping realm.", realm, token);            }        }        aggregate = strategy.afterAllAttempts(token, aggregate);        return aggregate;    }

在Realm开始处理验证的逻辑之前，Authenticator将调用Realm的supports方法去验证当前Realm是否支持获得的AuthenticationToken。

通常，Realm检查的是token的类型，比如在AuthenticatingRealm中检查类型是否相同。

public boolean supports(AuthenticationToken token) {    return token != null && getAuthenticationTokenClass().isAssignableFrom(token.getClass());}

另外，AuthenticatingRealm的constructor中类型默认为

authenticationTokenClass = UsernamePasswordToken.class;

如果当前Realm支持提交过来的token，authenticator则调用getAuthenticationInfo(token)方法。

以AuthenticatingRealm为例(注意是final)：

public final AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {    AuthenticationInfo info = getCachedAuthenticationInfo(token);    if (info == null) {        //otherwise not cached, perform the lookup:        info = doGetAuthenticationInfo(token);        log.debug("Looked up AuthenticationInfo [{}] from doGetAuthenticationInfo", info);        if (token != null && info != null) {            cacheAuthenticationInfoIfPossible(token, info);        }    } else {        log.debug("Using cached authentication info [{}] to perform credentials matching.", info);    }    if (info != null) {        assertCredentialsMatch(token, info);    } else {        log.debug("No AuthenticationInfo found for submitted AuthenticationToken [{}].  Returning null.", token);    }    return info;}

如果可以从缓存中获得验证信息，下一步则检查密码是否匹配，即assertCredentialsMatch(token, info)。

如果缓存中不存在验证信息则调用以下方法。

protected abstract AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException;

这里我们暂时先不考虑缓存的情况，考虑doGetAuthenticationInfo应该做什么。

有些人(比如我)直接在该方法中完成也验证，验证通过时返回SimpleAuthenticationInfo实例，失败则抛出相应的验证异常。

但下面有个assertCredentialsMatch，说明doGetAuthenticationInfo本没有打算这样用，这种使用方式会让CredentialMatcher失去意义。

参考JdbcRealm的实现，只是根据身份(用户名)去查询并返回SimpleAuthenticationInfo实例。

然后让assertCredentialsMatch比较token和authenticationInfo。

protected void assertCredentialsMatch(AuthenticationToken token, AuthenticationInfo info) throws AuthenticationException {    CredentialsMatcher cm = getCredentialsMatcher();    if (cm != null) {        if (!cm.doCredentialsMatch(token, info)) {            //not successful - throw an exception to indicate this:            String msg = "Submitted credentials for token [" + token + "] did not match the expected credentials.";            throw new IncorrectCredentialsException(msg);        }    } else {        throw new AuthenticationException("A CredentialsMatcher must be configured in order to verify " +                "credentials during authentication.  If you do not wish for credentials to be examined, you " +                "can configure an " + AllowAllCredentialsMatcher.class.getName() + " instance.");    }}

既然提到了CredentialMatcher，我们来看看他的意义所在。 首先说明，AuthenticatingRealm的默认CredentialMatcher是...

public AuthenticatingRealm() {    this(null, new SimpleCredentialsMatcher());}

如果仅仅是做密码字符比较我们大可不必做出这样一个接口(字符串比较的可插拔+可定制么?)

之前在说Authentication的时候就提过，AuthenticationToken的Principal和Credential可以是任何类型的，光是拿过来直接比较是否相符也不只是比较密码字符那么简单了。

SimpleCredentialsMatcher就是用来比较两个credential是否相同的。

其doCredentialsMatch方法返回其equals方法的返回值。

protected boolean equals(Object tokenCredentials, Object accountCredentials) {    if (log.isDebugEnabled()) {        log.debug("Performing credentials equality check for tokenCredentials of type [" +                tokenCredentials.getClass().getName() + " and accountCredentials of type [" +                accountCredentials.getClass().getName() + "]");    }    if (isByteSource(tokenCredentials) && isByteSource(accountCredentials)) {        if (log.isDebugEnabled()) {            log.debug("Both credentials arguments can be easily converted to byte arrays.  Performing " +                    "array equals comparison");        }        byte[] tokenBytes = toBytes(tokenCredentials);        byte[] accountBytes = toBytes(accountCredentials);        return Arrays.equals(tokenBytes, accountBytes);    } else {        return accountCredentials.equals(tokenCredentials);    }}

当然，实现类不只是SimpleCredentialsMatcher...

SimpleCredentialsMatcher下还跟着HashedCredentialsMatcher，再往下就都deprecated了。

说到HashedCredentialsMatcher，他只是给密码加个salt以提高安全。

其中hashSalted属性基本不用考虑，因为从Shiro 1.1开始salt是根据SaltedAuthenticationInfo的getCredentialSalt()方法返回的non-null value。

public HashedCredentialsMatcher() {    this.hashAlgorithm = null;    this.hashSalted = false;    this.hashIterations = 1;    this.storedCredentialsHexEncoded = true; //false means Base64-encoded}

说到salting就不得不说SaltedAuthenticationInfo，该接口继承AuthenticationInfo，即除了principal和credential，他还有一个credentialsSalt。

public interface SaltedAuthenticationInfo extends AuthenticationInfo {    /**     * Returns the salt used to salt the account‘s credentials or {@code null} if no salt was used.     *     * @return the salt used to salt the account‘s credentials or {@code null} if no salt was used.     */    ByteSource getCredentialsSalt();}

HashedCredentialsMatcher有个默认的salt，是将自己的principal作为salt，后来这个方法也被deprecated了。

因为从1.1开始，Shiro禁止salt从用户的登录信息中获取，而应该从数据源获取。

@Deprecatedprotected Object getSalt(AuthenticationToken token) {    return token.getPrincipal();}

这一系列方法和属性会从Shiro 2.0开始彻底消失。

Shiro - 关于Realm