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 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 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<Realm>`，对于支持提交的 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);
给大家的福利
零基础入门
对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。
同时每个成长路线对应的板块都有配套的视频提供：
因篇幅有限，仅展示部分资料
网络安全面试题
绿盟护网行动
还有大家最喜欢的黑客技术
网络安全源码合集+工具包
所有资料共282G，朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》，可以扫描下方二维码领取（如遇扫码问题，可以在评论区留言领取哦）~
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
