【Apache Shiro】学习笔记二

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（一般来讲一种数据源配置一个）。

参考资料同一