Apache Shiro 认证过程

骑猪看日落 2022-05-23 10:04 199阅读 0赞

**3.1.1    示例**

Shiro验证Subjects 的过程中，可以分解成三个不同的步骤：

1. 收集Subjects 提交的Principals(身份)和Credentials(凭证)；

2. 提交Principals(身份)和Credentials(凭证)进行身份验证；

3. 如果提交成功，则允许访问，否则重新进行身份验证或者阻止访问。

**收集身份/凭据信息 **

<table> 
 <tbody> 
  <tr> 
   <td> <p>//Example&nbsp;using&nbsp;most&nbsp;common&nbsp;scenario&nbsp;of&nbsp;username/password&nbsp;pair:&nbsp;&nbsp;</p> <p>UsernamePasswordToken&nbsp;token&nbsp;=&nbsp;new&nbsp;UsernamePasswordToken(username,&nbsp;password);&nbsp;&nbsp;</p> <p>//”Remember&nbsp;Me”&nbsp;built-in:&nbsp;&nbsp;</p> <p>token.setRememberMe(true);&nbsp;&nbsp;</p> </td> 
  </tr> 
 </tbody> 
</table>

UsernamePasswordToken支持最常见的用户名/密码的认证机制。同时，由于它实现了RememberMeAuthenticationToken接口，我们可以通过令牌设置“记住我”的功能。

**提交实体/凭据信息 **

<table> 
 <tbody> 
  <tr> 
   <td> <p>Subject&nbsp;currentUser&nbsp;=&nbsp;SecurityUtils.getSubject();&nbsp;&nbsp;</p> <p>currentUser.login(token);&nbsp;</p> </td> 
  </tr> 
 </tbody> 
</table>

收集了身份/凭据信息之后，我们可以通过SecurityUtils工具类，获取当前的用户，然后通过调用login方法提交认证。

**认证处理 **

