解锁Apache Shiro：新手友好的安全框架指南(一)——整体架构与身份认证

引言

Apache Shiro 是一个功能强大且易于使用的 Java 安全框架，它执行身份验证、授权、加密和会话管理，可用于保护任何应用程序——从命令行应用程序、移动应用程序到最大的 web 和企业应用程序。

Shiro 提供了应用程序安全 API 来执行以下方面：

• Authentication（认证）：验证用户身份，即用户登录。
• Authorization（授权）：访问控制
• Cryptography（密码学）：保护或隐藏私密数据
• Session Management（会话管理）：每个用户的时间敏感状态

本文作为 Shiro 指南的第一篇，重点介绍 Shiro 的整体架构与认证功能。在本文的最后一章，我将编写一个案例串联本文讲述的知识点。

Shiro 整体架构

架构图

Shiro 的核心架构概念展示于下图，我将在随后介绍每个组件：

• Subject：实体在安全领域的抽象，这个实体可以是用户、服务、定时任务等与软件存在交互的事物。
• SecurityManager：在Shiro的整体架构中，SecurityManager是核心组件，它管理着所有与安全相关的操作。SecurityManager类似于Spring框架中的ApplicationContext，是 Shiro 功能的中心，协调着认证、授权、会话、缓存等不同组件。
• Authenticator：当用户尝试登录时，该逻辑由Authenticator负责执行用户身份验证并对尝试结果进行响应。Authenticator与一个或多个存储相关用户/帐户信息的Realm协调，使用Realms对象获得的账户数据用于验证用户的身份。
• Authorizer：负责应用程序中用户访问控制的组件，决定用户是否被允许执行某类操作。Authorizer 和 Authenticator 一样，需要访问后端数据源得到用户的角色与权限信息。
• SessionManager：管理用户会话的组件，负责会话的创建、存储、生命周期、安全控制。SessionManager提供了一种机制来跨多个请求和交互维持用户状态，这对于构建需要身份验证和授权的复杂系统是至关重要的。
• CacheManager：创建和管理Cache实例生命周期的组件。Shiro 在认证、授权与会话管理过程中，会访问多个后端数据源，缓存这些数据将提升系统性能。
• Cryptography：Shiro 的 crypto 宝包含易于理解和使用的加密密码、哈希(又名摘要)和不同编解码器实现的表示。例如：Sha256Hash负责对原始密码执行散列操作，然后与数据库中存储的密码匹配。
• Realm：Shiro 与应用安全数据之间的桥梁。用户登录认证和授权时，Shiro 需要访问账户信息，这一过程是通过查询为应用程序配置的一个或多个Realm实例实现。

术语解释

• Subject：它代表应用程序用户的一个 安全特定视图(Security specific user view)。
  安全特定视图：从安全控制和身份认证的角度对用户或实体的抽象表示。一个 Subject 实例代表一个与应用程序交互的实体，包括了这个用户的身份信息、角色、权限等。
  在 Shiro 中，Subject 不局限于人类用户，可以是任何与应用程序交互的实体，包括：

  • 人类用户：比如一个通过浏览器登录的用户。
  • 第三方进程：其他应用程序或服务，可以通过 API 与你的应用程序交互。
  • 定时任务：自动执行的定时任务也可以是一个Subject，比如定期执行的数据库备份任务。

• Principals：Subject 的身份属性。例如：名字、姓氏、用户id、身份证号码。

• Credentials：用于认证身份的私密数据。例如：密码、生物特征数据等。

• Realms：专用于安全领域的数据访问对象（DAO），负责与后端数据源交互。Realms 负责验证用户提交的凭证（如用户名和密码）是否与后端数据源中的记录匹配。

Shiro 身份认证

身份认证是判断一个用户是否为合法用户的过程。最常用的认证方式是系统核对用户输入的用户名和密码，查看是否与系统存储的用户名和密码匹配，来判断用户身份的正确性。除了使用文本密码，还可以使用用户的生物学特征（如：指纹、面部特征）作为认证凭证。

下面一个小节，我将编写第一个 Shiro 程序，演示用户登录流程。

第一个Shiro程序

Java 中使用 Shiro 执行身份认证的过程可以分解为如下步骤：

1. 收集 Subject 的 principals（账户） 和 credentials（密码）；
2. 提交 principals 和 credentials 给认证系统；
3. 得到认证结果：认证通过允许访问、重试认证、认证失败阻止访问。

