Shiro权限管理

核心概念

Shiro 的体系结构有三个主要概念—— Subject、 SecurityManager 和 Realms。

Subject

在保护应用程序安全时，最需要问自己的问题可能是: “谁是当前用户?”或“当前用户是否允许做 x”？在编写代码或设计用户界面时，我们经常会问自己这些问题: 应用程序通常是基于用户故事构建的，而您希望基于每个用户的基础来表示(和保护)功能。因此，我们考虑应用程序安全性的最自然的方式是基于当前用户。Shiro 的 API 在其 Subject 概念中从根本上代表了这种思维方式。
Subject 是一个安全术语，基本上意味着“当前正在执行的用户”。它只是不被称为“用户”，因为“用户”这个词通常与人联系在一起。在安全领域，“ Subject”这个术语可以指人，也可以指第三方进程、守护进程帐户或任何类似的东西。它仅仅意味着“当前与软件相互作用的东西”。不过，对于大多数意图和目的，你可以把它看作 Shiro 的用户概念。您可以轻松地在代码中的任何位置获取 Shiro Subject，如下面的代码所示：

import org.apache.shiro.subject.Subject;
import org.apache.shiro.SecurityUtils;
...
Subject currentUser = SecurityUtils.getSubject();

一旦你获得了 Subject，你就可以立即访问当前用户希望 Shiro 做的90% 的事情，比如登录、注销、访问他们的会话、执行授权检查等等——但是稍后会更详细。这里的关键点在于 Shiro 的 API 在很大程度上是直观的，因为它反映了开发人员考虑“每个用户”安全控制的自然倾向。还可以轻松地在代码中的任何地方访问 Subject，从而允许在任何需要的地方执行安全操作。
正如上面提到的，Subject本质上是当前执行用户的特定于安全性的“视图”。尽管“用户”这个词通常意味着一个人，但Subject可以是一个人，但它也可以表示第三方服务、守护程序帐户、cron作业或任何类似的东西——基本上是当前与软件交互的任何东西。
Subject实例都绑定到SecurityManager。当您与Subject交互时，这些交互将转换为与SecurityManager的特定于Subject的交互。

SecurityManager

主体Subject的“幕后指挥”是 SecurityManager。Subject 表示当前用户的安全操作，SecurityManager 则管理所有用户的安全操作。它是 Shiro 架构的核心，作为一种“保护伞”对象，引用许多内部嵌套的安全组件。但是，一旦配置了 SecurityManager 及其内部对象，通常就不会对它进行任何处理，应用程序开发人员几乎所有时间都花在 Subject API 上。
web 应用程序通常会在 web.xml 中指定一个 Shiro Servlet 过滤器，这个过滤器将设置 SecurityManager 实例。
应用程序的SecurityManager执行安全操作并管理所有应用程序用户的状态。在Shiro的默认SecurityManager实现中，这包括：

• 身份验证（Authenticator）
• 授权（Authorizer ）
• 会话管理（SessionManager ）
• 缓存管理（CacheManager）
• Realm协调
• 事件传播
• remember me
• Subject创建
• 注销登录
  但是，在单个组件中需要管理很多功能。而且，如果将所有内容都集中到一个实现类中，那么使这些内容变得灵活和可定制将是非常困难的。为了简化配置并实现灵活的配置/可插拔性，Shiro的实现在设计上都是高度模块化的——事实上，模块化程度如此之高，以至于SecurityManager实现（及其类层次结构）根本做不到什么。相反，SecurityManager实现主要充当轻量级的“容器”组件，将几乎所有行为委托给嵌套/包装的组件。当组件实际执行逻辑时，SecurityManager实现知道如何以及何时协调组件以获得正确的行为。
  SecurityManager实现和组件也是JavaBeans兼容的，这允许您（或配置机制）通过标准JavaBeans访问器/变异器方法（get*/set*）轻松定制可插入组件。这意味着Shiro的架构模块化可以转化为非常简单的定制行为配置。

Realm

