盐城网站建设报价_三亚今天最新通知_友情链接搜读_重庆森林壁纸

授权策略

在上一章中，您了解了使用不同编程语言、框架和库与 Keycloak 集成的选项。您学习了如何从 Keycloak 获取令牌并使用这些令牌对用户进行身份验证。

本章将重点介绍您可以选择的不同授权策略，以及如何利用它们来使用不同的权限改造机制为您的应用程序启用授权，例如基于角色的权限改造（RBAC）、基于组的权限改造（GBAC）、OAuth2 范围和基于属性的权限改造（ABAC），以及学习如何利用 Keycloak 作为集中式授权服务器从您的应用程序外部化授权。您还将了解这些选项之间的差异以及如何选择最适合您的策略。在本章结束时，您将很好地了解如何利用 Keycloak 授权功能并为您的应用程序选择正确的授权策略。

我们将在本章中涵盖以下主题：

• 理解授权

• 使用 RBAC

• 使用 GBAC

• 使用 OAuth2 范围

• 使用 ABAC

• 使用 Keycloak 作为集中式授权服务器

了解授权

任何授权系统都会尝试帮助您回答用户是否可以访问资源并对其执行操作的问题。

这个问题的答案通常涉及以下问题：

• 用户是谁？

• 哪些数据与用户相关联？

• 访问资源的限制是什么？

通过获得这三个问题的答案，我们可以根据与用户关联的数据以及管理对资源的访问的约束来决定是否应该授予访问权限。

作为身份提供者，Keycloak 向您的应用程序颁发令牌。因此，应用程序应该期望从这些令牌中获得授权数据。Keycloak 颁发的令牌携带有关用户和用户身份验证上下文的信息；上下文可能包含有关用户正在使用的客户端的信息或在身份验证过程中收集的任何其他信息。

然而，这些约束可能涉及评估不同类型的数据，从用户拥有的单个属性到一组一个或多个角色，甚至是与当前事务相关的数据。通过依赖令牌携带的信息，应用程序可以选择不同的访问控制机制，具体取决于在实施对受保护资源的访问时，它们如何解释令牌中的声明。

有两种主要的授权模式用于实现和执行对受保护资源施加的访问约束。第一种，可能也是最常见的一种，是在应用程序级别强制实施访问控制，可以是声明性地 —— 使用一些元数据和配置，也可以是编程式地。另外一种，应用程序也可以将访问决策委托给外部服务，并根据该服务做出的决策来实施访问控制，这种策略也被称为集中式授权。不过，这两种模式并非相互排斥，在你的应用程序中同时使用这两种模式是完全可行的。在了解如何将 Keycloak 用作集中式授权服务器时，我们将在后面更详细地介绍这一点。

正如我们将在以下章节中看到的那样，Keycloak 非常灵活，允许你交换任何可能需要的信息，以便使用不同的访问控制机制在应用程序级别保护资源。它还允许你从不同的授权模式中进行选择，以管理和实施访问限制

在下一节中，我们将了解如何使用 Keycloak 为您的应用程序启用不同的授权策略。

使用 RBAC

RBAC 可能是最常用的权限改造机制之一，它允许您根据用户是否被授予角色来保护资源。

角色通常表示用户在您的组织或应用程序上下文中的角色。例如，可以授予用户管理员角色，以指示他们充当允许访问应用程序中任何资源并对其执行操作的人员。或者，可以授予他们人员经理角色，以指示他们充当允许访问与其下属相关的资源并对其执行操作的人员。

正如你从前面的章节中了解到的，Keycloak 有两类角色：领域角色和客户端角色。在领域级别定义的角色称为领域角色。这些角色通常代表用户在组织中的角色，而与领域中共存的不同客户端无关。

另一方面，客户端角色特定于客户端，其含义取决于客户端使用的语义。

何时将角色定义为领域角色或客户端角色的决定取决于该角色的范围。如果它在一个领域中跨越多个客户端同时保持相同的含义，那么领域角色是有意义的。否则，如果只有特定的客户端应该解释该角色，将其作为客户端角色更有意义。

在使用角色时，你还应该避免角色爆炸。换句话说，系统中过多的角色会使事情难以管理。避免这种情况的一种方法是非常谨慎地创建角色，要考虑到它们所涉及的范围（全域或客户端范围）以及在你的应用程序中与它们相关联的权限的粒度。角色的范围越细粒度，你的系统中就会有越多的角色。作为一个经验法则，不要在你的系统中使用角色进行细粒度授权。它们并不是为此而设计的。