环境配置

案例基于 Maven 构建，pom.xml 配置：

    <dependencies>
        
        <dependency>
            <groupId>org.apache.shirogroupId>
            <artifactId>shiro-coreartifactId>
            <version>1.10.1version>
        dependency>

        <dependency>
            <groupId>commons-logginggroupId>
            <artifactId>commons-loggingartifactId>
            <version>1.2version>
        dependency>

    dependencies>

项目结构：

Shiro 支持 INI 格式来构建SecurityManager对象及其组件，在本案例中将使用[users]小节，定义一组静态的用户账户。

[users]
wzz = 123456abc
zyy = 87667

Main 的完整代码如下，我将分块分析这部分代码：

import org.apache.shiro.SecurityUtils;
import org.apache.shiro.authc.AuthenticationException;
import org.apache.shiro.authc.UsernamePasswordToken;
import org.apache.shiro.config.IniSecurityManagerFactory;
import org.apache.shiro.mgt.SecurityManager;
import org.apache.shiro.subject.Subject;
import org.apache.shiro.util.Factory;

public class Main {
    public static void main(String[] args) {
        Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
        SecurityManager securityManager = factory.getInstance();
        SecurityUtils.setSecurityManager(securityManager);

        UsernamePasswordToken wzzToken = new UsernamePasswordToken("wzz", "123456abc"); // 密码正确
        wzzToken.setRememberMe(true);
        UsernamePasswordToken zyyToken = new UsernamePasswordToken("zyy", "1111"); // 密码错误
        
        Subject subject = SecurityUtils.getSubject();
        try {
            subject.login(wzzToken);
            System.out.println("wzz 身份验证成功");
        } catch (AuthenticationException e) {
            System.out.println("wzz 身份认证失败");
        } finally {
            subject.logout();
        }

        try {
            subject.login(zyyToken);
            System.out.println("wzz 身份验证成功");
        } catch (AuthenticationException e) {
            System.out.println("zyy 身份认证失败");
        }finally {
            subject.logout();
        }
    }
}

Step 0：依据 INI 配置构建 SecurityManager

Shiro 支持 INI 格式来构建SecurityManager对象及其支持组件。INI 易于阅读，易于配置，易于设置，非常适合大多数应用程序。INI 配置文件可以从文件系统、类路径或 url 中获取，前缀分别为file:、classpath:或url:。
案例中 INI 配置文件位于 resources 目录下，即从类路径加载，通过IniSecurityManagerFactory实例可以根据配置生成SecurityManager实例，通过SecurityUtils.setSecurityManager注册为全局安全管理器。

import org.apache.shiro.SecurityUtils;
import org.apache.shiro.util.Factory;
import org.apache.shiro.mgt.SecurityManager;
import org.apache.shiro.config.IniSecurityManagerFactory;

...

Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);

Step1：收集用户身份和凭证

UsernamePasswordToken wzzToken = new UsernamePasswordToken("wzz", "123456abc");
wzzToken.setRememberMe(true);

1. UsernamePasswordToken是最常用的身份认证 token，使用该 token 可以绑定用户名和密码。用户密码可以通过多种方式传递给应用（例如：web 表单、HTTP 头、命令行）。在Shiro中，如何获取它们并不重要——它与协议无关。
2. setRememberMe()：使应用在用户返回后能记住用户身份。
   
   

Step2：提交身份、凭证给认证系统

收集了用户提交的 token 中的信息，并设置记住用户身份后，下一步是将 token 交给认证系统。在 Shiro 中，Realm组件负责：

• 查询存储在持久层（如：数据库）中的账户信息；
• 与提交的 token 中的 principal 和 credential 相互比较；

换句话来说，Realm实例就是 Shiro 中用于安全领域针对特定数据源的数据访问对象（DAO）。

        Subject subject = SecurityUtils.getSubject(); // (1)
        try {
            subject.login(wzzToken);  //(2)
            System.out.println("wzz 身份验证成功");
        } catch (AuthenticationException e) { // （3）
            System.out.println("wzz 身份认证失败");
        } finally {
            subject.logout(); // (3)
        }

