电子公文传输系统团队冲刺第四天
——Apache Shrio
一、概述
Apache Shiro是一个功能强大且易于使用的Java安全框架，为开发人员提供了一个直观而全面的解决方案，用于身份验证、授权、加密和会话管理。
实际上，它实现了管理应用程序安全性的所有方面，同时尽可能避免出现问题。它建立在完善的接口驱动设计和面向对象的原则之上，可以在任何你想象得到的地方实现自定义行为。
二、Apache Shiro的特性
Shiro聚焦与应用程序安全领域的四大基石：认证、授权、会话管理和保密。
- 认证：也叫作登录，用于验证验证用户是不是拥有相应的身份；
- 授权：也就是访问控制，验证某个已认证的用户是否拥有某个权限，即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。
- 会话管理：管理用户相关的会话，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中。会话可以是普通 JavaSE 环境的，也可以是如 Web 环境的，即使在非web和ejb的环境下也支持。
- 加密：使用特性加密算法来保证用户数据的安全性，同时还要保证用起来够简单；
同时Shiro还提供了其他特性来在不同的应用程序环境下使用强化以上的四大基石：
- Web支持：Shiro的web相关的API简化了web应用安全控制；
- 缓存：在Shiro中，缓存是一等公民，用于保证用户认证和权限控制的性能；
- 测试：支持可测试性，以便用户可以方便的对安全相关代码编写单元测试和集成测试；
- 记住密码：可以跨会话的记住用户的身份信息，以便只有在一些强制性的场合才需要登录。
- 记住一点，Shiro 不会去维护用户、维护权限；这些需要我们自己去设计 / 提供；然后通过相应的接口注入给 Shiro 即可。
三、Shrio的架构
我们分别从外部和内部来看看 Shiro 的架构，对于一个好的框架，从外部来看应该具有非常简单易于使用的 API，且 API 契约明确；从内部来看的话，其应该有一个可扩展的架构，即非常容易插入用户自定义实现，因为任何框架都不能满足所有需求。
首先，我们从外部来看 Shiro 吧，即从应用程序角度的来观察如何使用 Shiro 完成工作。
可以看到，应用代码直接交互的对象是 Subject，也就是说 Shiro 的对外 API 核心就是 Subject；其每个 API 的含义如下：
Subject：主体，代表了当前 “用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是 Subject，如网络爬虫，机器人等，这是一个抽象概念。所有 Subject 都绑定到 SecurityManager，与 Subject 的所有交互都会委托给 SecurityManager。可以把 Subject 认为是一个门面，SecurityManager 才是实际的执行者。
SecurityManager：安全管理器，即所有与安全有关的操作都会与 SecurityManager 交互，且它管理着所有 Subject。可以看出它是 Shiro 的核心，它负责与后边介绍的其他组件进行交互。
Realm：域，这是用于连接Shiro和客户系统的用户数据的桥梁。一旦Shiro真正需要访问各种安全相关的数据（比如使用用户账户来做用户身份验证以及权限验证）时，他总是通过调用系统配置的各种Realm来读取数据。就是说 SecurityManager 要验证用户身份，那么它需要从 Realm 获取相应的用户进行比较以确定用户身份是否合法；也需要从 Realm 得到用户相应的角色 / 权限进行验证用户是否能进行操作。正因为如此，Realm往往被看做是安全领域的DAO，他封装了数据源连接相关的细节，将数据以Shiro需要的格式提供给Shiro。当我们配置Shiro的时候，我们至少需要配置一个Realm来提供用户验证和权限控制方面的数据。我们可能会给SecurityManager配置多个Realm，但是不管怎样，我们至少需要配置一个。
也就是说对于我们而言，最简单的一个 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 提高了一些常见的加密组件用于如密码加密 / 解密的。
四、Shrio中的过滤器
当 Shrio 被运用到 Web 项目时，会自动创建一些默认的过滤器对客户端请求进行过滤。以下是Shiro 提供的过滤器：
注意：anon，authcBasic，auchc，user 是认证过滤器。
perms，roles，ssl，rest，port 是授权过滤器。
过滤器链：
五、Shrio基础配置
users用户：
- ini 配置：ini 实际上是一个文本配置，包含了由唯一命名的项来组织的键/值对。
- [users] 部分允许定义一组静态的用户帐户
- 每行的格式：
username = password, roleName1, roleName2, …
roles角色：
- 一个命名的实体， 通常代表一组行为或职责。 这些行为演化为在一个应用中能或者不能做的事情。角色通常分配给用户帐户。一个角色拥有一个权限的集合。授权验证时，需要判断当前角色是否拥有指定的权限。这种角色权限可以对该角色进行详细的权限描述。
- [roles] 部分允许把定义在 [users] 部分中的角色与权限关联起来
- 每行的格式：
rolename = permissionDefinition1, permissionDefinition2, …（permissionDefinition 是一个任意的字符串）
- 如果角色不想关联权限，则不需要在 [roles] 部分把它们列出来。只需定义在 [user] 部分中定义角色名就足以创建尚不存在的角色。
- 仅定义非空的 [users] 或 [roles] 部分就将自动地触发org.apache.shiro.realm.text.IniRealm 实例的创建。
permission权限：
- Shiro 安全机制最核心的元素。它在应用程序中明确声明了被允许的行为。一个格式良好的权限声明可以清晰表达出用户对该资源拥有的权限。在 Shiro 中主要通过通配符表达式来完成权限的描述
引入shrio依赖
shiro在springboot项目中的位置：
六、Shrio的具体实现内容
（一）Shrio认证
通过提交用户的身份和凭证给 Shiro，以判断它们是否和应用程序预期的相匹配。
基本概念：
- Principals(身份)：Subject 的标识属性，比如我们登录提交的用户名。
- Credentials(凭证)：用来作为一种起支持作用的证据，比如我们登录提供的密码。
认证的基本步骤：
- 收集Subjects 提交的Principals(身份)和Credentials(凭证)；
- 提交Principals(身份)和Credentials(凭证)进行身份验证；
- 如果提交成功，则允许访问，否则重新进行身份验证或者阻止访问。
- AuthenticationToken：Shiro 中代表提交的 Principals(身份) 和 Credentials (凭证) 的身份验证系统的最基本接口。
- UsernamePasswordToken ：AuthenticationToken 的接口的实现类，支持最常见的用户名/密码的身份验证
认证顺序：
（二）Shrio授权
控制谁有权限在应用程序中做什么，比如用户是否能访问某个网页，编辑数据，或打使用这台打印机。
授权的三要素：权限、角色和用户 。
需要在应用程序中对用户和权限建立关联：通常的做法是将权限分配给角色，然后将角色分配给一个或多个用户。
Shiro的三种授权方式：
- 编写代码：在 Java 代码中用像 if 和 else 块的结构执行授权检查。
- JDK 的注解：可以添加授权注解给 Java 方法
- JSP 标签库：可以控制基于角色和权限的JSP 页面输出。
Shiro权限基础概念：
- 安全实体：就是被权限系统保护的对象。
- 权限：就是需要被校验的行为，比如查看、修改等。
- 分配权限：把对某些安全实体的某些权限分配给某些人员。是向数据库里面添加数据、或是维护数据的过程
- 权限验证（权限匹配）：判断某个人员或程序对某个安全实体是否拥有某个或某些权限。从数据库中获取相应数据进行匹配的过程。
- 权限的继承性：如果多个安全实体存在包含关系，而某个安全实体没有权限限制，则它会继承包含它的安全实体的相应权限。
- 权限的最近匹配原则：如果多个安全实体存在包含关系，而某个安全实体没有权限限制，那么它会向上寻找并匹配相应权限限制，直到找到一个离这个安全实体最近的拥有相应权限限制的安全实体为止。如果把整个层次结构都寻找完了都没有匹配到相应权限限制的话，那就说明所有人对这个安全实体都拥有这个相应的权限限制。
授权顺序：
（三）Realms的认证实现
Shiro 的认证过程由 Realm 执行，SecurityManager 会调用 org.apache.shiro.realm.Realm 的 getAuthenticationInfo(AuthenticationToken token) 方法
实际开发中，通常会提供 org.apache.shiro.realm.AuthenticatingRealm 的实现类，并在该实现类中提供doGetAuthenticationInfo(AuthenticationToken token)方法的具体实现
- 检查提交的进行认证的×××信息
- 根据×××信息从数据源(通常为数据库)中获取用户信息
- 对用户信息进行匹配验证。
- 验证通过将返回一个封装了用户信息的 AuthenticationInfo 实例。
- 验证失败则抛出 AuthenticationException 异常信息。
