Shiro的顶层架构图
这其中主要讲的是 subject、securityManager、Realm的关系
用户请求访问系统，那么这个用户就被认为是一个subject，subject要和后台系统交互，首先经过securityManager的内部处理，然后通过桥梁Realm进行交互。所以被称为DAO的Realm就是一个类似转接器的部件。
由此可以看出，shiro的具体业务逻辑实现就是Realm的实现，我们主要的工作就是设计编写Realm，这很重要。
各组件层次图
Subject：(org.apache.shiro.subject.Subject)，如上所述；
SecurityManager：(org.apache.shiro.mgt.SecurityManager)，如上所述；
Authenticator（用户认证管理器）：(org.apache.shiro.authc.Authenticator)
这个组件主要用于处理用户登录逻辑，他通过调用Realm的接口来判断当前登录的用户的身份。
用户认证策略，(org.apache.shiro.authc.pam.AuthenticationStrategy)
如果系统配置了多个Realm，则需要使用AuthenticationStrategy 来协调这些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（通常来说一种数据源配置一个）。
参考资料同一
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