标记(1)：获取当前执行线程的主题(Subject)，在 Shiro 中每个执行线程均有一个Subject实例，使用SecurityUtils.getSubject()可获取。该实例表示与系统交互的当前用户是谁，在登录前，subject 是匿名的，没有任何与它相关的身份数据。
标记(2)：有了Subject实例作为用户身份数据的表示后，调用Subject#login方法，提交 Step1 构造的令牌 wzzToken，进行身份验证。
如果login()方法调用成功，用户成功登录并与一个账户或身份相关联。从此开始，用户可以使用该应用，并在会话期间或更长时间内保持身份（因为设置了Remember Me）。
标记(3)：当用户使用完应用程序后，调用logout()执行注销操作，注销操作将关闭用户会话，并从 subject 实例中移除任何相关的身份信息。

多Realm认证序列

很多情况下，SecurityManager 管理了不止一个 Realm 实例，这引出了如下问题：

• 身份认证时，管理器会以什么顺序编排 Realm 实例，从而将 Token 逐个提交给这些 Realm，完成与【持久层中存储的身份信息】的比对。
• subject.login(token) 的成功条件是什么？
  如果只有一个 Realm，这个问题很容易回答，Realm 实例查询得到的凭证(credentials) 与提交的 Token 匹配，登录操作成功。
  如果存在多个 Realm，根据上述标准，可能出现如下场景：全部 Realm 的认证尝试均成功、部分 Realm 认证成功而剩余的 Realm 认证录失败、所有 Realm 认证尝试均失败。
  由此，我们引出 身份认证策略 AuthenticationStrategy 这一概念，根据用户指定的认证策略，安全管理器才能确定登录操作是否成功。
  
  

Shiro 身份认证流程

Shiro 与身份认证的流程分为五个步骤，涉及的相关组件如下：

步骤1：应用程序传入AuthenticationToken代表最终用户主体(principal)和凭证(credential)的构造实例。
步骤2：Subject实例（通常为DelegatingSubject实例）login方法调用SecurityManager#login，开始实际的身份验证工作。

步骤3：SecurityManager将认证工作委托给内部实例authenticator.authenticate(token)，authenticator 总是为ModularRealmAuthenticator实例，它支持将账户查询委派给Realm集合。

步骤4：如果应用中配置了不止1个Realm，ModularRealmAuthenticator实例将根据其配置的AuthenticationStrategy，使用多个Realm尝试进行身份认证。在调用 Realms 进行身份认证之前、期间和之后， AuthenticationStrategy将用于对 Realm 查询的结果作出反应。

步骤5：认证过程中，会通过Realm#supports方法判断，Realm 是否支持提交的AuthenticationToken实例。如果当前Realm 支持该令牌类型，Realm#getAuthenticationInfo方法将被调用。

为了印证上述描述并加深理解，下面展示并解说ModularRealmAuthenticator#doMultiRealmAuthentication方法：

protected AuthenticationInfo doMultiRealmAuthentication(Collection<Realm> realms, AuthenticationToken token) { // (1)
    AuthenticationStrategy strategy = getAuthenticationStrategy(); // 获取认证策略
    AuthenticationInfo aggregate = strategy.beforeAllAttempts(realms, token); // (2)

    for (Realm realm : realms) {
        try {
            aggregate = strategy.beforeAttempt(realm, token, aggregate); // (3)
        } catch (ShortCircuitIterationException shortCircuitSignal) {
            // Break from continuing with subsequnet realms on receiving 
            // short circuit signal from strategy
            break;
        }

        if (realm.supports(token)) { // (4)
            AuthenticationInfo info = null;
            Throwable t = null;
            try {
                info = realm.getAuthenticationInfo(token); // (5)
            } catch (Throwable throwable) {
                t = throwable;
            }

            aggregate = strategy.afterAttempt(realm, token, info, aggregate, t); // (6)
        }
    }

    aggregate = strategy.afterAllAttempts(token, aggregate); // (7)
    return aggregate;
}

注释(1)：入参 realms 为应用配置的Realm实例集合，token 一般为用户登录的 id 和密码 (或令牌)；
注释(2)、(3)、(6)、(7)：AuthenticationStrategy提供的扩展点，用于在使用 Realm 集合中的实例查询账户信息的各个阶段，处理 Realm 返回结果。（分别是：开始身份认证前[2]、特定的Realm查询前[3]、特定的Realm实例查询完成后[6]、完成身份认证后[7] ）。下面我以AtLeastOneSuccessfulStrategy为例，简略介绍四个扩展点的实现：

