本篇是对Shiro体系架构的介绍，本栏目大部分内容来自于Shiro官网。翻译过程中已经尽量保证用词的准确性和易懂性，如有不准确或者不确切的地方，请联系作者加以修改。本篇内容翻译自Apache Shiro 体系结构。

Apache Shiro的设计目标是通过直观且易于使用的API来简化应用程序安全性。Shiro的核心设计模拟了大多数人是如何考虑应用程序的安全性的。

软件应用程序通常是基于用户背景设计的。也就是说，您通常会根据用户与软件的交互方式来设计用户界面或服务API。例如，您可能会说：“如果与我的应用程序交互的用户已登录，我将向他们显示一个按钮，使他们可以单击以查看其帐户信息。如果他们尚未登录，我将显示一个注册按钮”。这个简单的陈述表明，应用程序的编写很大程度上是为了满足用户需求。即使“用户”是另一个软件系统，而不是人类，您仍然可以基于当前正在与您的软件进行交互的人员（或物）编写代码来响应行为。

Shiro在自己的设计中体现了这些概念。通过匹配那些对软件开发人员来说已经很直观的东西，Apache Shiro几乎在任何应用程序中保持了直观性和易用性。

我们可以从应用程序的角度（外部）观察Shiro的架构，即应用程序是如何使用Shiro完成安全验证工作的。从下图可以看到Shiro主要有三个概念：Subject，SecurityManager，Realms。并且可以看到应用程序代码直接交互的对象是Subject，也就是说Shiro对外的API的核心就是Subject。下面是对Subject，SecurityManager，Realms的解释。

Subject：主题，Subject本质上是当前正在执行的用户的安全特定“视图”。"user"一词通常表示一个具体的人，但Subject不一定是一个具体的人，与当前与该软件交互的任何东西都是一个Subject，比如：第三方服务，网络爬虫，机器人等，它是一个抽象概念。Subject都绑定到SecurityManager上，与Subject的所有的交互都会委托给SecurityManager，Subject是与外部应用程序的一个接口，而SecurityManager才是真正的执行者。

SecurityManager：SecurityManager是整个Shiro体系架构的核心。所有安全有关的操作都会与SecurityManager交互。该对象协调内部安全组件，通常在为应用程序配置了SecurityManager以及相应的安全组件后，开发人员只需要将时间花费在Subject API上即可。后面会详细的介绍SecurityManager

Realms：Realms充当Shiro与应用程序安全数据之间的桥梁，简而言之，Shiro从Realms中获取安全数据（用户，角色，权限）。SecurityManager当真正需要与安全性相关的数据（例如用户帐户）执行身份验证（登录）和授权（访问控制）时，那么它需要从 Realm 获取相应的用户进行比较以确定用户身份是否合法；也需要从 Realm 得到用户相应的角色/权限进行验证用户是否能进行操作。从这个意义上说，Realms本质上是特定于安全性的DAO：它封装了数据源的连接详细信息，并根据需要使关联数据可用于Shiro。在配置Shiro时，您必须至少指定一个Realms用于身份验证或授权。所述SecurityManager可配置多个Realms，但至少有一个Realm是必需的。Shiro提供了开箱即用的Realm，可以连接到许多安全数据源，例如LDAP，关系数据库（JDBC），文本配置源（例如INI和Properties文件）等。如果默认的Realms不能满足您的需求，那么您还可以使用自定义Realm。即：可以把 Realm 看成DataSource。

从上面的介绍中我们知道认证和权限控制最终都交给了SecurityManager去处理，SecurityManager是如何进行处理的，它的架构又是如何实现的呢？如下图为SecurityManager的详细架构图，看懂了本篇的两张图，就等于Shiro学会了百分之50以上。只要是跟Shiro有关的课程或者博客不会缺少这两张图。

 从图上总结起来：最简单的一个 Shiro认证流程如下：
1、 应用代码通过 Subject来进行认证和授权，而Subject又委托给 SecurityManager进行处理；
2、 我们需要给 Shiro 的 SecurityManager 注入 Realm，从而让 SecurityManager 能通过Realm得到合法的用户及其权限控制。

一下内容为图中各个组件的描述：

Subject（org.apache.shiro.subject.Subject）：前面已经讲述过，当前与软件进行交互的实体的特定于安全性的“视图”，可以是用户，第三方服务，计划任务等。

SecurityManager（org.apache.shiro.mgt.SecurityManager）：前面已经讲述过，SecurityManager是Shiro体系结构的核心。所有具体的交互都通过 SecurityManager 进行控制,它用于协调其托管其他组件（如：Subject、Authenticator、Authorizer等）以确保它们能够顺利协同工作。

Authenticator（org.apache.shiro.authc.Authenticator）：Authenticator是认证器，负责主体认证的。当用户尝试登录时，该逻辑由Authenticator执行。Authenticator知道如何通过一个或多个Realms获取相关的用户/帐户信息。从这些Realms获得的数据用于验证用户的身份。如果觉得 Shiro 默认实现不满足，可以自定义实现Authenticator，其需要认证策略（Authentication Strategy），即什么情况下算用户认证通过了。

• Authentication Strategy（org.apache.shiro.authc.pam.AuthenticationStrategy）：如果配置了多个Realms，AuthenticationStrategy会协调这些Realms尝试身份认证是否成功（只有一个Realm成功即成功，还是所有Realms成功才算成功等等）

 Authorizer（org.apache.shiro.authz.Authorizer）：授权器或者访问控制器。判定用户是否有权限做某事，用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能。与Authenticator，Authorizer也可以通过Realms获取相应的角色和权限，Authorizer使用该信息来确定是用户是否可以执行特定的操作。

SessionManager（org.apache.shiro.session.mgt.SessionManager）：用于创建和管理用户Session生命周期，在所有环境中给用户提供强大的会话体验。即Shiro能够在任何环境中本地管理用户会话，不仅仅可以用在 Web 环境，也可以用在如普通的 JavaSE 环境、EJB 等环境；它将使用其内置的企业级会话管理来提供相同的编程体验。Shiro 抽象了一个自己的 Session（org.apache.shiro.session。Session）来管理主体与应用之间交互的数据,这样的话，比如我们在 Web 环境用，刚开始是一台Web 服务器；接着又上了台 EJB 服务器；这时想把两台服务器的会话数据放到一个地方，我们就可以通过SessionDAO将数据放到 Memcached 服务器等从而实现分布式会话管理。

• SessionDAO（org.apache.shiro.session.mgt.eis.SessionDAO）:会话DAO，是对session会话操作的一套接口。SessionDAO代表SessionManager执行Session的持久化（CRUD）操作。通过实现SessionDAO，我们可以把Session保存到数据库、memcache、Redis等。

CacheManager (org.apache.shiro.cache.CacheManager)：CacheManager创建并管理其他组件使用的Cache示例的生命周期。简单来说就是用于管理如用户、角色、权限等缓存；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能。Shiro支持多种缓存方式（Redis、ehcache等）。
Cryptography (org.apache.shiro.crypto.*)：密码模块。shiro提供了一套加密/解密的组件，提供常用的散列、加/解密等功能。该组件让加密和解密更加容易。
Realms (org.apache.shiro.realm.Realm)：前面也已经讲述，由用户提供用于获取安全实体的，可以是 JDBC 实现，也可以是LDAP 实现，或者内存实现、文本实现等等；

总结起来用户只需要跟Subject交互，而其他的则交给SecurityManager进行统一管理。同时我们也可以自定义一些组件交给SecurityManager进行管理，比如：Realm。