Shiro的设计目标就是让应用程序的安全管理更简单、更直观。
软件系统一般是基于用户故事来做设计。也就是我们会基于一个客户如何与这个软件系统交互来设计用户界面和服务接口。比如，你可能会说：“如果用户登录了我们的系统，我就给他们显示一个按钮，点击之后可以查看他自己的账户信息。如果没有登录，我就给他显示一个注册按钮。”
上述应用程序在很大程度上是为了满足用户的需求而编写的，即便这个“用户”不是人，而是一个其他的软件系统。你仍然是按照谁当前正在与你的系统交互的逻辑来编写你的逻辑代码。
Shiro的设计已经考虑到以上这些用户安全的概念。
总览
在最顶层，Shiro的架构有3个主要概念：Subject、SecurityManager和Realms。下图展示了这几个组件之间的交互，下面我们会逐一介绍这些概念：
#，Subject，正如我们在教程中所说，Subject其实代表的就是当前正在执行操作的用户，只不过因为“User”一般指代人，但是一个“Subject”可以是人，也可以是任何的第三方系统，服务账号等任何其他正在和当前系统交互的第三方软件系统。
所有的Subject实例都被绑定到一个SecurityManager，如果你和一个Subject交互，所有的交互动作都会被转换成Subject与SecurityManager的交互。
#，SecurityManager。SecurityManager是Shiro的核心，他主要用于协调Shiro内部各种安全组件，不过我们一般不用太关心SecurityManager，对于应用程序开发者来说，主要还是使用Subject的API来处理各种安全验证逻辑。
#，Realm，这是用于连接Shiro和客户系统的用户数据的桥梁。一旦Shiro真正需要访问各种安全相关的数据（比如使用用户账户来做用户身份验证以及权限验证）时，他总是通过调用系统配置的各种Realm来读取数据。
正因为如此，Realm往往被看做是安全领域的DAO，他封装了数据源连接相关的细节，将数据以Shiro需要的格式提供给Shiro。当我们配置Shiro的时候，我们至少需要配置一个Realm来提供用户验证和权限控制方面的数据。我们可能会给SecurityManager配置多个Realm，但是不管怎样，我们至少需要配置一个。
Shiro提供了几种开箱即用的Realm来访问安全数据源，比如LDAP、关系数据库、基于ini的安全配置文件等等，如果默认提供的这几种Realm无法满足你的需求，那么你也可以编写自己的定制化的Realm插件。
和其他内部组件一样，SecurityManager决定了在Shiro中如何使用Realm来读取身份和权限方面的数据，然后组装成Subject实例。
详细架构
下图展示了Shiro的核心组件，并概述了每个组件的功能。
#，Subject，(
org.apache.shiro.subject.Subject)，如上所述；#，SecurityManager， (org.apache.shiro.mgt.SecurityManager)，如上所述；
#，Authenticator（用户认证管理器）， (org.apache.shiro.authc.Authenticator)
这个组件主要用于处理用户登录逻辑，他通过调用Realm的接口来判断当前登录的用户的身份。
如果系统配置了多个Realm，则需要使用AuthenticationStrategy 来协调这些Realm以便决定一个用户登录的认证是成功还是失败。（比如，如果一个Realm验证成功了，但是其他的都失败了，那么这次认证算是成功了吗？还是说必须所有的Realm都认为成功了才算成功？或者是第一个成功就算成功？可见，策略还是蛮复杂的）；
#， Authorizer（权限管理器）(org.apache.shiro.authz.Authorizer)
这个组件主要是用来做用户的访问控制。通俗来说就是决定用户能做什么、不能做什么。和Authenticator类似，Authorizer也知道怎么协调多个Realm数据源的数据，他有自己的一套策略。
#，SessionManager（会话管理器） (org.apache.shiro.session.mgt.SessionManager)
SessionManager知道如何创建会话、管理用户回话的声明周期以便在所有运行环境下都可以给用户提供一个健壮的回话管理体验。Shiro在任何运行环境下都可以在本地管理用户会话（即便没有Web或者EJB容器也可以）——这在安全管理的框架中算是独门绝技了。当然，如果当前环境中有会话管理机制（比如Servlet容器），则Shiro默认会使用该环境的会话管理机制。而如果像控制台程序这种独立的应用程序，本身没有会话管理机制，此时Shiro就会使用内部的会话管理器来给应用的开发提供一直的编程体验。SessionDAO允许用户使用任何类型的数据源来存储Session数据。
*，SessionDAO，(org.apache.shiro.session.mgt.eis.SessionDAO)
用于代替SessionManager执行Session相关的增删改查。这个接口允许我们将任意种类的数据存储方式引入到Session管理的基础框架中。
#，CacheManager(org.apache.shiro.cache.CacheManager)
CacheManager用于创建和维护一些在其他的Shiro组件中用到的Cache实例，维护这些Cache实例的生命周期。缓存用于存储那些从后端获取到的用户验证与权限控制方面的数据以提高性能，缓存是一等公民，在获取数据时，总是先从缓存中查找，如果没有再调用后端接口从其他数据源获取。Shiro允许用户使用其他更加现代的、企业级的数据源来替代内部的默认实现，以提供更高的性能和更好的用户体验。
#，Cryptography ，加密技术，(org.apache.shiro.crypto.*)
对于一个企业级的安全框架来说，加密算是其固有的一种特性。Shiro的crypto包中包含了一系列的易于理解和使用的加密、哈希（aka摘要）辅助类。这个包内的所有类都是经过精心设计，相比于java本身提供的那一套反人类的加密组件，Shiro提供的这套加密组件简直不要好用太多。
#，Realm，(org.apache.shiro.realm.Realm)
就如上文所提到的，Realm是连接Shiro和你的安全数据的桥梁。任何时候当Shiro需要执行登录或者访问控制的时候，都需要调用已经配置的Realm的接口去获取数据。一个应用程序可以配置一个或者多个Realm（通常来说一种数据源配置一个）。
SecurityManager介绍
Shiro对外主要提供了以Subject为核心的一些列API，各种用户验证与权限控制的接口都是围绕着Subject来设计的，所以一般的用户不太会需要直接和SecurityManager类打交道。即便如此，如果我们能够了解一些SecurityManager相关的工作原理，对于我们更好的用好Shiro还是大有裨益的。
设计
如上文所述，应用程序的SecurityManager执行安全相关的操作并管理该应用的所有用户的状态。在Shiro的SecurityManager的默认实现中，这些操作和状态包括：
#，用户认证；
#，权限控制；
#，回话管理；
#，缓存管理；
#，Realm的协调调度；
#，事件传播；
#，“Remember Me”服务；
#，创建Subject；
#，退出登录；
#，。。。
如果要在一个类内部实现所有这些功能，那将是相当复杂。而如果我们还进一步要求所有这些特性都要足够灵活、可定制，那可如何是好？
为了提供更加灵活的可配置特性、可插拔的特性，Shiro的实现完全是模块化的，SecurityManager本身几乎不做什么事情，他只是一个轻量级的“容器”组件，他把所有的功能都转发给相关的子组件去完成，这种包装器的设计模式见上文 详细架构 中的框图。
SecurityManager也兼容JavaBeans，这样我们就可以通过JavaBean的标准的get*/set*方法来给SecurityManager诸如一些定制化的组件。
易于配置：因为与JavaBean兼容，所以我们可以使用任何与JavaBean兼容的机制来给SecurityManager注入一些定制化的组件，比如Spring、Guice、Jboss等等。
下一节我们会介绍 配置 （Configuration ）相关的信息。
本系列相关：