在 Keycloak 中，您可以将角色授予组。这是一个强大的功能，其中组的成员会自动为他们所属的组授予角色。通过利用此功能，您应该能够通过避免单独向多个用户授予权限来克服一些角色管理问题。

Keycloak 还提供了复合角色的概念，这是一种特殊类型的角色，它链接其他角色，被授予复合角色的用户会自动被授予此链中的任何角色（常规角色甚至是另一个复合角色）。尽管这是 Keycloak 具有的强大而独特的功能，但你应该谨慎使用它，以避免性能问题（例如在链接多个复合角色时）以及由于系统中角色的激增和与这些角色相关的权限粒度而导致的可管理性问题。作为建议，如果你需要为用户授予多个角色，应该考虑使用组并将角色分配给这些组。这是一种比使用复合角色更自然的权限模型。

你对系统角色的建模方式也会对 Keycloak 颁发的令牌大小产生影响。理想情况下，令牌应包含客户端在本地授权用户或访问使用这些令牌的其他服务时所需的最小角色集。

请记住，您的系统拥有的角色越多，维护和管理就会变得越复杂。

在本主题中，您了解了在 Keycloak 中使用 RBAC 时的主要概念。您还了解了在使用可能影响应用程序可运维性和性能的角色时的一些建议和注意事项。

在下一个主题中，我们将了解 Keycloak 在应用程序中使用它时如何帮助您实现 GBAC 和建议。

使用 GBAC

Keycloak 允许您为您的领域管理组。用户被放入组中以表示他们与组织中特定业务单元的关系（映射您的组织树），或者只是根据他们在应用程序中的角色组合在一起，例如当您希望为可以执行管理操作的用户创建一个特定组时。

通常，组和角色经常被互换使用，这在定义权限模型时会引起一些混淆。在 Keycloak 中，这两个概念有明确的区分，与角色不同，组旨在组织用户，并根据与组相关联的角色授予权限。

通过允许为组分配角色，Keycloak 使得为多个用户管理角色变得容易得多，而无需强制你为领域中的每个用户单独授予和撤销角色。

Keycloak 中的组是分层的，当颁发令牌时，可以通过查看组的路径来遍历层次结构。例如，假设有一个人力资源组。作为这个组的子组，有一个经理组。当 Keycloak 在令牌中包含有关组的信息时，应该以以下格式期望此信息：/ 人力资源 / 经理。对于服务器颁发的每个令牌，只要主体（用户）是该组的成员，此信息就应该可用。

与角色不同，组信息不会自动包含在令牌中。为此，你应该将特定的协议映射器与你的客户端相关联（或者将具有相同映射器的客户端范围相关联）。

在下一节中，您将学习如何将有关用户的组信息包含到令牌中。

将组成员映射到令牌

与角色不同，没有默认的协议映射器会自动在令牌中包含组信息。要做到这一点，我们需要为你的客户端创建一个协议映射器。

或者，您还可以创建客户端范围并将其分配给您领域中的任何客户端。

首先，让我们创建 myclient 客户端：

• Client ID: myclient

现在，在 Keycloak 中创建一个用户。

• Username : alice

导航到 myclient 设置并单击 Client 范围选项卡。在此选项卡中，您将看到为客户端配置的所有客户端范围的列表。单击 myclient-dedicated 链接以创建向客户端添加新映射器。

图 8.1：将映射器添加到客户端的专用客户端范围

要创建新映射器，请单击 Configure a new mapper 并从列表中选择 Membership 映射器。现在，配置如下：

图 8.2：创建组成员协议映射器

在此页面上，使用以下信息创建一个新的映射器：

• Name: groups

• Mapper Type: Group Membership

• Token Claim Name: groups

现在，单击保存按钮创建映射器。

现在让我们为此用户创建一个组。为此，请单击左侧菜单中的Groups链接：

图 8.3：列出组

要创建新组，请单击创建组按钮：

图 8.4：创建一个新组

让我们创建一个名为 Project Management Office 的组。在名称字段中键入此名称，然后单击创建按钮。

现在，让我们将 alice 用户添加为该组的成员。为此，导航到 alice 用户详情页，然后单击组选项卡：

图 8.5：管理用户的组成员资格

在此页面中，单击加入组按钮将用户关联为组成员。在此页面上，选择项目管理办公室组并单击加入按钮。

