第 1 章 概述
Red Hat Single Sign-On 支持精细的授权策略，并可组合不同的访问控制机制，例如：
- 基于属性的访问控制(ABAC)
- 基于角色的访问控制(RBAC)
- 基于用户的访问控制(UBAC)
- 基于上下文的访问控制(CBAC)
基于规则的访问控制
- 使用 JavaScript
- 基于时间的访问控制
- 通过策略提供程序服务提供程序接口(SPI)支持自定义访问控制机制(ACM)
Red Hat Single Sign-On 基于一组管理 UI 和 RESTful API，提供为受保护资源和范围创建权限所需的方法，将这些权限与授权策略与授权决策相关联，并在您的应用程序和服务中实施授权决策。
资源服务器（应用程序或服务为受保护的资源）通常依赖于某种信息来确定是否应向受保护的资源授予访问权限。对于基于 RESTful 的资源服务器，这些信息通常从安全令牌获取，通常在每个请求上作为 bearer 令牌发送到服务器。对于依赖会话验证用户的 Web 应用，该信息通常存储在用户的会话中，并从那里检索每个请求。
通常，资源服务器仅根据基于角色的访问控制(RBAC)执行授权决策，其中授予用户试图访问受保护的资源的角色会根据映射到这些相同资源的角色进行检查。虽然角色非常有用，并由应用程序使用，但它们有一些限制：
- 资源和角色与角色紧密耦合和更改角色（如添加、删除或更改访问上下文）可能会影响多个资源
- 对您安全要求的更改可能会对应用程序代码进行深度更改，以反映这些更改
- 根据您的应用程序大小，角色管理可能会变得困难且容易出错
- 它不是最灵活的访问控制机制。角色不表示您是和缺少上下文信息。如果您被授予角色，您至少具有一些访问权限。
我们认为，我们需要考虑在不同区域分发用户的异构环境、具有不同本地策略、使用不同的设备，以及大量信息共享的需求，红帽单点登录授权服务可以帮助您提高应用程序和服务的授权功能：
- 使用精细授权策略和不同的访问控制机制进行资源保护
- 集中资源、权限和策略管理
- 集中策略决策点
- 基于一组基于 REST 的授权服务进行 REST 安全性
- 授权工作流和用户管理的访问
- 基础架构，以帮助避免项目间的代码复制（并重新部署），并快速适应安全要求的变化。
1.1. 架构
从设计的角度，授权服务基于一组精心定义的授权模式，提供这些功能：
策略管理点(PAP)
提供一组基于 Red Hat Single Sign-On 管理控制台的 UI，以管理资源服务器、资源、范围、权限和策略。其中的一部分也通过使用 保护 API 远程来完成。
策略决策点(PDP)
提供可分发策略决策点，以根据请求的权限相应地评估授权请求和策略的位置。如需更多信息，请参阅 获取权限。
策略实施点(PEP)
为不同的环境提供实现，在资源服务器端实际强制执行授权决策。红帽单点登录提供一些内置 政策增强程序。
策略信息点(PIP)
根据 Red Hat Single Sign-On Authentication Server，您可以在评估授权策略期间从身份和运行时环境获取属性。
1.1.1. 授权进程
三个主要进程定义了了解如何使用 Red Hat Single Sign-On 为应用程序启用精细授权所需的步骤：
- 资源管理
- 权限和策略管理
- 策略强制
1.1.1.1. 资源管理
资源管理 涉及所有必要的步骤来定义受保护的内容。
首先，您需要指定您要保护的 Red Hat Single Sign-On，它代表一个 Web 应用程序或一组或多个服务。有关资源服务器的更多信息，请参阅 术语。
资源服务器使用红帽单点登录管理控制台管理。您可以启用任何注册的客户端应用程序作为资源服务器，并开始管理您要保护的资源和范围。
资源可以是网页、RESTFul 资源、文件系统中的文件、EJB 等。它们可以代表一组资源（就像 Java 中的类）或代表一个和特定资源。
例如，您可能有一个代表所有 银行 帐户的银行帐户资源，并使用它来定义对所有银行帐户通用的授权策略。但是，您可能想为 Alice 帐户 （属于客户的资源实例）定义特定的策略，其中只有所有者可以访问某些信息或执行操作。
资源可以使用 Red Hat Single Sign-On Administration Console 或 Protection API 进行管理。在后者的情况下，资源服务器可以远程管理其资源。
范围通常代表可以对资源执行的操作，但它们不限于该资源。您还可以使用范围来代表资源中的一个或多个属性。
1.1.1.2. 权限和策略管理
在定义了资源服务器以及您要保护的所有资源后，您必须设置权限和策略。
此过程涉及所有必要步骤，以实际定义管理资源的安全和访问要求。
策略定义了访问或对某些对象（资源或范围）执行操作的条件，但它们不会与受到保护的内容关联。它们是通用的，可以重复利用以构建权限或更复杂的策略。
例如，若要允许访问由角色"用户高级"授予的用户，可以使用 RBAC （基于角色的访问控制）。
Red Hat Single Sign-On 提供一些内置策略类型（及其相应策略供应商）涵盖了最常见的访问控制机制。您甚至可以根据使用 JavaScript 编写的规则创建策略。
定义了策略后，您可以开始定义权限。权限与其保护的资源相结合。在这里，您需要指定您要保护的内容（资源或范围）以及必须满足授予或拒绝权限的策略。
1.1.1.3. 策略强制
策略强制 涉及实际对资源服务器实施授权决策的必要步骤。这可以通过在能够与授权服务器通信的资源服务器中启用 策略强制点 或 PEP 实现，请求授权数据并根据服务器返回的决策和权限控制对受保护资源的访问。
Red Hat Single Sign-On 提供了一些内置 策略强制 实现，您可以使用它们根据运行的平台来保护应用程序。
1.1.2. 授权服务
授权服务包括以下 RESTFul 端点：
- 令牌端点
- 资源管理端点
- 权限管理端点
这些服务各自提供一种特定的 API，涵盖了授权流程中涉及的不同步骤。
1.1.2.1. 令牌端点
OAuth2 客户端（如前端应用）可以使用令牌端点从服务器获取访问令牌，并将这些令牌用于访问由资源服务器（如后端服务）保护的资源。同样，Red Hat Single Sign-On Authorization Services 为 OAuth2 提供扩展，允许根据处理与请求资源关联的所有策略来发布访问令牌。这意味着资源服务器可以根据服务器获得的权限强制访问其受保护的资源，并由访问令牌持有。在 Red Hat Single Sign-On Authorization Services 中，具有权限的访问令牌被称为 Requesting unsupported Token 或 RPT for short。
如需更多信息，请参阅 获取权限。
1.1.2.2. 保护 API
Protection API 是一组 兼容 UMA 的端点，为资源服务器提供操作，以帮助它们管理与其关联的资源、范围、权限和策略。只有资源服务器可以访问此 API，它还需要 uma_protection 范围。
保护 API 提供的操作可以分为两个主要组：
资源管理
- 创建资源
- 删除资源
- Id 查找
- 查询
权限管理
- 问题 Permission Tickets
默认情况下启用 Remote Resource Management。您可以使用 Red Hat Single Sign-On 管理控制台进行更改，并只允许通过控制台进行资源管理。
使用 UMA 协议时，保护 API 的 Permission Tickets 的确是整个授权过程的重要组成部分。如后续小节中所述，它们代表客户端所请求的权限，并发送到服务器来获取最终令牌，以便在评估与请求的资源和范围关联的权限和策略时获得所有权限。
如需更多信息，请参阅 保护 API。
