shiro-架构

Shiro是一个强大易用的Java安全框架,提供了认证、授权、加密和会话管理等功能。

架构图

概念

subject

主体，代表了当前“用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是Subject，如网络爬虫，机器人等；即一个抽象概念；所有Subject都绑定到SecurityManager，与Subject的所有交互都会委托给SecurityManager；可以把Subject认为是一个门面；SecurityManager才是实际的执行者；

subject使用Shiro编程为单个用户时的主要组件安全操作，它是任何可访问的用户安全数据的句柄。所有单用户身份验证、授权和会话操作是通过subject实例执行的。操作包括认证（登录/注销）、授权（访问控制），和会话访问.

下面的引用来自javax.sercurity规范：
subject表示单个实体（如人）的相关信息的分组。此类信息包括主体的身份以及其安全相关属性（例如密码和密码密钥）。受试者可能具有多重身份。每个标识在subject内表示为subject 。主体简单地将名称绑定到{@代码主题}。例如，发生在某人身上的subject，爱丽丝，可能有两个主体：一个绑定“爱丽丝bar”，她的驾驶执照上的名字，到subject，另一个绑定，“99到999 99 99”，在她的学生身份证上的数字，到subject。两个主体都引用相同的*subject，即使每个名称都有不同的名称。 subject也可以拥有与安全相关的属性，称为凭据。需要特殊保护的敏感凭据，如私有密码密钥，存储在私有凭据{@代码集}内。要共享的凭据，如公钥证书或Kerberos服务器票，存储在公共凭证{@代码集}内。需要不同的权限来访问和修改不同的证书集。检索与subject相关联的所有主体，调用{@代码GEngErrase}方法。要检索属于subject的所有公共或私有凭据，分别调用{@代码GETPusieCudith}方法或{代码GETPultActReCudie}方法。修改主体和凭据返回的{@代码集}，使用{@代码集}类中定义的方法。例如

 Subject subject;
 *      Principal principal;
 *      Object credential;
 *
 *      // add a Principal and credential to the Subject
 *      subject.getPrincipals().add(principal);
 *      subject.getPublicCredentials().add(credential);

This {@code Subject} class implements {@code Serializable}.
* While the Principals associated with the {@code Subject} are serialized,
* the credentials associated with the {@code Subject} are not.
* Note that the {@code java.security.Principal} class
* does not implement {@code Serializable}. Therefore all concrete
* {@code Principal} implementations associated with Subjects
* must implement {@code Serializable}.

Realm

域，Shiro从从Realm获取安全数据（如用户、角色、权限），就是说SecurityManager要验证用户身份，那么它需要从Realm获取相应的用户进行比较以确定用户身份是否合法；也需要从Realm得到用户相应的角色/权限进行验证用户是否能进行操作；可以把Realm看成DataSource，即安全数据源。

可以访问特定于应用程序的安全实体的安全组件。用于确定身份验证和授权操作的用户、角色和权限。
通常与一个数据源（如关系数据库）有1对1的对应关系，文件系统，或其他类似的资源。因此，此接口的实现使用特定于数据源的API。确定授权数据（角色、权限等），如JDBC、文件IO、Hibernate或JPA，或其他任何数据访问API。它们本质上是安全专用的。
因为这些数据源通常包含subject信息，如用户名和密码，一个域可以充当一个可插入的身份验证模块,
这允许一个领域执行单个数据源的认证和授权职责，以满足大型数据源的要求。
如果出于某种原因，您不希望您的域实现执行身份验证职责，您应该始终重写org.apache.shiro.authc.AuthenticationToken
因为每个应用程序都是不同的，所以可以使用诸如用户和角色的安全数据。以多种方式表示。Shiro试图保持一种非侵入式的发展哲学。
Shiro允许应用程序实现这个接口来访问特定于环境的数据源。和数据模型对象。然后可以将实现插入到应用程序的Shiro配置中。此模块化技术抽象出任何环境/建模细节，并允许Shiro部署在几乎任何应用环境。大多数用户不会直接实现Realm,但会扩展其中一个子类。
支持核心Realm接口的组件和子包。特别注意多个子包与现有领域支持的许多实现,可以直接使用或扩展自定义行为的环境。

可以有1个或多个Realm，可以认为是安全实体数据源，即用于获取安全实体的；可以是JDBC实现，也可以是LDAP实现，或者内存实现等等；由用户提供；注意：Shiro不知道你的用户/权限存储在哪及以何种格式存储；所以我们一般在应用中都需要实现自己的Realm；

Principal
shiro使用的是java.security.Principal，代表一个委托人的抽象概念。可以用来表示任何实体，例如个人，A公司和登录ID。
只是一个安全标识属性，如用户名或用户ID或社会安全号码或其他任何可以被认为是“识别”属性为“编码主体

Session

状态数据上下文 和一个单独的subject关联（用户，守护进程等等）它和在一段时间内的一个软件系统交互，意图被业务层管理 访问通过其他层 不是通过任何给予的客户端。