Realm 充当 Shiro 和应用程序的安全数据之间的“桥梁”或“连接器”。也就是说，当需要与用户帐户等与安全相关的数据进行实际交互以执行身份验证(登录)和授权(访问控制)时，Shiro 会从为应用程序配置的一个或多个领域查找其中的许多内容。从这个意义上讲，Realm 实质上是一个特定于安全的 DAO: 它封装了数据源的连接细节，并根据需要将相关的数据提供给 Shiro。在配置 Shiro 时，您必须指定至少一个 Realm 用于身份验证和授权。可以配置多个领域，但至少需要一个领域。与其他内部组件一样，SecurityManager管理如何使用Realm来获取安全性和标识数据，以表示为Subject实例。

Shiro组件架构

Subject、SecurityManager、Realm在上面已经介绍过了，在此不再赘述。

Authenticator

Authenticator是负责执行和响应用户的身份验证（登录）的组件。当用户尝试登录时，该逻辑由Authenticator执行。Authenticator知道如何与存储相关用户/帐户信息的一个或多个Realm进行协调。从这些Realm获得的数据被用来验证用户的身份，以保证用户真正是他们所说的那个人。

Principals

Principals是Subject的“标识属性”。Principals可以是任何标识Subject的东西，例如名字（给定名称）、姓氏（姓氏或姓氏）、用户名、身份证号码等。当然，像姓氏之类的东西不太擅长唯一地识别，因此，用于身份验证的最佳Principals对于应用程序是唯一的——通常是身份证号码或电子邮件地址。

Credentials

凭证通常是只有主体知道的秘密值，用作证明他们实际上“拥有”所声称的身份的证据。凭证的一些常见示例包括密码、指纹和视网膜扫描等生物特征数据以及X.509证书。

Principals/Credentials配对最常见的例子是用户名和密码。用户名是声明的身份，密码是与声明的身份匹配的证明。如果提交的密码与应用程序所期望的密码匹配，那么应用程序可以在很大程度上假设用户确实是他们所说的人，因为其他人不应该知道相同的密码。

AuthenticationStrategy

如果配置了多个Realm，AuthenticationStrategy将协调这些Realm，以确定身份验证尝试成功或失败的条件。例如，如果一个Realm成功，而其他Realm失败，那么尝试是否成功？所有领域都必须成功吗？

Authorizer

Authorizer 是负责确定应用程序中用户访问控制的组件。它是一种机制，最终决定了是否允许用户做某事。与Authenticator一样，Authorizer 也知道如何协调多个后端数据源来访问角色和权限信息。Authorizer使用此信息来确定是否允许用户执行给定的操作。

SessionManager

SessionManager知道如何创建和管理用户会话生命周期，以便为所有环境中的用户提供健壮的会话体验。这是安全框架中的一个独特特性—Shiro能够在任何环境中以本机方式管理用户会话，即使没有可用的Web/Servlet或EJB容器。默认情况下，Shiro将使用现有的会话机制（如Servlet容器），但如果没有，例如在独立应用程序或非web环境中，它将使用其内置的企业会话管理来提供相同的编程体验。SessionDAO允许任何数据源用于持久化会话。

SessionDAO

SessionDAO代表SessionManager执行会话持久性（CRUD）操作。这允许将任何数据存储插入会话管理基础结构。

CacheManager

CacheManager创建并管理由其他Shiro组件使用的缓存实例生命周期。由于Shiro可以访问许多后端数据源以进行身份验证、授权和会话管理，因此缓存一直是框架中的一个一流的体系结构特性，可以在使用这些数据源的同时提高性能。任何现代开源和/或企业缓存产品都可以插入Shiro，以提供快速高效的用户体验。

Cryptography

加密技术是企业安全框架的自然补充。Shiro的加密包包含易于使用和理解的晶体密码、哈希（aka digests）和不同编解码器实现的表示。这个包中的所有类都经过精心设计，非常易于使用和理解。Shiro的cryptoapi简化了复杂的Java原生加密技术，使加密技术更容易为普通人使用。

文章参考：
Shiro官方文档