Overview
Keycloak支持细粒度的授权策略，并且能够组合不同的访问控制机制，例如：
- 基于属性的访问控制(ABAC)
- 基于以角色的访问控制(RBAC)
- 基于用户的访问控制(UBAC)
- 基于上下文的访问控制(CBAC)
- 基于规则的访问控制
- 基于时间的访问控制
- 通过策略提供程序服务提供程序接口(SPI)支持自定义访问控制机制(acm)
Keycloak 基于一组管理 ui 和一个 RESTful API，并提供了必要的方法来创建受保护资源和范围的权限，将这些权限与授权策略关联起来，并在应用程序和服务中执行授权决策。
资源服务器(为受保护资源服务的应用程序或服务)通常依赖某种类型的信息来决定是否应该授予受保护资源访问权。 对于基于 restful 的资源服务器，该信息通常从安全令牌获得，通常在每次向服务器发送请求时作为承载令牌发送。 对于依赖会话验证用户身份的 web 应用程序，该信息通常存储在用户的会话中，并从该会话中检索每个请求。
通常，资源服务器只执行基于以角色为基础的存取控制的授权决策，其中授予试图访问受保护资源的用户的角色将根据映射到这些相同资源的角色进行检查。 虽然角色非常有用，应用程序也会使用它们，但它们也有一些限制:
- 资源和角色是紧密耦合的，对角色的更改(例如添加、删除或更改访问上下文)可能会影响多个资源
- 对安全需求的更改可能意味着对应用程序代码进行深度更改以反映这些更改
- 根据应用程序的大小，角色管理可能会变得困难并且容易出错
- 它不是最灵活的访问控制机制。 角色并不代表您是谁，并且缺乏上下文信息。 如果您被授予了一个角色，那么您至少有一些访问权限。
考虑到今天我们需要考虑异构环境，其中用户分布在不同的区域，使用不同的本地策略，使用不同的设备，以及对信息共享的高需求，Keycloak Authorization Services 可以通过提供以下功能来帮助您提高应用程序和服务的授权能力:
- 使用细粒度授权策略和不同的访问控制机制进行资源保护
- 集中式资源、权限和策略管理
- 集中式策略决策点
- 基于一组基于 REST 的授权服务的 REST 安全性
- 授权工作流和用户管理访问
- 有助于避免在项目之间进行代码复制(和重新部署)并快速适应安全需求中的更改的基础结构。
Architecture
从设计角度来看，Authorization Services 基于一组定义良好的授权模式，提供了以下功能:
- 政策管理点(PAP)：提供一组基于 Keycloak 管理控制台的 ui，用于管理资源服务器、资源、范围、权限和策略。 其中一部分也是通过使用 protectionapi 远程完成的。
- 策略决策点(PDP)：提供一个可分发的策略决策点，指向在何处发送授权请求，并使用请求的权限相应地评估策略。 有关详细信息，请参阅获取权限。
- 策略执行点(PEP)：提供不同环境的实现，以在资源服务器端实际执行授权决策。 Keycloak 提供了一些内置的策略执行器。
- 政策资讯点(PIP)：基于 Keycloak Authentication Server，您可以在评估授权策略中从标识和执行期函式库获取属性。
授权过程
三个主要过程定义了理解如何使用 Keycloak 对应用程序进行细粒度授权的必要步骤:
- 资源管理
- 许可及策略管理
- 策略执行
资源管理
资源管理包括所有必要的步骤来定义什么是受保护的。
首先，您需要指定 Keycloak要保护的项目，它通常表示一个 web 应用程序或一组或多个服务。 有关资源服务器的更多信息，请参见术语。使用 Keycloak 管理控制台管理资源服务器。 在那里，您可以将任何已注册的客户机应用程序启用为资源服务器，并开始管理要保护的资源和范围。
资源可以是网页、 RESTFul 资源、文件系统中的文件、 EJB 等等。 它们可以表示一组资源(就像 Java 中的 Class) ，也可以表示单个特定的资源。
例如，您可能有一个代表所有银行账户的银行账户资源，并使用它来定义对所有银行账户通用的授权策略。 但是，您可能希望为 Alice Account (一个属于客户的资源实例)定义特定的策略，其中只允许所有者访问某些信息或执行操作。
资源可以使用 Keycloak 管理控制台或保护 API 来管理。 在后一种情况下，资源服务器能够远程管理它们的资源。
作用域通常表示可以在资源上执行的操作，但它们不仅限于此。 还可以使用范围表示资源中的一个或多个属性。
许可及策略管理
一旦定义了资源服务器和要保护的所有资源后，你必须设置权限和策略。这个过程包括所有必要的步骤，以实际定义管理资源的安全性和访问需求。
策略定义了必须满足的条件，以访问或执行对某些东西(资源或范围)的操作，但它们并不与它们所保护的东西绑定在一起。 它们是通用的，可以重用来构建权限或更复杂的策略。
例如，为了只允许拥有“ User Premium”角色的用户访问一组资源，您可以使用 RBAC (以角色为基础的存取控制)。
Keycloak 提供了一些内置策略类型(以及它们各自的策略提供者) ，涵盖了最常见的访问控制机制。 你甚至可以根据使用 JavaScript 编写的规则创建策略。
一旦定义了策略，就可以开始定义权限了。 权限与要保护的资源耦合。 这里您指定要保护的内容(资源或范围)以及授予或拒绝权限必须满足的策略。
策略执行
策略执行包括对资源服务器实际实施授权决策的必要步骤。这是通过在资源服务器上启用策略执行点来实现的，该资源服务器能够与授权服务器通信，请求授权数据，并根据服务器返回的决策和权限控制对受保护资源的访问。
Keycloak 提供了一些内置的 Policy Enforcers 实现，您可以根据应用程序运行的平台使用它们来保护应用程序。
授权服务
授权服务由以下 RESTFul 端点组成:
- Token Endpoint
- Resource Management Endpoint
- Permission Management Endpoint
这些服务中的每一个都提供了一个特定的 API，涵盖了授权过程中涉及的不同步骤。
Token Endpoint
Oauth2 clients(例如前端应用程序)可以使用token endpoint从服务器获取访问令牌，并使用这些相同的令牌访问受资源服务器保护的资源(例如后端服务)。 同样，Keycloak Authorization Services 为 OAuth2提供扩展，允许根据与所请求的资源或范围相关的所有策略的处理发出访问令牌。 这意味着资源服务器可以根据服务器授予的权限和访问令牌持有的权限强制访问其受保护的资源。 在 Keycloak Authorization Services 中，具有权限的访问令牌称为请求方令牌(requestparty Token)或简称为 RPT。有关详细信息，请参阅获取权限。
Protection API
Protection API 是一组符合 uma 的端点——为资源服务器提供操作，以帮助它们管理与其相关的资源、范围、权限和策略。 只有资源服务器被允许访问这个 API，这也需要一个 uma 保护范围。
Protection API提供的操作可以分为两大类:
- Resource Management：Create Resource，Delete Resource，Find by Id，Query
- Permission Management：Issue Permission Tickets
默认情况下，远程资源管理是开启的。 您可以使用 Keycloak 管理控制台更改这一点，并且只允许通过控制台进行资源管理。在使用 UMA 协议时，使用保护 API 发布许可证是整个授权过程的重要组成部分。 如后续部分所述，它们表示客户机请求的权限，这些权限被发送到服务器以获得最终令牌，其中包含在评估与请求的资源和范围相关的权限和策略期间授予的所有权限。有关更多信息，请参见Protection API。
术语
在继续之前，重要的是要了解Keycloak授权服务引入的这些术语和概念。
Resource Server
根据 OAuth2术语，资源服务器是托管受保护资源的服务器，能够接受和响应受保护资源请求。
资源服务器通常依赖某种类型的信息来决定是否授予对受保护资源的访问权。 对于基于 restful 的资源服务器，该信息通常在安全令牌中携带，通常作为承载令牌与每个请求一起发送到服务器。 依赖会话对用户进行身份验证的 Web 应用程序通常将该信息存储在用户的会话中，并从那里为每个请求检索该信息。在 Keycloak，任何机密客户端应用程序都可以充当资源服务器。 这个客户机的资源及其各自的范围受到一组授权策略的保护和管理。
Resource
资源是应用程序和组织的资产的一部分。 它可以是一组或多个端点、一个经典的 web 资源(如 HTML 页面)等等。 在授权策略术语中，资源是受保护的对象。
每个资源都有一个唯一标识符，它可以表示一个资源或一组资源。 例如，您可以管理一个“银行帐户资源” ，该资源表示并定义了一组针对所有银行帐户的授权策略。 但是您也可以有一个名为 Alice’s Banking Account 的不同资源，它表示单个客户拥有的单个资源，该资源可以有自己的一组授权策略。
Scope
资源的作用域是可以在资源上执行的有界访问范围。 在授权策略术语中，范围是逻辑上可以应用于资源的潜在多个谓词之一。它通常表示可以用给定的资源做什么。 范围示例有视图、编辑、删除等。范围也可以与资源提供的特定信息相关联。 在这种情况下，您可以有一个项目资源和一个cost范围，其中cost范围用于定义特定的策略和权限，以便用户访问项目的cost。
Permission
Policy
策略定义了授予对象访问权限必须满足的条件。 与权限不同，您不指定受保护的对象，而是指定访问给定对象(例如，资源、范围或两者)必须满足的条件。策略与可用于保护资源的不同访问控制机制(acm)密切相关。 使用策略，您可以实现基于属性的访问控制(ABAC)、基于以角色的访问控制(RBAC)、基于上下文的访问控制，或者这些策略的任何组合。
Keycloak 利用策略的概念以及如何通过提供聚合策略的概念来定义它们，在这个概念中，您可以构建“策略的策略”并仍然控制评估的行为。 Keycloak Authorization Services 中的策略实现遵循分治技术，而不是编写一个包含访问给定资源必须满足的所有条件的大型策略。 也就是说，您可以创建单个策略，然后使用不同的权限重用它们，并通过组合单个策略构建更复杂的策略。
Policy Provider
策略提供者是特定策略类型的实现。 Keycloak 提供了内置的策略，由相应的策略提供者支持，您可以创建自己的策略类型来支持您的特定需求。Keycloak 提供了一个 SPI (服务提供者接口) ，您可以使用它插入您自己的策略提供者实现。
Permission Ticket
一个Permission Ticket是用户管理访问(User-Managed Access，UMA)规范定义的一种特殊令牌类型，该规范提供了一个不透明的结构，其形式由授权服务器决定。 该结构表示客户机请求的资源和 / 或范围、访问上下文以及必须应用于授权数据请求(请求方令牌 RPT)的策略。 在 UMA，Permission Ticket对于支持个人对个人的分享和个人对组织的分享至关重要。 对授权工作流使用Permission Ticket可以实现从简单到复杂的一系列场景，其中资源所有者和资源服务器根据控制对这些资源的访问的细粒度策略对其资源进行完全控制。有关许可证的详细信息，请参阅用户管理访问和 UMA 规范。
来源：oschina
链接：https://my.oschina.net/wecanweup/blog/3193330