• beforeAllAttempts：实例化SimpleAuthenticationInfo并返回。
• beforeAttempt：直接返回 aggregate，不做处理。
• afterAttempt：如果聚合的认证信息 aggregateInfo 为空，初始化为 singleRealmInfo；如果非空，使用MergableAuthenticationInfo#merge合并多个Realm实例返回的认证信息。
  
• afterAllAttempts：如果 aggregate 中至少包含一个账户(principal)信息，则返回 aggregate；否则，抛出AuthenticationException。这里可以看出，该认证策略要求用户提交的 Token 至少要在一个 Realm 实例通过认证，才能认定登录操作成功。

注释(4)：supports方法判断 token 是否为Realm实例支持的类型。本质是调用应用实现的getAuthenticationTokenClass()方法。

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

注释(5)：调用Realm#getAuthenticationInfo查询身份认证信息，并与提交的 Token 匹配，返回值为AuthenticationInfo类型。

AuthenticationStrategy

当为应用程序配置两个以上 Realm 时，ModularRealmAuthenticator依赖内部的AuthenticationStrategy组件来确定身份验证尝试成功或失败的条件。
AuthenticationStrategy组件是无状态的，在身份认证过程中，会在如下四个阶段被使用：

1. 在调用任何 Realm 之前；
2. 在调用单个 Realm 的 getAuthenticationInfo 方法之前；
3. 在调用单个 Realm 的 getAuthenticationInfo 方法之后立即调用；
4. 在调用了所有 Realm 之后；

另外，AuthenticationStrategy负责聚合来自每个成功Realm的结果，并将它们合并到单个AuthenticationInfo实例中。这个最终的聚合 AuthenticationInfo 实例是由 Authenticator 实例返回的，Shiro 最终用它表示 Subject 实例的身份信息。

Shiro有 3 个具体的AuthenticationStrategy实现:

• AtLeastOneSuccessfulStrategy：如果至少一个 Realm 认证成功，总体的尝试被认为是成功的。如果没有任何 Realm 认证成功，尝试失败。
• FirstSuccessfulStrategy：只有从第一个成功验证的 Realm 返回的信息才会被使用。所有其他领域都将被忽略。如果没有认证成功，则尝试失败。
• AllSuccessfulStrategy：所有配置的 Realm 必须通过身份验证才能被认为是成功的。如果任何一个身份验证不成功，则尝试失败。

ModularRealmAuthenticator默认使用AtLeastOneSuccessfulStrategy策略：

如果要更换为FirstSuccessfulStrategy策略，可在 shiro.ini 中进行如下配置：

[main]
authStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy
securityManager.authenticator.authenticationStrategy = $authStrategy

配置Realms认证策略

当执行身份验证尝试时，ModularRealmAuthenticator将迭代遍历Collection，对于支持提交的 AuthenticationToken 的每个 Realm，调用 Realm#getAuthenticationInfo 方法。
应用程序可以通过 shiro.ini 配置 Realm 执行的顺序：

• 隐式顺序：Realm 实例将按照 ini 文件中定义的顺序被调用。

blahRealm = com.company.blah.Realm
...
fooRealm = com.company.foo.Realm
...
barRealm = com.company.another.Realm

SecurityManager按照如下顺序blahRealm->fooRealm->barRealm调用 Realm 实例尝试身份认证。

• 显式顺序：设置 SecurityManager 实例的 realms 属性，显式指定 Realm 实例调用顺序。

blahRealm = com.company.blah.Realm
...
fooRealm = com.company.foo.Realm
...
barRealm = com.company.another.Realm
securityManager.realms = $fooRealm, $blahRealm, $barRealm

本例中，Realm 调用顺序为：fooRealm-->blahRealm-->barRealm，这与声明的顺序无关。

Realm认证流程详解

在【Shiro 身份认证流程】小节中，我介绍了当用户提交 Token 后，Shiro 框架的整体认证流程，其中提到当 SecurityManager 配置了多个 Realm 实例时，认证器ModularRealmAuthenticator实例会将账户查询与匹配工作分配给 Realm 集合。

校验令牌类型

这一节，我将介绍 Realm 实例收到认证器传递的账户信息后的认证流程，在此之前先让大家看一个异常：

java.lang.RuntimeException: org.apache.shiro.authc.pam.UnsupportedTokenException: Realm [cn.wzz.gateway.authorization.GatewayAuthorizingRealm@6b09bb57] does not support authentication token [cn.wzz.gateway.authorization.GatewayAuthorizingToken@6536e911].  
Please ensure that the appropriate Realm implementation is configured correctly or that the realm accepts AuthenticationTokens of this type.