<table> 
 <tbody> 
  <tr> 
   <td> <p>try&nbsp;{&nbsp;&nbsp;</p> <p>&nbsp;&nbsp;&nbsp;&nbsp;currentUser.login(token);&nbsp;&nbsp;</p> <p>}&nbsp;catch&nbsp;(&nbsp;UnknownAccountException&nbsp;uae&nbsp;)&nbsp;{&nbsp;...&nbsp;&nbsp;</p> <p>}&nbsp;catch&nbsp;(&nbsp;IncorrectCredentialsException&nbsp;ice&nbsp;)&nbsp;{&nbsp;...&nbsp;&nbsp;</p> <p>}&nbsp;catch&nbsp;(&nbsp;LockedAccountException&nbsp;lae&nbsp;)&nbsp;{&nbsp;...&nbsp;&nbsp;</p> <p>}&nbsp;catch&nbsp;(&nbsp;ExcessiveAttemptsException&nbsp;eae&nbsp;)&nbsp;{&nbsp;...&nbsp;&nbsp;</p> <p>}&nbsp;...&nbsp;catch&nbsp;your&nbsp;own&nbsp;...&nbsp;&nbsp;</p> <p>}&nbsp;catch&nbsp;(&nbsp;AuthenticationException&nbsp;ae&nbsp;)&nbsp;{&nbsp;&nbsp;</p> <p>&nbsp;&nbsp;&nbsp;&nbsp;//unexpected&nbsp;error?&nbsp;&nbsp;</p> <p>}&nbsp;&nbsp;</p> </td> 
  </tr> 
 </tbody> 
</table>

如果login方法执行完毕且没有抛出任何异常信息，那么便认为用户认证通过。之后在应用程序任意地方调用SecurityUtils.getSubject() 都可以获取到当前认证通过的用户实例，使用subject.isAuthenticated()判断用户是否已验证都将返回true。相反，如果login方法执行过程中抛出异常，那么将认为认证失败。

**3.1.2    步骤**

下面将详细介绍Shiro进行身份认证时的内部处理过程。

![1349935173_8302.JPG][]

如上图，我们通过Shiro架构图的认证部分，来说明Shiro认证内部的处理顺序：

1、应用程序构建了一个终端用户认证信息的AuthenticationToken 实例后，调用Subject.login方法。AuthenticationToken 实例中包含终端用户的Principals(身份信息)和Credentials(凭证信息)。

2、Sbuject的实例通常是DelegatingSubject类（或子类）的实例对象，在认证开始时，会委托应用程序设置的securityManager实例调用securityManager.login(token)方法。

3、SecurityManager接受到token(令牌)信息后会委托内置的Authenticator的实例（通常都是ModularRealmAuthenticator类的实例）调用authenticator.authenticate(token)。ModularRealmAuthenticator在认证过程中会对设置的一个或多个Realm实例进行适配，它实际上为Shiro提供了一个可拔插的认证机制。

4、如果在应用程序中配置了多个Realm，ModularRealmAuthenticator会根据配置的AuthenticationStrategy(认证策略)来进行多Realm的认证过程。在Realm被调用后，AuthenticationStrategy将对每一个Realm的结果作出响应。

注：如果应用程序中仅配置了一个Realm，Realm将被直接调用而无需再配置认证策略。

5、判断每一个Realm是否支持提交的token，如果支持，Realm将调用getAuthenticationInfo(token);getAuthenticationInfo 方法就是实际认证处理，我们通过覆盖Realm的doGetAuthenticationInfo方法来编写我们自定义的认证处理。

**3.1.3    配置**

**Authenticator（认证器）**

ShiroSecurityManager 的实现默认使用一个ModularRealmAuthenticator实例。它既支持单一Realm也支持多个Realm。如果仅配置了一个Realm，ModularRealmAuthenticator会直接调用该Realm处理认证信息，如果配置了多个Realm，它会根据认证策略来适配Realm，找到合适的Realm执行认证信息。

如果你想配置SecurityManager通过一个自定义的Authenticator来实现，你可以在shiro.ini 中如下设置：

<table> 
 <tbody> 
  <tr> 
   <td> <p>[main]</p> <p>…</p> <p>authenticator = com.foo.bar.CustomAuthenticator</p> <p>securityManager.authenticator = $authenticator</p> </td> 
  </tr> 
 </tbody> 
</table>

**AuthenticationStrategy（认证策略）**

当一个应用程序配置了两个或两个以上的Realm 时，ModularRealmAuthenticator 依靠内部的AuthenticationStrategy 组件来判定认证的成功或失败。

AuthenticationStrategy是一个无状态的组件，它在身份验证尝试中被询问4 次（这4 次交互所需的任何必要的状态将被作为方法参数）：

1. 在任何Realm 被调用之前被询问；

2. 在一个单独的Realm 的getAuthenticationInfo 方法被调用之前立即被询问；

3. 在一个单独的Realm 的getAuthenticationInfo 方法被调用之后立即被询问；

4. 在所有的Realm 被调用后询问。

认证策略的另外一项工作就是聚合所有Realm的结果信息封装至一个AuthenticationInfo实例中，并将此信息返回，以此作为Subject的身份信息。

Shiro中定义了3种认证策略的实现：

<table> 
 <tbody> 
  <tr> 
   <td> <p><strong>AuthenticationStrategy class</strong></p> </td> 
   <td> <p><strong>描述</strong></p> </td> 
  </tr> 
  <tr> 
   <td> <p>AtLeastOneSuccessfulStrategy</p> </td> 
   <td> <p>只要有一个（或更多）的Realm验证成功，那么认证将被视为成功</p> </td> 
  </tr> 
  <tr> 
   <td> <p>FirstSuccessfulStrategy</p> </td> 
   <td> <p>第一个Realm验证成功，整体认证将被视为成功，且后续Realm将被忽略</p> </td> 
  </tr> 
  <tr> 
   <td> <p>AllSuccessfulStrategy</p> </td> 
   <td> <p>所有Realm成功，认证才视为成功</p> </td> 
  </tr> 
 </tbody> 
</table>

ModularRealmAuthenticator内置的认证策略默认实现是AtLeastOneSuccessfulStrategy 方式，因为这种方式也是被广泛使用的一种认证策略。当然，你也可以通过配置文件定义你需要的策略，比如：

<table> 
 <tbody> 
  <tr> 
   <td> <p>[main]</p> <p>…</p> <p>authcStrategy = org.apache.shiro.authc.pam.FirstSuccessfulStrategy</p> <p>seurityManager.authenticator.authenticationStrategy = $authcStrategy</p> <p>...</p> </td> 
  </tr> 
 </tbody> 
</table>

**RealmAuthentication Order（Realm认证顺序）**

从刚才提到的认证策略可以看到Realm在ModularRealmAuthenticator里面的顺序对认证是有影响的。ModularRealmAuthenticator 会读取配置在SecurityManager里的Realm。当执行认证时，它会遍历Realm集合，对所有支持提交的token的Realm调用getAuthenticationInfo 方法。

隐式排列（ImplicitOrdering）

当使用Shiro 的INI 配置文件格式时，根据你在INI文件中定义好的顺序依次被处理。比如：

<table> 
 <tbody> 
  <tr> 
   <td> <p>blahRealm = com.company.blah.Realm</p> <p>…</p> <p>fooRealm = com.company.foo.Realm</p> <p>…</p> <p>barRealm = com.company.another.Realm</p> </td> 
  </tr> 
 </tbody> 
</table>

SecurityManager 根据这三个Realm 的配置顺序调用，依次是blahRealm，fooRealm 和barRealm顺序调用。与下面这样的效果是一样的。

<table> 
 <tbody> 
  <tr> 
   <td> <p>securityManager.realms = $blahRealm, $fooRealm, $barRealm</p> </td> 
  </tr> 
 </tbody> 
</table>

使用这种方法，你并不需要设置SecurityManager 的Realm 属性——每个定义好的realm 将会自动地被添加到realm 的属性。

显示排列（ExplicitOrdering）

明确地定义Realm的先后顺序，显式地配置securityManager.realms 的属性以表明你需要引用的Realm和它们的调用顺序。比如：

这样调用的顺序依次是fooRealm，barRealm和blahRealm。

**RealmAuthentication（Realm认证）**

Realm 实质上就是一个特定安全的DAO。Realm 通常和数据源是一对一的对应关系，如关系数据库，LDAP 目录，文件系统，或其他类似资源。

若Realm 支持一个提交的AuthenticationToken，那么Authenticator 将会调用该Realm 的getAuthenticationInfo(token)方法。这代表了一个与Realm的后备数据源的认证尝试。该方法按以下方法进行：

1. 为主要的识别信息（帐户识别信息）检查token。

2. 基于principal 在数据源中寻找相吻合的帐户数据。

3. 确保token 支持的credentials 匹配那些存储在数据源的。

4. 若credentials 匹配，返回一个封装了Shiro 能够理解的帐户数据格式的AuthenticationInfo 实例。

5. 若credentials 不匹配，则抛出AuthenticationException 异常。

在上述过程中，Realm有一个职责就是匹配提交的credentials 和那些存储在Realm 后备数据存储中的credentials。Shiro 本身拥有CredentialsMatcher 实现，如SimpleCredenticalsMatcher 和HashedCredentialsMatcher，但你也可以根据自己的逻辑自定义一个实现。比如：

<table> 
 <tbody> 
  <tr> 
   <td> <p>[main]</p> <p>…</p> <p>customMatcher = com.company.shiro.realm.CustomCredentialsMatcher</p> <p>myRealm = com.company.shiro.realm.MyRealm</p> <p>myRealm.credentialsMatcher = $customMatcher</p> <p>...</p> </td> 
  </tr> 
 </tbody> 
</table>

Shiro 中默认使用的是SimpleCredentialsMatcher，SimpleCredentialsMatcher 验证该密码是否与存储在数据库中的密码相同。SimpleCredentialsMatcher不仅仅为字符串执行直接相等比较。它能够处理大多数常用的字节码，像字符串，字符数组，字节数组，文件及输入流。

除此之外Shiro 还提供了HashedCredentialsMatcher，通过单向散列化方式实现一种更安全的方式存储终端用户的credentials。配置方式如下：

<table> 
 <tbody> 
  <tr> 
   <td> <p>[main]</p> <p>…</p> <p>credentialsMatcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher</p> <p># base64 encoding, not hex in this example:</p> <p>credentialsMatcher.storedCredentialsHexEncoded = false</p> <p>credentialsMatcher.hashIterations = 1024</p> <p># This next property is only needed in Shiro 1.0. Remove it in 1.1 and later:</p> <p>credentialsMatcher.hashSalted =true</p> <p>…</p> <p>myRealm = com.company……</p> <p>myRealm.credentialsMatcher = $credentialsMathcer</p> <p>...</p> </td> 
  </tr> 
 </tbody> 
</table>

[1349935173_8302.JPG]: https://img-my.csdn.net/uploads/201210/11/1349935173_8302.JPG