本文基于shiro 认证框架分析登录逻辑中是如何进行用户识别认证的，文章会涉及到shiro 的CacheManager、SessionManager、多Realm的Strategy认证策略等的配置，相信会让刚接触到shiro框架的老哥们能快速上手去配置自定义的一些内容。
1、开始执行登录，由Subject提交登录请求
Subject subject = SecurityUtils.getSubject();
UsernamePasswordToken token = new UsernamePasswordToken(loginVO.getLoginName(), loginVO.getPassword());
if(!subject.isAuthenticated()){
try{
subject.login(token);
doSth...
}catch (Exception e){
doSth...
}
}
2、subject中转叫给对应的securityManager执行登录
图1
3、securityManager利用本身的 Authenticator 认证器进行认证。而Authenticator对象本身是一个接口，它使用的是主要抽象类AbstractAuthenticator中的 authenticate(token) 方法，然后这个方法中再调用抽象方法的doAuthenticate(token)去实现认证。实际的认证逻辑就是转交到了它们的实现类中去写认证逻辑，可以根据这一点自定义实现类改变一些认证原理。
在我们没有自定义去实现Authenticator的情况下，系统自动调用了认证器默认的实现类ModularRealmAuthenticator去处理这个逻辑。接下来还是回去跟踪这个默认实现类去理解。
图2
4、接下来是跟踪上面默认实现类的doAuthenticate认证方法，代码如下。
图3
这个方法很重要，它决定了我们将要如何去使用我们定义的Realm数据源去匹配数据，以及多Realm的情况下，如何配置认证策略。
代码第二句是获取所有的Realm。这个Realm是我们自定义设置的，看方法逻辑是从本身的Authenticator 对象中的一个属性获取内容。通常情况下，我实现单Realm的认证，可以直接使用securityManager.setRealm( Realm realm)方法，它的内部逻辑帮助我们将realm塞到了当前Authenticator 对象中。但是在多Realm数据源的情况下，上述方法显然不满足我们集合的需求。此时我们自己去修改ModularRealmAuthenticator，示例如下（最后需要将该authenticator设置到SecurityManager中）
@Bean
protected Authenticator authenticator(){
ModularRealmAuthenticator authenticator = new ModularRealmAuthenticator();
FirstSuccessfulStrategy strategy = new FirstSuccessfulStrategy();
HashSet<Realm> realmSet = new HashSet<Realm>();
realmSet.add(realm());
// 同时设置相关的realm 和 strategy
authenticator.setRealms(realmSet);
authenticator.setAuthenticationStrategy(strategy);
return authenticator;
}
上述代码中提到的策略是说在多Realm环境下的认证逻辑限制，包含以下三种情况。用户可自定义选择某一种使用
FirstSuccessfulStrategy 只要有一个成功即可，返回第一个成功的信息
AtLeatOneSuccessfulStrategy 只要有一个成功即可,返回所有成功了的信息
AllSuccessfulStrategy 所有Realm验证成功才算成功，且返回所有Realm身份认证成功的认证信息
5、假设目前的环境是单Realm的情况。用户在在定义Realm的时候，一般实现的接口都是AuthenticatingRealm。
实现验证的过程也是需要从Realm的doGetAuthenticationInfo()方法中获取 AuthoricationInfo对象。登录的验证实际山就是AuthoricationInfo和用户传入的Token对象进行对比验证。
具体对比是使用this.assertCredentialsMatch(token, info); 这个调用的方法去实现的。如果在对比过程中发现一些不一致的内容，它就会自动抛出一些异常。
顺带一提，本人在一些shiro教程的博客里面，看到博主在自定义Realm的时候就对一些password作对比判断，个人觉得这样做有点偏离了初衷，但是实际上效果也会差不多，只不过需要用户在密码等内容不正确的时候返回null即可。
图4
6、从图4中可以看出来，我们在使用this.doGetAuthencationInfo(token)获取AuthencationInfo认证信息之前，有一步从缓存获取的操作，这个操作很重要。我们可不能每次都要求shiro去数据库查询用户认证信息，这给予数据库的压力太大了。因此在研究一下Cache缓存内容。
很容易能够看出来，我们要实现缓存首先需要实现一个接口 org.apache.shiro.cache.Cache<K, V>接口即可。Cache的植入有两种方式：（A 的优先级高于 B 的）
Ａ) 在之前的自定义Realm中再通过重写setAuthenticationCache()方法将Cache<K, V>注入到Realm中即可。
B）当然还有另外一种方式获取Cache，在Realm本身是没有Cache对象的时候，可以默认从CacheManager对象中获取一个Cache对象。因此我们还可以自定义实现一个CacheManager接口的类，这个类需要实现一个getCache的方法，返回的也是Cache<K, V>。 在实现了CacheManager将它注入到SecurityManager中即可。
图5
图6 Cache.jpg
7、认证成功以后，返回AuthenticationInfo对象一直回到SecurityManager中。并利用传入的token，以及info等，利用SubjectContext上下文存储的内容构建最新的Subject，将subject的登录状态改为 true，并将info和token都存储进去。最后返回最后更新了状态的Subject
图7
8、在然后有一个onSuccessfulLogin(token, info, loggedIn) 方法。它主要是处理RememberMe相关的内容。首先获取SecurityManager中封装的属性RememberMeManager。这个对象执行onSuccessfulLogin()方法的逻辑，会先forgetIdentity(subject)清除掉原本有的信息，然后判断token中是否有rememberMe属性的存在，或是这个属性应该是true值。因此在我们在登陆时候，应该封装Token的时候给rememberMe这个属性赋值。
最后再执行 this.rememberIdentity(subject, token, info) 这个方法储存登陆信息
图8
9、自定义继承AbstractRememberMeManager类需要实现四个方法。而Shiro已经为我们提供了一个可以直接使用的CookieRememberMeManager的实现类，我们可以直接将它注入到SecurityManager中。
10、之后返回到了DelegatingSubject类，验证了返回Subject之后继续后面的逻辑。
PrincipalCollection对象应该是封装到Subject中的通过不同策略的返回的身份集合
Session session = subject.getSession(false);
图9
Subject对象的Session属性本身是在SecurityUtils.getSubject(); 方法创建 Subject对象的时候就已经从SessionManager中创建了Session对象并封装。（如果之前本身没有Session，可以通过getSession() 方法，它里面会自动使用SessionManager 创建一个Session出来。因此SessionManager 也是可以自定义实现的）
11、SessionManager 会话管理
图10
AbstractSessionDAO提供了SessionDAO的基础实现，如生成会话ID等；CachingSessionDAO提供了对开发者透明的会话缓存的功能，只需要设置相应的CacheManager即可；MemorySessionDAO直接在内存中进行会话维护；EnterpriseCacheSessionDAO提供了缓存功能的会话维护，默认情况下使用MapCache实现，内部使用ConcurrentHashMap保存缓存的会话。
Shiro会话管理SessionManager
SecurityUtils.getSubject() 方法创建Subject对象时，会先创建一个SubjectContext 对象，然后将SecurityManager Session（利用SessionManager获取） 和PrincipalCollection 三个对象封装进了SubjectContext ，再使用工厂类getSubjectFactory创建出subject 对象，即shiro中的Client端。
图11
首先SecurityManager是需要我们自己定义的，定义成Bean后自动装载；
Session：Session 则是从SubjectContext 中获取或者利用SubjectContext 中的sessionId 从SessionManager中获取已有的。第一次创建自然是两个地方都不会存在，因此此时session还是为null
PrincipalCollection 则是先按照顺序依次从SubjectContext、Subject、Session和RememberMe中获取，因为是第一次创建，这些内容还没有，还是为null
下面的 save 方法，则是调用DefaultSecurityManager 中 subjectDAO （默认使用实现类DafaultSessionDAO）保存会话。主要是想要将已经储存的用户信息和认证信息存储到会话中。
网友评论