注意到异常描述Realm does not support authentication token[GatewayAuthorizingToken]，这个异常出现的原因为 GatewayAuthorizingToken 类型不被当前配置的 GatewayAuthorizingRealm 支持。


在使用 Realm 实例尝试身份认证前，它的 supports 方法会被调用，只有当 supports 返回true时，realm.getAuthenticationInfo(token)方法才会调用。
Realm 会使用 supports 检查提交的 token 的类型，判断是否能处理该类型的令牌。如果某个 Realm 实例用于认证生物特征信息（指纹、刷脸等），它很可能不能理解UsernamePasswordToken（用户名+密码），这种情况下会返回false。

解决措施：
方案一：在GatewayAuthorizingRealm中重写 supports 方法，supports方法用于检验当前 Realm 是否能处理某个类型的 token 实例。

方案二：重写getAuthenticationTokenClass()方法，配置该 Realm 处理的令牌类型。

// 配置Realm支持的Token类型, supports方法会校验
@Override
public Class<?> getAuthenticationTokenClass() {
    return GatewayAuthorizingToken.class;
}

处理支持的令牌类型

如果 Realm 支持认证提交的令牌类型，Authenticator 将调用 Realm 的getAuthenticationInfo(token) 方法，该方法的步骤如下：

1. 检查 token 标识的 principal 信息，例如：获取账户 id；
2. 基于 principal，利用数据源查询对应的账户数据。
3. 确保 token 中提供的 credentials 与存储在数据源中的账户信息匹配，例如：验证登录密码的正确性。
4. 如果 credentials 匹配，返回一个AuthenticationInfo实例，该实例以 Shiro 理解的格式封装帐户数据。
5. 如果 credentials 不匹配，抛出AuthenticationException异常。

直接实现 Realm 接口可能既耗时又容易出错，通常只需要实现AuthorizingRealm抽象类的子类，这个类实现了常见的身份验证和授权工作流。

`org.apache.shiro.realm.AuthenticatingRealm`抽象类的 getAuthenticationInfo 方法按照上述算法模板进行实现：

1. getCachedAuthenticationInfo：尝试从缓存中获取账户数据 AuthenticationInfo；
2. doGetAuthenticationInfo：若缓存中没有账户数据，则去对应的数据源查询，该方法是抽象的，继承该抽象类的实现类负责实现。
3. cacheAuthenticationInfoIfPossible：查询到账户数据后，如果开启了账户数据缓存则缓存账户数据。
4. assertCredentialsMatch：利用 Realm 绑定的 credentialsMatcher 执行凭证匹配，若匹配失败，抛出 IncorrectCredentialsException。

凭证匹配

将【用户提交的凭证 Credential 】与【存储在 Realm 的后台数据存储中的凭证】匹配是每个 Realm 的责任，因为每个 Realm 都熟悉特定的凭证格式和存储方式，而Authenticator是一个通用的工作流组件。
AuthenticatingRealm及其子类支持使用CredentialsMatcher 执行凭证比较，在查询到账户数据后，用户提交的 AuthenticationToken 和 数据源存储的账户数据 AuthenticationInfo 会被传递给 doCredentialsMatch 执行匹配。

Shiro 提供的 CredentialsMatcher 实现：SimpleCredentialsMatcher与HashedCredentialsMatcher。

SimpleCredentialsMatcher

Shiro 所有开箱即用的Realm实现默认使用 SimpleCredentialsMatcher，例如抽象类AuthenticatingRealm.credentialsMatcher就是 SimpleCredentialsMatcher 类型：

如果提交的是 UsernamePasswordToken，那么SimpleCredentialsMatcher将提交的 账户密码与数据库中存储的凭证精确匹配。（注：任何可以转换为字节数组的 credential 均可以使用 SimpleCredentialsMatcher 完成匹配工作）

HashedCredentialsMatcher

存储最终用户的凭据(例如密码)的一种更安全的方式是，在将它们存储到数据存储中之前，先对它们进行单向散列，而不是以原始形式存储凭据并执行原始/普通比较。这确保了没有人能知道账户原始的凭证。
Shiro 提供HashedCredentialMatcher为加密散列策略提供支持，匹配过程如下：

1. 对用户登录时提供的 AuthenticationToken 执行散列操作；
2. 将散列后的 credentials 与数据源中获取的 AuthenticationInfo.credentials 比较。注意：数据源获取的 credentials 必须是散列后的凭证。
3. 如果这两个值相等，则提交的 credentials 匹配。

