Shiro技术的整合

很久不用shiro权限框架了，感觉有点手生了，现打算从网上把一些知识点做个整合，便于以后自己查阅和很快的熟悉起来。

1）shiro的简单介绍
一、什么是Shiro
Apache Shiro是一个强大易用的Java安全框架，提供了认证、授权、加密和会话管理等功能：
认证 - 用户身份识别，常被称为用户“登录”；
授权 - 访问控制；
密码加密 - 保护或隐藏数据防止被偷窥；
会话管理 - 每用户相关的时间敏感的状态。

使用Shiro的时候我们主要考虑在什么样的环境下使用：
1）登录的验证
2）对指定角色的验证
3）对URL的验证
基本上我们也就这三个需求，所以同时我们也需要三个方法：

1.1）findUserByUserName(String username)根据username查询用户，之后Shiro会根据查询出来的User的密码来和提交上来的密码进行比对。
1.2）findRoles(String username)根据username查询该用户的所有角色，用于角色验证。
1.3）findPermissions(String username)根据username查询他所拥有的权限信息，用于权限判断。

2）shiro架构的介绍
首先从外部来看shiro,主要分为三个核心组件:
Subject,SecurityManager,Realms

可以看到：应用代码直接交互的对象是Subject，也就是说Shiro的对外API核心就是Subject；其每个API的含义：
Subject：主体，代表了当前“用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是Subject，如网络爬虫，机器人等；即一个抽象概念；所有Subject都绑定到SecurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认为是一个门面；SecurityManager才是实际的执行者；
SecurityManager：安全管理器；即所有与安全有关的操作都会与SecurityManager交互；且它管理着所有Subject；可以看出它是Shiro的核心，它负责与后边介绍的其他组件进行交互，如果学习过SpringMVC，你可以把它看成DispatcherServlet前端控制器；
Realm：域，Shiro从从Realm获取安全数据（如用户、角色、权限），就是说SecurityManager要验证用户身份，那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以把Realm看成DataSource，即安全数据源

也就是说对于我们而言，最简单的一个Shiro应用：
1、应用代码通过Subject来进行认证和授权，而Subject又委托给SecurityManager；
2、我们需要给Shiro的SecurityManager注入Realm，从而让SecurityManager能得到合法的用户及其权限进行判断。

从以上也可以看出，Shiro不提供维护用户/权限，而是通过Realm让开发人员自己注入。

然后我们从shiro内部来看下shiro的架构，如下图:

Subject：主体，可以看到主体可以是任何可以与应用交互的“用户”；
SecurityManager：相当于SpringMVC中的DispatcherServlet或者Struts2中的FilterDispatcher；是Shiro的心脏；所有具体的交互都通过SecurityManager进行控制；它管理着所有Subject、且负责进行认证和授权、及会话、缓存的管理。
Authenticator：认证器，负责主体认证的，这是一个扩展点，如果用户觉得Shiro默认的不好，可以自定义实现；其需要认证策略（Authentication Strategy），即什么情况下算用户认证通过了；
Authrizer：授权器，或者访问控制器，用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能；
Realm：可以有1个或多个Realm，可以认为是安全实体数据源，即用于获取安全实体的；可以是JDBC实现，也可以是LDAP实现，或者内存实现等等；由用户提供；注意：Shiro不知道你的用户/权限存储在哪及以何种格式存储；所以我们一般在应用中都需要实现自己的Realm；
SessionManager：如果写过Servlet就应该知道Session的概念，Session呢需要有人去管理它的生命周期，这个组件就是SessionManager；而Shiro并不仅仅可以用在Web环境，也可以用在如普通的JavaSE环境、EJB等环境；所有呢，Shiro就抽象了一个自己的Session来管理主体与应用之间交互的数据；这样的话，比如我们在Web环境用，刚开始是一台Web服务器；接着又上了台EJB服务器；这时想把两台服务器的会话数据放到一个地方，这个时候就可以实现自己的分布式会话（如把数据放到Memcached服务器）；
SessionDAO：DAO大家都用过，数据访问对象，用于会话的CRUD，比如我们想把Session保存到数据库，那么可以实现自己的SessionDAO，通过如JDBC写到数据库；比如想把Session放到Memcached中，可以实现自己的Memcached SessionDAO；另外SessionDAO中可以使用Cache进行缓存，以提高性能；
CacheManager：缓存控制器，来管理如用户、角色、权限等的缓存的；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能
Cryptography：密码模块，Shiro提高了一些常见的加密组件用于如密码加密/解密的。

3)shiro的认证机制
认证就是验证用户身份的过程。在认证过程中，用户需要提交实体信息(Principals)和凭据信息(Credentials)以检验用户是否合法。最常见的“实体/凭证”组合便是“用户名/密码”组合。
一、Shiro认证过程
1、收集实体/凭据信息

//Example using most common scenario of username/password pair:  UsernamePasswordToken token = new UsernamePasswordToken(username, password);  //”Remember Me” built-in:  token.setRememberMe(true);  

UsernamePasswordToken支持最常见的用户名/密码的认证机制。同时，由于它实现了RememberMeAuthenticationToken接口，我们可以通过令牌设置“记住我”的功能。
但是，“已记住”和“已认证”是有区别的：
已记住的用户仅仅是非匿名用户，你可以通过subject.getPrincipals()获取用户信息。但是它并非是完全认证通过的用户，当你访问需要认证用户的功能时，你仍然需要重新提交认证信息。
这一区别可以参考亚马逊网站，网站会默认记住登录的用户，再次访问网站时，对于非敏感的页面功能，页面上会显示记住的用户信息，但是当你访问网站账户信息时仍然需要再次进行登录认证。

2.提交实体/凭据信息

Subject currentUser = SecurityUtils.getSubject();  currentUser.login(token); 

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

3.认证处理

try {      currentUser.login(token);  } catch ( UnknownAccountException uae ) { ...  } catch ( IncorrectCredentialsException ice ) { ...  } catch ( LockedAccountException lae ) { ...  } catch ( ExcessiveAttemptsException eae ) { ...  } ... catch your own ...  } catch ( AuthenticationException ae ) {      //unexpected error?  }  

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

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

如上图，我们通过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方法来编写我们自定义的认证处理。

源码分析shiro认证授权流程：https://www.cnblogs.com/davidwang456/p/4428421.html（参考）