在上篇Shiro核心概念中,我们介绍了Shiro的三大核心概念:Subject
、SecurityManager
、Realms
,并通过示例代码QuickStart
展示常用的认证、鉴权、退出的操作。
本篇我们将深入到Shiro的源码中,探究Shiro底层实现认证的过程,做到“知其然知其所以然”。
1 认证原理
1.1 Principals与Credentials
认证就是进行身份确认的过程,也就是用户(对应Shiro中的Subject
)需要提供证明来证实自己的身份。就像到自动取款机取款,持有银行卡的人就可以理解为此处的用户,银行卡的取款密码就是证明材料,如果输入正确的密码,就可以进行取款。在这个过程中,有两个概念,用户和证明材料,对应Shiro中的就分别是Principals与Credentials。
1.2 认证步骤
要进行认证,我们需要先收集用户的Principals与Credentials,比如用户通过页面上的表单提交用户名和密码,APP用户通过提交手机号与短信验证码,然后交由服务端进行处理。
①服务端首先收集Principals与Credentials,对应Shiro的代码
UsernamePasswordToken token = new UsernamePasswordToken("username", "passwd");
这里我们使用Shiro中通过的用户名/密码认证方式,或者你可以实现AuthenticationToken
接口来自定义
②接下来进行提交,对应代码
Subject currentUser = SecurityUtils.getSubject();
currentUser.login(token);
③认证结果
if (currentUser.isAuthenticated()) {
// success do something
} else {
// fail throw exception
}
1.3 认证原理
在了解了Shiro认证过程的基本代码操作后,我们来看下底层是到底如何实现。首先我们先通过Shiro官方给出的一张认证流程图来作全局的了解,看看底层认证都涉及到了哪些东西。
① 获取Subject
对象,如果还不了解如何获取Subject
对象,可以回头去看下我们第一篇文章的介绍,或者下载示例代码进行了解;然后收集用户的认证资料,调用Subject
对象的login(token)
方法。
② DelegatingSubject
作为Subject
的实现,本身并不负责处理认证与授权的逻辑,而是将方法的调用传递给底层的SecurityManager
,本质上说,DelegatingSubject
只是SecurityManager
的代理类,①中login(token)
方法的调用,本质上调用调用的是SecurityManager
接口的login(token)
方法,而DefaultSecurityManager
作为SecurityManager
的默认实现,将调用Authenticator
进行认证逻辑处理
③ Authenticator
接口是Shiro API中的主要入口之一,就是用来负责应用中的认证操作的,该类作为顶级接口,只有一个authenticate(AuthenticationToken token)
方法,而ModularRealmAuthenticator
作为Shiro默认的认证处理实现类将会接过认证处理的枪,通过doAuthenticate(AuthenticationToken token)
来进行认证操作,源码如下
Collection<Realm> realms = getRealms();
if (realms.size() == 1) {
return doSingleRealmAuthentication(realms.iterator().next(), authenticationToken);
} else {
return doMultiRealmAuthentication(realms, authenticationToken);
}
④ 通过情况下应用中会使用单个的Realm来进行认证授权处理,但是强大的Shiro却支持配置多个Realm,在多个Realm对象存在的情况下,就需要指定认证策略AuthenticationStrategy
,Shiro提供了三种具体的认证策略实现
AtLeastOneSuccessfulStrategy:ModularRealmAuthenticator的默认实现,多个Realm中,如果有一个或以上认证通过,就表示认证成功
FirstSuccessfulStrategy:只使用第一个认证通过的Realm返回的信息,后面的Realm将会被忽略
AllSuccessfulStrategy:所有Realm认证通过才算认证成功,否则认证失败
⑤ 通过Realm进行认证最终的逻辑判断,我们此处以应用只存在单个Realm来进行介绍。Realm首先会通过realm.supports(token)
进行验证,验证Realm是否支持对应的token进行认证操作,如果返回true,将会进行认证逻辑处理,否则直接忽略认证逻辑,如果我们的应用只想处理授权,可以自定义Realm,并将supports方法返回false即可。
Realm会通过token与INI配置文件中的配置项进行对比,或者与我们数据库存储的数据进行对比,如果相同则认证通过。
下一小节,我们将通过IniRealm来介绍Shiro是如何进行认证逻辑判断的
1.4 IniRealm认证实现
在上篇文章中,我们提到,Shiro默认使用IniRealm,但是前提是我们在INI配置中指定了[users]或[roles]有效配置数据,否则就会用配置中指定的securityManager的realms,如果两者都没有指定那么就会抛出错误,因为Shiro应用,至少要配置一个Realm
IniRealm在初始化onInit()
时,会将已经加载的INI文件中的[users]、[roles]配置进行处理,分别转换为SimpleRole、SimpleAccount,再将SimpleAccount与SimpleRole进行绑定,至此,IniRealm对INI配置文件处理已经完毕。
但是认证的操作并没有完成,IniRealm仍需要与传递过来的token进行对比,判断是否相同,具体的判断逻辑交由AuthenticatingRealm
来进行。
1.5 AuthenticatingRealm
AuthenticatingRealm是Realm的顶级抽象实现类,主要用于处理认证操作,至于授权等操作则交由该类的子类去处理。
AuthenticatingRealm拿到token后,会先去缓存中查找是否存在对应的认证信息,如果存在直接使用缓存中的认证信息与token进行比对,如果缓存中不存在,则直接获取IniRealm中的认证信息进行比对,比对通过后,返回认证成功的Subject对象。
至此,认证的整体过程与底层逻辑已经全部介绍完毕。如果文章有什么不足之处,或者说的不正确的地方,也希望各位小伙伴们与我联系和沟通。