图 8.6：将用户分配为组的成员

alice 用户现在是项目管理办公室的成员。

现在让我们回到 myclient 详情页，使用评估工具查看如何将组信息添加到令牌中。

单击客户范围选项卡。在此选项卡中，单击Evaluate子选项卡：

图 8.7：使用评估工具检查组信息

在用户字段中搜索 alice 用户，然后单击页面左下角的生成访问令牌链接，查看生成的令牌是否包含有关用户所属组的信息：

图 8.8：评估结果

如您所见，生成的令牌现在包括一个组声明以及用户所属的组列表。在这种情况下，用户 alice 是单个 Project Management Office 组的成员。在本节中，您学习了如何管理组以及如何使用户成为组的成员。您还学习了如何使用协议映射器在令牌中包含组信息，以便您的应用程序可以使用此信息使用用户所属的组强制执行权限改造。

在下一节中，我们将了解您的应用程序如何使用自定义声明来强制访问其资源。

使用 OAuth2 scopes

Keycloak 的核心是 OAuth2 授权服务器。在纯 OAuth2 中，主要有两种类型的应用程序：客户端和资源服务器。

正如您从前面关于 OAuth2 的章节中了解到的那样，访问令牌被颁发给客户端，以便它们可以代表用户行事，其中这些令牌仅限于基于用户同意的一组范围。

另一方面，资源服务器是访问令牌的消费者，它们需要对访问令牌进行内省，以决定客户端是否可以根据用户授予的范围访问资源服务器上的受保护资源。

如你所见，使用 OAuth2 scopes进行授权完全基于用户的同意。当你希望第三方与你的 API 集成时，这是最好的策略，这样你就可以将第三方应用程序是否可以访问用户资源的决定权委托给用户。在这种策略中，重点是保护用户信息，而不是资源服务器上的常规资源。使用 OAuth2 scopes与你目前所学的其他授权策略之间存在根本区别，主要在于你要保护系统免受其影响的实体方面。通过使用 OAuth2 scopes，你是在保护系统免受客户端的影响，而例如在使用基于角色的访问控制（RBAC）时，你是在保护系统免受用户的影响。简而言之，你基本上是在检查客户端是否被允许代表用户执行某些操作或访问资源，这是 OAuth2 通常解决的委托用例。

• OAuth2 范围授权基于用户同意：在 OAuth2 授权框架中，客户端向授权服务器请求访问令牌时，会包含一个范围请求参数，指定对用户资源的访问范围。授权服务器根据用户的同意，在颁发的访问令牌中包含相应的范围信息。例如，当用户使用第三方应用登录时，第三方应用会向用户请求特定的权限范围，如访问用户的基本资料、读取联系人等。用户看到这些请求后，决定是否同意授权。只有用户同意，第三方应用才能获得相应范围的访问令牌，从而访问用户的资源。
• 适用于第三方集成 API 场景：许多开放平台（如谷歌、Facebook 等）允许第三方开发者通过 OAuth2 协议集成其 API。以谷歌地图 API 为例，第三方地图应用想要使用谷歌地图的某些功能（如获取地图数据、使用导航功能等），就需要通过 OAuth2 范围授权获取相应的权限。第三方应用向用户请求授权，用户决定是否允许第三方应用访问谷歌地图的相关资源。这样，第三方应用就可以基于用户的授权访问谷歌地图 API，为用户提供服务。
• 重点保护用户信息：在 OAuth2 scopes授权中，通过限制客户端的访问范围，确保客户端只能获取用户授权范围内的信息，避免客户端过度获取用户信息。比如，一个天气应用通过 OAuth2 授权获取用户的地理位置信息，只能在用户授权的范围内使用该信息，而不能获取用户的其他隐私信息（如通讯录、邮件等），从而保护了用户信息安全。
• 与 RBAC 的区别：RBAC（基于角色的访问控制）是根据用户的角色来分配权限，重点是控制用户对资源的访问。例如，在一个企业系统中，管理员角色可以访问和管理所有资源，普通员工角色只能访问特定的资源。而 OAuth2 范围授权主要是控制客户端对资源的访问，基于用户对客户端的授权。在使用 OAuth2 范围授权时，是在用户同意的基础上，检查客户端是否有权代表用户执行某些操作或访问资源；而 RBAC 则是直接根据用户的角色来决定其对资源的访问权限。