与管理会话相关的组件，基于subject 基于时间的数据上下文与应用程序交互。
* Shiro中的会话完全是基于POJO的，而不是要求应用程序使用基于Web的或基于EJB的会话管理基础设施-客户端和/或服务器技术无关
* Shiro的体系结构，允许会话管理应用在最小的独立应用程序中最大的企业部署
*会话不管客户端使用HTTP，定制插座，Web服务，甚至非java编程语言。除了Shiro，目前还没有技术在java今天允许这种异质性客户端会话能力。由于这个自由，Shiro自然也支持任何应用程序的单点登录这种异构会话支持。

Authenticator：认证器，负责主体认证的，这是一个扩展点，如果用户觉得Shiro默认的不好，可以自定义实现；其需要认证策略（Authentication Strategy），即什么情况下算用户认证通过了；

Authentication：身份认证/登录，验证用户是不是拥有相应的身份；

Authorization：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；

Authrizer：授权器，或者访问控制器，用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能；

Permission
权限表示执行操作或访问资源的能力。许可是最重要的系统安全策略中的颗粒状或原子单位，是细粒度安全的基石模型的建立。
*重要的是理解权限实例只表示功能或访问-它不授予它。
*通过应用程序的安全性来实现对应用程序功能或特定资源的访问。配置，通常是通过向用户、角色和/或组分配权限。
最典型的系统是Shiro团队在本质上称为基于角色的，其中角色代表
某些用户类型的常见行为。例如，系统可能有一个管理员角色，a
用户或访客< /EM>角色等。
但是如果您有一个动态安全模型，在运行时可以创建和删除角色，则不能硬编码。代码中的角色名称。在这种环境中，角色本身并不是很有用。重要的是什么权限被分配给这些角色。
*在此范例下，权限是不可变的，反映应用程序的原始功能。打开文件，访问Web URL，创建用户等）。这是允许系统安全策略的原因。是动态的：因为权限代表原始功能，只有当应用程序更改时才发生更改。
源代码更改，它们在运行时是不可变的——它们代表系统可以做什么。角色、用户和组是应用程序的“WHO”。确定“谁”可以做“什么”然后成为一个简单的练习。
以某种方式将权限与角色、用户和组关联。大多数应用程序通过将命名角色与权限关联（即角色有一个权限集合）来实现这一点。
然后将用户与角色（即用户有一个角色集合）关联起来，以便通过传递关联，用户有其角色中的权限。这个主题有很多变化。
*（直接分配给用户或分配给组的权限），并将用户依次添加到组和这些组中有角色等）。当使用基于权限的安全模型而不是基于角色的安全模型时，用户、角色
*和组都可以在运行时创建、配置和/或删除。这使得安全极为强大。模型。
* Shiro的好处是，尽管它假定大多数系统是基于这些类型的静态角色或动态角色W/许可方案，它不需要系统以这种方式对它们的安全数据建模。权限检查被降级到 {@link org.apache.shiro.realm.Realm}实现，并且仅限于那些实现真的决定了用户是否有权限。领域可以使用描述的语义这里，或者它可以完全利用一些其他机制-它总是取决于应用程序开发人员。
* Shiro以这种形式提供了一个非常强大的默认接口org.apache.shiro.authz.permission.WildcardPermission WildcardPermission。我们强烈推荐你在尝试实现自己的<代码>权限< /代码>之前，调查此类。

Session Manager：管理所有应用程序的创建、维护和清理，会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通JavaSE环境的，也可以是如Web环境的；

如果写过Servlet就应该知道Session的概念，Session呢需要有人去管理它的生命周期，这个组件就是SessionManager；而Shiro并不仅仅可以用在Web环境，也可以用在如普通的JavaSE环境、EJB等环境；所有呢，Shiro就抽象了一个自己的Session来管理主体与应用之间交互的数据；这样的话，比如我们在Web环境用，刚开始是一台Web服务器；接着又上了台EJB服务器；这时想把两台服务器的会话数据放到一个地方，这个时候就可以实现自己的分布式会话（如把数据放到Memcached服务器）；

Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；

Web Support：Web支持，可以非常容易的集成到Web环境；

Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率；

Concurrency：shiro支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；

Testing：提供测试支持；

Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；

Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。

SecurityManager

安全管理器；即所有与安全有关的操作都会与SecurityManager交互；且它管理着所有Subject；可以看出它是Shiro的核心，它负责与后边介绍的其他组件进行交互，如果学习过SpringMVC，你可以把它看成DispatcherServlet前端控制器；相当于SpringMVC中的DispatcherServlet或者Struts2中的FilterDispatcher；是Shiro的心脏；所有具体的交互都通过SecurityManager进行控制；它管理着所有Subject、且负责进行认证和授权、及会话、缓存的管理。

SessionDAO：DAO大家都用过，数据访问对象，用于会话的CRUD，比如我们想把Session保存到数据库，那么可以实现自己的SessionDAO，通过如JDBC写到数据库；比如想把Session放到Memcached中，可以实现自己的Memcached SessionDAO；另外SessionDAO中可以使用Cache进行缓存，以提高性能；负责持久化主体实例的内部状态，以使主体实例生效，如果需要的话，可以在以后重新创建。

CacheManager：缓存控制器，来管理如用户、角色、权限等的缓存的；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能

Cryptography：密码模块，Shiro提高了一些常见的加密组件用于如密码加密/解密的。