High-Level Overview
在最高的概念层次，Shiro 的架构有3 个主要的概念：Subject，SecurityManager 和Realms。下面的关系图是关于这 些组件是如何交互的高级概述，而且我们将会在下面讨论每一个概念：
Subject：在我们的教程中已经提到，Subject 实质上是一个当前执行用户的特定的安全“视图”。鉴于"User"一词通常意味着一个人，而一个Subject 可以是一个人，但它还可以代表第三方服务，daemon account，cron job，或其他类似的任何东西——基本上是当前正与软件进行交互的任何东西。所有Subject 实例都被绑定到（且这是必须的）一个SecurityManager 上。当你与一个Subject 交互时，那些交互作用转化为与SecurityManager 交互的特定subject 的交互作用。
SecurityManager：SecurityManager 是Shiro 架构的心脏，并作为一种“保护伞”对象来协调内部的安全组件共同构成一个对象图。然而，一旦SecurityManager 和它的内置对象图已经配置给一个应用程序，那么它单独留下来，且应用程序开发人员几乎使用他们所有的时间来处理Subject API。我们稍后会更详细地讨论SecurityManager，但重要的是要认识到，当你正与一个Subject 进行交互时，实质上是幕后的SecurityManager 处理所有繁重的Subject 安全操作。这反映在上面的基本流程图。
Realms：Realms 担当Shiro 和你的应用程序的安全数据之间的“桥梁”或“连接器”。当它实际上与安全相关的数据如用来执行身份验证（登录）及授权（访问控制）的用户帐户交互时，Shiro 从一个或多个为应用程序配置的Realm 中寻找许多这样的东西。在这个意义上说，Realm 本质上是一个特定安全的DAO：它封装了数据源的连接详细信息，使Shiro 所需的相关的数据可用。当配置Shiro 时，你必须指定至少一个Realm 用来进行身份验证和/或授权。SecurityManager可能配置多个Realms，但至少有一个是必须的。Shiro 提供了立即可用的Realms 来连接一些安全数据源（即目录），如LDAP，关系数据库（JDBC），文本配置源，像INI 及属性文件，以及更多。你可以插入你自己的Realm 实现来代表自定义的数据源，如果默认地Realm 不符合你的需求。像其他内置组件一样，Shiro SecurityManager 控制Realms 是如何被用来获取安全和身份数据来代表Subject 实例的。
Detailed Architecture
下图展示了Shiro 的核心架构概念，紧跟其后的是每个的简短总结：
Subject(org.apache.shiro.subject.Subject)
当前与软件进行交互的实体（用户，第三方服务，cron job，等等）的安全特定“视图”。
SecurityManager(org.apache.shiro.mgt.SecurityManager)
如上所述，SecurityManager 是Shiro 架构的心脏。它基本上是一个“保护伞”对象，协调其管理的组件以确保它们能够一起顺利的工作。它还管理每个应用程序用户的Shiro 的视图，因此它知道如何执行每个用户的安全操作。
Authenticator(org.apache.shiro.authc.Authenticator)
Authenticator 是一个对执行及对用户的身份验证（登录）尝试负责的组件。当一个用户尝试登录时，该逻辑被Authenticator 执行。Authenticator 知道如何与一个或多个Realm 协调来存储相关的用户/帐户信息。从这些Realm 中获得的数据被用来验证用户的身份来保证用户确实是他们所说的他们是谁。
Authentication Strategy(org.apache.shiro.authc.pam.AuthenticationStrategy)
如果不止一个Realm 被配置，则AuthenticationStrategy 将会协调这些Realm 来决定身份认证尝试成功或失败下的条件（例如，如果一个Realm 成功，而其他的均失败，是否该尝试成功？ 是否所有的Realm必须成功？或只有第一个成功即可？）。
Authorizer(org.apache.shiro.authz.Authorizer)
Authorizer 是负责在应用程序中决定用户的访问控制的组件。它是一种最终判定用户是否被允许做某事的机制。与Authenticator 相似，Authorizer 也知道如何协调多个后台数据源来访问角色恶化权限信息。Authorizer 使用该信息来准确地决定用户是否被允许执行给定的动作。
SessionManager(org.apache.shiro.session.SessionManager)
SessionManager 知道如何去创建及管理用户Session 生命周期来为所有环境下的用户提供一个强健的Session体验。这在安全框架界是一个独有的特色——Shiro 拥有能够在任何环境下本地化管理用户Session 的能力，即使没有可用的Web/Servlet 或EJB 容器，它将会使用它内置的企业级会话管理来提供同样的编程体验。
SessionDAO 的存在允许任何数据源能够在持久会话中使用。
SessionDAO(org.apache.shiro.session.mgt.eis.SessionDAO)
SesssionDAO 代表SessionManager 执行Session 持久化（CRUD）操作。这允许任何数据存储被插入到会话管理的基础之中。
CacheManager(org.apahce.shiro.cache.CacheManager)
CacheManager 创建并管理其他Shiro 组件使用的Cache 实例生命周期。因为Shiro 能够访问许多后台数据源，由于身份验证，授权和会话管理，缓存在框架中一直是一流的架构功能，用来在同时使用这些数据源时提高性能。任何现代开源和/或企业的缓存产品能够被插入到Shiro 来提供一个快速及高效的用户体验。
Cryptography(org.apache.shiro.crypto.*)
Cryptography 是对企业安全框架的一个很自然的补充。Shiro 的crypto 包包含量易于使用和理解的cryptographicCiphers，Hasher（又名digests）以及不同的编码器实现的代表。所有在这个包中的类都被精心地设计以易于使用和易于理解。任何使用Java 的本地密码支持的人都知道它可以是一个难以驯服的具有挑战性的动物。Shiro的cryptoAPI 简化了复杂的Java 机制，并使加密对于普通人也易于使用。
Realms(org.apache.shiro.realm.Realm)
如上所述，Realms 在Shiro 和你的应用程序的安全数据之间担当“桥梁”或“连接器”。当它实际上与安全相关的数据如用来执行身份验证（登录）及授权（访问控制）的用户帐户交互时，Shiro 从一个或多个为应用程序配置的Realm 中寻找许多这样的东西。你可以按你的需要配置多个Realm（通常一个数据源一个Realm），且Shiro 将为身份验证和授权对它们进行必要的协调。The SecurityManager因为Shiro的API 鼓励一个以Subject 为中心的编程方式，大多数应用程序开发人员很少，如果真有，与SecurityManager直接进行交互（框架开发人员有时候会觉得它很有用）。即便如此，了解如何SecurityManager 是如何工作的仍然是很重要的，尤其是在为应用程序配置一个SecurityManager 的时候。
Design
如前所述，应用程序的SecurityManager 执行安全操作并管理所有应用程序用户的状态。在Shiro 的默认SecurityManager 实现中，这包括：
Authentication
Authorization
Session Management
Cache Management
Realm coordination
Event propagation
"Remember Me" Services
Subject creation
Logout
以及更多。
但这是许多功能来尝试管理一个单一的组件。而且，使这些东西灵活而又可定制将会是非常困难的，如果一切都集中到一个单一的实现类。为了简化配置并启用灵活配置/可插性，Shiro 的实现都是高度模块化设计——由于如此的模块化，SecurityManager实现（以及它的类层次结构）并没有做很多事情。相反，SecurityManager 实现主要是作为一个轻量级的“容器”组件，委托计划所有的行为到嵌套/包裹的组件。这种“包装”的设计体现在上面的详细构架图。
----------------------
Apache Shiro Terminology
请花2 分钟来阅读和理解它——这很重要。真的。这里的术语和概念在文档的任何地方都被涉及到，它将在总体上大大简化你对Shiro 和安全的理解。
由于所使用的术语使得安全可能令人困惑。我们将通过澄清一些核心概念使生活更容易，你将会看到Shiro API 是如何很好地反映了它们：
Authentication
身份验证是验证Subject 身份的过程——实质上是证明某些人是否真的是他们所说的他们是谁。当认证尝试成功后，应用程序能够相信该subject 被保证是其所期望的。
Authorization
授权，又称为访问控制，是决定一个user/Subject 是否被允许做某事的过程。它通常是通过检查和解释Subject的角色和权限（见下文），然后允许或拒绝到一个请求的资源或功能来完成的。
Cipher
密码是进行加密或解密的一种算法。该算法一般依赖于一块被称为key 的信息。基于不同的key 的加密算法也是不一样的，所有解密没有它是非常困难的。
密码有不同的表现形式。分组密码致力于符号块，通常是固定大小的，而流密码致力于连续的符号流。对称性密码加密和解密使用相同的密钥（key），而非对称性加密使用不同的密钥。如果非对称性加密的密钥不能从其他地方得到，那么可以创建公钥/私钥对公开共享。
Credential
凭证是一块信息，用来验证user/Subject 的身份。在认证尝试期间，一个（或多个）凭证与Principals(s)被一同提交，来验证user/Subject 所提交的确实是所关联的用户。证书通常是非常秘密的东西，只有特定的user/Subject 才知道，如密码或PGP 密钥或生物属性或类似的机制。这个想法是为principal 设置的，只有一个人会知道正确的证书来“匹配”该principal。如果当前user/Subject提供了正确的凭证匹配了存储在系统中的，那么系统可以假定并信任当前user/Subject 是真的他们所说的他们是谁。信任度随着更安全的凭证类型加深（如，生物识别签名 > 密码）。
Cryptography
加密是保护信息不受不希望的访问的习惯做法，通过隐藏信息或将它转化成无意义的东西，这样没人可以理解它。Shiro 致力于加密的两个核心要素：加密数据的密码，如使用公钥或私钥的邮件，以及散列表（也称消息摘要），它对数据进行不可逆的加密，如密码。
Hash
散列函数是单向的，不可逆转的输入源，有时也被称为消息，在一个编码的哈希值内部，有时也被称为消息摘要。它通常用于密码，数字指纹，或以字节数组为基础的数据。
Permission
权限，至少按照Shiro 的解释，是在应用程序中描述原始功能的一份声明并没有更多的功能。权限是在安全策略中最低级别的概念。它们仅定义了应用程序能够做“什么”。它们没有说明“谁”能够执行这些操作。权限只是行为的声明，仅此而已。一些权限的例子：
打开文件
浏览'/user/list'页面
打印文档
删除'jsmith'用户
Principal
Principal 是一个应用程序用户（Subject）的任何标志属性。“标志属性”可以是任何对你应用程序有意义的东西——用户名，姓，名，社会安全号码，用户ID 等。这就是它——没什么古怪的。
Shiro 也引用一些我们称之为Subject 的primary principal 的东西。一个primary principal 是在整个应用程序中唯一标识Subject 的principal。理想的primary principal 是用户名或RDBMS 用户表主键——用户ID。对于在应用程序中的用户（Subject）来说，只有一个primary principal
Realm
Realm 是一个能够访问应用程序特定的安全数据（如用户，角色和权限）的组件。它可以被看作是一个特定安全的DAO（Data Access Object）。Realm 将这些应用程序特定的数据转换成Shiro 能够理解的格式，这样Shiro反过来能够提供一个单一的易于理解的Subject 编程API，无论有多少数据源存在或无论你的数据是什么样的应用程序特定的格式。
Realm 通常和数据源是一对一的对应关系，如关系数据库，LDAP 目录，文件系统，或其他类似资源。因此，Realm 接口的实现使用数据源特定的API 来展示授权数据（角色，权限等），如JDBC，文件IO，Hibernate 或JPA，或其他数据访问API。
Role
基于你对话的对象，一个角色的定义是可以多变的。在许多应用程序中，它充其量是个模糊不清的概念，人们用它来隐式定义安全策略。Shiro 偏向于把角色简单地解释为一组命名的权限的集合。这就是它——一个应用程序的唯一名称，聚集一个或多个权限声明。这是一个比许多应用程序使用的隐式的定义更为具体的定义。如果你选择了你的数据模型反映Shiro 的假设，你会发现将有更多控制安全策略的权力。
Session
会话是一个在一段时间内有状态的数据，其上下文与一个单一的与软件系统交互的user/Subject 相关联。当Subject 使用应用程序时，能够从会话中添加/读取/删除数据，并且应用程序稍后能够在需要的地方使用该数据。会话会被终止，由于user/Subject 注销或会话不活动而超时。对于那些熟悉HttpSession 的，Shiro Session 服务于同一目标，除了Shiro 会话能够在任何环境下使用，甚至在没有Servlet 容器或EJB 容器的环境。
Subject
Subject 只是一个精挑细选的安全术语，基本上的意思是一个应用程序用户的安全特定的“视图”。然而Subject不总是需要反映为一个人——它可以代表一个调用你应用程序的外部进程，或许是一个系统帐户的守护进程，在一段时间内执行一些间歇性的东西（如一个cron job）。它基本上是任何使用应用程序做某事的实体的一个代表。
扫一扫
4193
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