默认情况下，Keycloak 中的客户端被配置为不请求用户同意。原因是 Keycloak 通常用于企业用例。与委托用例相比，不需要用户同意，因为客户端在企业边界内，并且他们需要访问的资源不依赖于用户的任何同意，而是依赖于系统管理员授予他们的权限。在这里，客户端更感兴趣的是对用户进行身份验证，其中访问范围是根据与用户相关联的角色、组甚至特定属性来定义的。

在本主题中，您了解了使用 OAuth2 scopes授权访问的概念。您还了解到，这种授权策略更适合允许第三方通过您的 API 访问有关您的用户的信息。

在下一个主题中，我们将了解如何根据映射到令牌的声明授权访问。

使用 ABAC

当用户通过 Keycloak 进行身份验证时，服务器颁发的令牌包含有关身份验证上下文的重要信息。令牌包含有关已认证用户和颁发令牌的客户端的信息，以及在身份验证过程中可以收集的任何其他信息。考虑到这一点，令牌携带的任何信息都可以用于授权访问您的应用程序。它们只是映射到令牌的声明

ABAC 涉及使用与身份（由令牌表示）相关的不同属性以及有关身份验证上下文的信息来实施对资源的访问。它可能是您可以选择的最灵活的访问控制机制，对细粒度授权具有自然支持。与基于令牌的授权一起，使用 Keycloak 的应用程序可以轻松启用 ABAC 以保护其资源。

基于令牌的授权是基于对令牌的内省，并使用其中的信息来决定是否应授予访问权限。此信息表示为一组属性或声明，其值可用于实施访问控制。

以应用程序中如何使用角色来实施访问控制为例。正如你在前几章和主题中学到的那样，角色通过一组特定的声明映射到令牌上。为了使用角色实施访问控制，你的应用程序只需要使用这些声明来计算授予用户的角色，然后决定是否应该授予对特定资源的访问权限。

这与令牌中的任何其他声明没有什么不同，在令牌中，您的应用程序可以使用任何声明并使用它来强制访问。对于每个客户端，您可以定制存储在令牌中的声明和断言。为此，Keycloak 提供了一种称为协议映射器的功能。有关更多详细信息，请查看https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers中的 Keycloak 留档。

在本主题中，您了解了如何利用映射到令牌中的声明来执行 ABAC。您还了解到 Keycloak 允许您将任何您想要的信息映射到令牌，以便它们可以用于在应用程序级别强制访问。尽管 ABAC 足够灵活，可以支持多种权限改造机制，但实现和管理并不容易。

在下一个主题中，我们将了解如何使用 Keycloak 作为集中式授权服务器来利用 ABAC。

使用 Keycloak 作为集中式授权服务器

到目前为止，已经为你介绍了依赖特定访问控制机制的授权策略。除了基于属性的访问控制（ABAC）之外，这些策略依赖于关于用户的特定数据集来实施对应用程序的访问。此外，这些策略与你的应用程序紧密耦合；安全要求的变化将需要更改应用程序代码

例如，假设您的应用程序中有以下伪代码：

