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