Apache Shiro Architecture shiro架构
Apache Shiro Architecture
Apache Shiro以直观简单的简化应用程序安全性为目标。shiro的核心设计模拟了大队哦熟人在某人(或某物)与应用程序交互的情况下对应用程序安全性的看法。
软件应用程序通常是根据用户案例设计的。也就是说你会经常根据用户与软件交互的方式来设计用户界面或服务API。例如,你可能会说如果与我的应用程序交互的用户已登录,我会给他们一个看到自己账户信息的按钮。如果没有登录我会提供一个登录按钮。
这个例子表明应用程序主要是为了满足用户需求而写的。甚至“用户”可能是另一个软件系统或并非人类。你将继续基于当前正在与你的应用程序交互的某人/某物编码来反映行为(编码以支持交互行为)。
Shiro在设计中反映了这些意向。为了与软件开发者的直观意图匹配,Apache Shiro保持在几乎所有应用程序中都直观且易用的功能。
高层概述(High-Level Overview)
在抽象的最高层级,shiro架构有三个主要概念:Subject
、SecurityManager
和Realms
。下面这张图扎实你是了高层抽象组件之间如何相互作用,并且在下面的叙述中将介绍每个概念
-
Subject:正如在教程中提到的那样,
Subject
本质上是当前操作用户的特定的安全视图(view)。“用户(User)”一次通常表示一个人但Subject
可以是一个人也可以是第三方服务(3rd-party service)、守护账户(daemon account)、定时任务(cron job)或其他类似的东西,基本上是当前与软件交互的任何东西.Subject
实例都会被绑定(需要)一个SecurityManager
。当你与Subject
交互,这些交互会被转换成与SecurityManager
特定主题(subject-specific)的交互。 -
SecurityManager:
SecurityManager
是Shiro体系结构的核心并充当一种协调内部其他安全组件构成对象图的伞(umbrella)
对象(伞下包含多个对象?)。然而,一旦为应用程序配置SecurityManager及其内部对象图,通常(SecurityManager)就被放到一边了,而且程序开发人员几乎将所有时间都花在与Subject
API交互上。稍后我们将详细讨论SecurityManager,但重要的是认识到当与
Subject
交互时,实际上是在幕后的SecurityManager
为Subject
的安全操作干了所有的重活.这反映在上面的基本流程图中。 -
Realms:Realms充当Shiro与应用的安全数据之间的’桥梁(bridge)‘或’连接器(Connector)’。当真正需要与安全性相关的数据(例如用户账户)进行身份验证(login)和授权(访问控制)时,Shiro会从为应用程序配置的一个或多个Realms中查找许多相关内容。Realms相当于安全数据的数据源
从这个意义上说Realms本质上是特定于安全性(security-specific)的DAO(数据访问对象):它封装了数据源的连接详细信息并且根据Shiro的需要提供安全数据支持。当配置Shiro的时候你必须指定至少一个Realm用于验证(authentication)/授权(authentization).
SecurityManager
或许被配置成多Realms(多安全数据源)。至少有一个被需求。Shiro提供了开箱即用的Realms来连接许多安全数据源(又名目录directories)例如LDAP、关系数据库(JDBC)、文本配置源(例如INI和属性文件)等。如果默认的Realms不能满足您的需求,那么您可以插入时的实现自己的Realms以表示自定义数据源。
像其他内部组件一样Shiro的
SecurityManager
管理了Realms以用于提供安全身份数据来支持Subject
实例。
详细架构(Detailed Architecture)
下图展示了Shiro的核心架构概念并简述了每个概念
-
Subject(
org.apache.shiro.subject.Subject
)一个当前正在与软件交互的实体(用户、第三方服务、定时任务等)的安全性质视图(A security-specific
view
of the entity)。 -
SecurityManager (org.apache.shiro.mgt.SecurityManager)
如上所述
SecurityManager
是shiro架构的核心。它是一个伞对象用以协调其托管的组件以确保它们能够顺利的协调工作。它还管理Shiro对每个应用程序用户的视图。因此它知道如何对每个用户执行安全操作- -
Authenticator(org.apache.shiro.authc.Authenticator)
Authenticat
or是负责执行用户身份验证(登录)。当用户尝试登陆,该逻辑由Authenticator
执行。身份验证器Authenticator
知道如何协调一个或多个存储用户/账户数据的Realms
。从这些Realms
中获取的数据用于验证用户的身份来确保用户确实是它们所说的真实身份。来验证用户是谁-
Authentication Stategy(org.apache.shiro.authc.pam.AuthenticationStrategy)
如果配置了多个
Realm
,验证策略AuthenticationStrategy
将协调Realms来决定验证操作成功/失败的各种情况。(例如,如果一个realms成功了,但是其他失败了,则该判定为成功吗?必须所有realms都成功?还是说只要第一个成功就行?)
-
-
Authorizer (org.apache.shiro.authz.Authorizer)
Authorizer
是负责决定用户对应用程序访问权限的组件。它最终表明用户是否允许做某事。与身份验证器Authenticator
一样,Authorizer
也知道如何协调多个后端数据源来进行按角色访问以及权限信息。Authorizer
使用这个信息来决定是否允许用户执行给定操作。 -
SessionManager(org.apache.shiro.session.mgt.SessionManager)
SessionManager
知道如何创建和管理用户会话Session
的生命周期,以便为所有环境中的用户提供可靠的会话体验。这是安全框架领域中的一项特有功能。Shiro拥有在任务环境中本地性地(native)管理用户会话的功能即使在非Web/Servlet或者EJB容器中, 默认情况下,Shiro将使用现有的会话机制(例如Servlet容器)(如果可用),但是如果没有,例如在独立应用程序或非Web环境中,它将使用其内置的企业会话管理来 提供相同的编程经验。 SessionDAO的存在是为了允许使用任何数据源来保留会话。-
SessionDAO(org.apache.shiro.session.mgt.eis.SessionDAO)
SessionDAO
代表SessionManager执行会话的持久性CRUD操作。这允许任何数据存储集成到会话管理的基础结构中
-
-
CacheManager(org.apache.shiro.cache.CacheManager)
CacheManager
创建和管理其他Shiro组件使用Cache实例的生命周期。由于Shiro可以访问许多后端数据源进行身份验证、授权和会话管理,缓存一直是架构中的一流特性,可以在使用这些数据源时提高性能。可将任何现代的开源或企业缓存产品集成到Shiro以提供快速有效的用户体验。 -
Cryptography(org.apache.shiro.crypto.*)
密码技术是企业安全框架的必备条件。Shiro的家秘软件包包含易于使用和理解的加密密码。hash(又名摘要 digests)和不同编码器实现的表示形式。该软件包中的所有类都被精心设计以使其易于使用和理解。使用Java本机加密技术支持的人都知道很难用。Shiro的家秘API简化了复杂的Java机制并使加密技术更易于被普通人使用。
-
Realms(org.apache.shiro.realm.Realm)
如上所述,Realms充当Shiro与您的应用程序的安全数据之间的桥梁或连机器。当真正需要与安全性相关的数据(例如用户帐户)进行交互以执行身份验证(登录)和授权(访问控制)时,Shiro会从一个或多个为应用程序配置的Realms中查找许多此类内容。 您可以根据需要配置任意多个Realms(通常每个数据源一个),并且Shiro会根据需要与它们进行协调,以进行身份验证和授权。
The SecurityManager
由于Shiro的API鼓励以Subject
为中心的编程方法,因此大多数应用程序开发人员很少(如果有的话)直接与SecurityManager进行交互(框架开发人员有时可能觉得这很有用)。即使如此,了解SecurityManager的功能仍然很重要,尤其是在为应用程序配置一个功能时。
Design
如前所述,应用程序的SecurityManager执行安全性操作并管理所有应用程序用户的状态。在Shiro默认的SecurityManager实现中,包含以下功能
- Authentication 认证
- Authorization 授权
- Session Management 会话管理
- Cache Management 缓存管理
- Realm coordination Realm协调(安全数据源协调
- Event propagation 事件传播
- “Remember Me” Services “记住我”
- Subject creation 创建
Subject
- Logout and more. 注销 etc…
但这是尝试在单个组件中管理许多的功能。并且,如果将所有内容归为一个实现类,则致使这些功能的灵活性和可自定义性降低。
功能耦合在一起
为了简化配置并实现灵活的配置/可插拔,Shiro的实现在设计上都是高度模块化的,因此SecurityManager(及其层次结构)的实现并不匹配。相反,SecurityManager实现主要充当轻量级的容器几乎将所有行为委托给嵌套/包装的组件。这种包装器设计反映在上面的详细架构图中。
抽出一层SecurityManager
来统合各个组件,总过组合而不是继承,来降低层次复杂性
当组件实际执行逻辑时,SecurityManager
实现知道如何以及何时协调组件以正常运行程序完成特定功能
SecurityManager
实现和组件业余JavaBeans兼容,这允许你(或者配置)通过JavaBeans访问器/更改器(accessor/mutator)方法(get/set)轻松自定义可插拔组件。这意味着Shiro的体系结构模块化可以转换为非常易于配置的自定义行为。
可以通过自定义实现来改变shiro执行逻辑,SecurityManager
中的组件可以自定义进行扩展和修改逻辑
Easy Configuration
Because of JavaBeans compatibility, it is very easy to configure the SecurityManager
with custom components via any mechanism that supports JavaBeans-style configuration, such as Spring, Guice, JBoss, etc.
We will cover Configuration next.
可以使用Spring,Guice,JBoss等轻松通过配置继承shiro
帮助文档
尽管我们希望该文档对您使用Apache Shiro所做的工作有所帮助,但社区一直在不断改进和扩展文档。 如果您想为Shiro项目提供帮助,请考虑在需要的地方更正,扩展或添加文档。 您提供的每一点帮助都会扩大社区,进而改善Shiro。
The easiest way to contribute your documentation is to submit a pull-request by clicking on the Edit
link below, send it to the User Forum or the User Mailing List.
提交文档的最简单方法是通过单击下面的“编辑”链接来提交请求请求,然后将其发送到“用户论坛”或“用户邮件列表”。
原文 https://shiro.apache.org/architecture.html