保存用户登录凭证的更安全方式：对用户密码加盐(salt)，并执行多次散列迭代。

salt 应该在用户账户创建时随机生成，这个安全数字不能被散播给用户，必须保持私密。

用于散列 credential 的任何盐都将从存储的帐户信息 (AuthenticationInfo实例) 中获得。这样更安全，因为盐值对应用程序来说是私有的。

• 为了启用这一机制，Realm应该返回 SaltedAuthenticationInfo 实例，随后 HashedCredentialsMatcher 将利用其提供的 credentialsSalt 执行散列。（通过 getCredentialsSalt 方法获取）
• 如果在持久化到数据存储之前多次散列 credential，则还需要设置该类的 hashIterations 属性。

自定义 Realm 案例

下面，我以一个 Demo 来演示如何使用加盐后多次散列的方式对用户的账号/密码进行身份认证，这里我选择Sha256CredentialsMatcher作为HashedCredentialsMatcher的实现类。

shiro.ini 配置：
因为存储在持久层的用户密码是经过了加盐 + 多次 SHA-256 散列得到的，因此需要配置 Shiro 使用适当的 HashedCredentialsMatcher 来匹配【用户提交的凭证】与【数据库查询的凭证】。
在本例中，我创建一个随机盐并执行1024次哈希迭代，以获得较强的安全性，INI 配置如下：

[main]
# 使用SHA256作为哈希算法, 对原始 credential 执行散列操作
credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher
# 使用Base64编码 credential 散列后的字符粗
credentialsMatcher.storedCredentialsHexEncoded = false
# 多次对 credential 执行散列操作
credentialsMatcher.hashIterations = 1024

# 配置自定义Realm
myRealm = cn.wzz.demo.realms.MyRealm
myRealm.credentialsMatcher = $credentialsMatcher

自定义 MyRealm：
accountMap模拟账户数据库，用户登陆时， 查询数据库获取账户数据。如果不存在 principal 对应的账户，执行账户创建流程。

• 首先利用随机数生成器SecureRandomNumberGenerator为新账户生成 salt。
• 随后，对用户提交的凭证加盐，并使用 SHA256 算法执行 1024 次散列迭代，得到 Base64 字符串作为持久存储（数据库）中的凭证 hashedPwdBase64 。
• 最后将 salt、principal、hashedPwdBase64 记录到 Account 对象，并插入数据库。

import org.apache.shiro.authc.AuthenticationException;
import org.apache.shiro.authc.AuthenticationInfo;
import org.apache.shiro.authc.AuthenticationToken;
import org.apache.shiro.authc.SimpleAuthenticationInfo;
import org.apache.shiro.crypto.SecureRandomNumberGenerator;
import org.apache.shiro.crypto.hash.Sha256Hash;
import org.apache.shiro.realm.AuthenticatingRealm;
import org.apache.shiro.util.ByteSource;
// ...

public class MyRealm extends AuthenticatingRealm {

    private final Map<Object , Account> accountMap = new HashMap<>();

    @Override
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
        Object principal = token.getPrincipal();
        // credential是原始密码加盐后经过多轮哈希后生成的字符粗
        Account account = accountMap.get(principal);

        if(account == null) {
            SecureRandomNumberGenerator generator = new SecureRandomNumberGenerator();
            ByteSource salt = generator.nextBytes();
            // credential加盐后经过多次散列后, 经过Base64编码的字节数组
            String hashedPwdBase64 = new Sha256Hash(token.getCredentials(), salt, 1024).toBase64();
            account = new Account(((String) principal), hashedPwdBase64, salt);

            accountMap.put(principal, account);
        }
        System.out.println("查询到账户信息: " + account);

        // 返回SaltedAuthenticationInfo实例
        return new SimpleAuthenticationInfo(principal, account.getHashedPwdBase64(), account.getSalt(), getName());
    }
}

需要注意的是，doGetAuthenticationInfo 需要返回 SaltedAuthenticationInfo 类型的实例而不是普通的AuthenticationInfo，SaltedAuthenticationInfo实例可以提供创建用户帐户时的盐给HashedCredentialsMatcher使用。
HashedCredentialsMatcher需要盐，以便对提交的AuthenticationToken执行相同的散列散列，以查看令牌是否与保存在数据存储中的令牌匹配。