If (User.hasRole("manager") {
// can access the protected resource
}

在前面的代码中，我们使用 RBAC 进行了一个非常简单的检查，其中只有被授予经理角色的用户才能访问受保护的资源。如果您的需求发生了变化，并且您还需要向特定用户授予对同一资源的访问权限，或者甚至向被授予其他角色的用户授予对该资源的访问权限，或者利用 ABAC 查看有关正在访问资源的上下文的不同信息，会发生什么？

至少，你需要更改你的代码并重新部署你的应用程序，更不用说还要经历持续集成和交付过程，以确保更改已准备好投入生产。

集中式授权允许你使用外部授权服务将访问管理和决策从你的应用程序中外部化。它允许你使用多种访问控制机制，而无需将你的应用程序与它们耦合，并使用与你的应用程序引用应受保护的不同资源相同的语义来实施访问。让我们看一下以下代码，它提供了与前面示例相同的访问检查：

If (User.canAccess("Manager Resource") {
// can access the protected resource
}

从前面的代码片段可以看出，没有引用特定的权限改造机制；权限改造基于您要保护的资源，您的应用程序只关心外部授权服务授予的权限。

对管理器资源访问方式的更改不应该影响您的应用程序代码，但更改通过授权服务管理对该资源的访问的策略应该会影响您的应用程序代码。Keycloak 可以通过称为授权服务的功能充当集中式授权服务。此功能基于代表不同访问控制机制的一组策略，您可以将这些策略与要保护的资源相关联。所有这些都是通过 Keycloak 管理控制台和 REST API 进行管理的。

集中式授权的优势：传统授权策略（除 ABAC 外）依赖特定用户数据，与应用程序紧密耦合，安全需求变动时需修改应用代码和重新部署。而集中式授权借助外部授权服务，使应用程序仅关注外部服务授予的权限，访问控制基于受保护资源，能灵活应对安全需求变化，无需频繁改动应用代码。

Keycloak 授权服务功能利用 ABAC 为您的应用程序启用细粒度授权。默认情况下，一组表示不同权限改造机制的策略是开箱即用的，可以聚合这些策略，以便在保护资源时轻松支持多种授权策略。Keycloak 授权服务功能还允许您控制对与您正在保护的资源关联的特定操作和属性的访问。

使用集中式授权服务器时的一个常见问题是需要额外的往返来获取访问决策。通过利用基于令牌的授权，Keycloak 授权服务功能允许你通过颁发具有服务器授予的所有权限的令牌来克服这个问题，这样使用这些令牌的应用程序就不需要执行额外的网络调用，而是在本地检查令牌。它还支持增量授权，在这种情况下，令牌被颁发一组有限的权限，并可以根据需要获得新的权限。

• 集中式授权服务器的常见问题：使用集中式授权服务器时，一个普遍存在的问题是应用程序为获取访问决策，往往需要进行额外的网络往返请求。这是因为应用在每次访问受保护资源时，可能都要向集中式授权服务器询问当前用户是否有权限访问，增加了网络开销和延迟，影响系统性能 。
• Keycloak 授权服务的解决方案：Keycloak 授权服务借助基于令牌的授权机制来解决这一问题。服务器在颁发令牌时，会将所有已授予的权限包含在令牌中。这样一来，使用这些令牌的应用程序无需再频繁地向服务器发起额外的网络请求以获取访问决策，而是可以直接在本地对令牌进行解析和验证，查看令牌中包含的权限信息，判断当前用户是否有权访问相应资源，减少了网络通信次数，提高了系统的响应速度和性能。
• Keycloak 的增量授权特性：Keycloak 还支持增量授权。在这种模式下，服务器最初颁发的令牌所包含的权限范围较窄。随着应用程序的运行，如果用户在后续操作中需要访问其他受保护资源，且当前令牌权限不足时，应用程序可以根据实际需求获取新的权限。这种方式既保证了初始时令牌的简洁性和安全性，又能灵活满足用户在不同场景下对权限的动态需求

有关 Keycloak 授权服务的更多详细信息，请查看https://www.keycloak.org/docs/latest/authorization_services/

在本节中，您了解了集中式授权以及 Keycloak 授权服务可用于实现这种形式的授权。您还了解到，与基于令牌的授权一起，Keycloak 授权服务可帮助应用程序为应用程序启用细粒度授权。

小结

在本章中，您了解了授权访问应用程序中受保护资源的不同策略。通过利用基于令牌的授权，应用程序应该能够在本地或通过自省端点自省令牌，并使用它们的声明来支持不同的权限改造机制，如 RBAC、GBAC 和 ABAC，或者使用用户授予代表他们行事的客户端应用程序的范围。

您还了解到，Keycloak 可用作集中式授权服务，以将授权与应用程序分离，其中访问决策由 Keycloak 根据通过服务器管理的资源和策略做出。

在下一章中，我们将介绍在生产环境中运行 Keycloak 的主要步骤。

问题

1. 如何防止令牌变得太大，同时仍提供必要的数据以在应用程序级别强制访问资源？

2. 你如何决定一个角色应该是领域还是客户端角色？

3. 是否可以根据身份验证期间收集的信息强制访问？

4. 是否可以更改 Keycloak 将角色映射到令牌的方式？

5. 前面两种策略是否相互排斥？

进一步阅读

有关本章所涵盖主题的更多信息，请参阅以下链接：

• keycloak 角色：https://www.keycloak.org/docs/latest/server_admin/#roles
• keycloak 组：https://www.keycloak.org/docs/latest/server_admin/#groups
• Keycloak 协议映射器：https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers
• Keycloak 客户端范围：https://www.keycloak.org/docs/latest/server_admin/#_client_scopes
• keycloak 授权服务：https://www.keycloak.org/docs/latest/authorization_services