Keycloak - 基于资源的角色和范围基础身份验证

Question

我有一个场景，我想限制 keycloak 中的用户

我有用户

用户可以在多个帐户中访问多个帐户，使用可以是管理员或代理（读者）

user
|
|
|-------account-1
|            |
|            |-------admin
|-------account-2
|            |
|            |-------agent

我们如何在 Keycloak 中将其映射到策略、权限和角色？

任何参考文档任何真正有帮助的例子

还基于：keycloak 中的资源、范围、权限和策略

根据安迪的回答，我创建了一个资源帐户和角色管理员和代理。

创建与示例相同的策略。

我期待向 JWT 令牌添加范围（身份验证范围）和角色，如何映射该部分，以便 API 网关或服务可以进一步验证。

Answer 1

@changa，我根据我们的讨论重写了我的答案。希望这可以帮助！

在回答之前，让我先澄清一些关键领域。我对您链接的答案的主要关注点实际上是如何使用该Evaluate工具，并且我并没有真正深入研究某些概念 - 所以让我们这样做:)

在 Keycloak 中，您将遇到客户端和授权范围。有关这些术语的正式定义，请查看服务器管理指南中的核心概念和术语，简单地说：

客户端范围是通过参数请求时授予scope客户端的范围（一旦资源所有者允许）。请注意，还有一个概念Default Client Scope，但我选择让事情变得简单。此外，您可以利用协议和角色范围映射器来定制访问令牌中存在的声明和断言。

另一方面，在成功评估针对受保护资源的策略后，授权范围会授予客户端。这些范围并非基于用户同意而授予客户。

两者之间的主要区别实际上在于客户端何时以及如何获取这些范围。为了帮助您直观地了解这一切，这里有一个场景：

1. 一位著名的武术家Bob通过 Keycloak 进行身份验证

2. Bob出现一个同意屏幕，要求他分享他的名字、他的战斗风格和他的年龄。

3. Bob选择透露他的名字和战斗风格，但他拒绝透露自己的年龄。

4. 当我们现在检查令牌时，我们将看到scope访问令牌属性的以下（完全组成的）条目：name和fighting_style。

5. 此外，假设我们已经设置了几个协议映射器（例如用户属性映射器类型 - 有很多）来通过以下令牌声明显示全名和战斗风格的值：fighter_name并且martial_arts当上述两个Client Scopes存在时在访问令牌中。除了前面提到的两个范围之外，在检查访问令牌时我们还会看到类似fighter_name: Robert Richards和 的内容。martial_arts: Freestyle Karate

   • 旁注：考虑到这个答案的长度，我决定跳过这个主题，但请观看这个7 分钟左右的精彩视频以及相关的GitHub 项目以获取更多信息。README 非常好。

6. 此外，我们假设Bob映射到名为 的领域角色Contestant和 的客户端角色Fighter，并且在共享此信息时我们确实在 Keycloak 中设置了任何限制。因此，除了上面提到的所有内容之外，我们还会在令牌内看到这些信息。

   • 不用说，这对我来说过于简单化了，因为我只是为演示搭建舞台。目的，并且访问令牌内还有更多信息。

7. Bob不喜欢锦标赛的分组方式，因为他渴望尽快与世界冠军较量，因此他尝试通过发送针对 的请求来改变自己的排名tournament/tekken6/bracket/{id}。该资源与范围相关联bracket:modify。此外，还有一项权限将相关资源与名为 的基于角色的策略相关联Referee Role Required。如果Bob是，Referee那么他将被授予该bracket:modify范围，但由于他不是，那么他将被拒绝该范围。

   • 当谈到 Keycloak 中授权过程的内部运作时，我几乎没有触及表面。欲了解更多信息，请查看本实用指南。您可以使用 UMA 做一些非常酷的事情。

好的，理论就足够了。让我们设置环境来演示这一切。我正在使用以下内容：

• 一个境界叫做demo
• 有一个客户叫my-demo-client
• 客户端范围称为client_roles
• 2 个用户 -paul和law
• 两个领域级别的角色 -Admin以及Reader
• 两个客户级角色 -demo-admin以及demo-reader

请注意，我将使用 Keycloak 12.0.4，并且我将跳过几乎所有基本设置说明。我只会分享相关的部分。如果您不确定如何进行设置，请查看入门指南或此答案。答案包含版本 8 的步骤，但据我所知，差异非常小。

关联用户和角色

为了paul与Admin、Reader、bank-admin和bank-reader角色关联，请执行以下操作：

• Click on Users > View all users > Click on the ID value for paul > Click on Role Mappings > Under Realm Roles move Admin and Reader under Assigned Roles > Select my-demo-client under the Client Roles select box and move demo-admin and demo-reader under Assigned Roles like so

• As for law we'll just associate him with Reader and bank-reader.

Associating a client scope with a client

Create a Client Scope by:

• Clicking on the Client Scopes link on the left > Click on Create > Enter custom-client-scope for the Name field and Hit Save. It should look like this

• Click on Clients on the left > Select the my-demo-client > Click on the Client Scopes tab at the top > and let's just move it to Assigned Default Client Scopes for convenience.

Inspecting the Access Token

We can easily generate an access token for our setup via Keycloak to see what it looks like. In order to do so:

• Click on Evaluate tab under Client Scopes.

• Select paul as the user

• Click on the blue Evaluate button

• Click on Generated Access Token. While inspecting the token, look for:

  • resource_access to see client level roles associated with paul
  • realm_access to see paul's realm level roles
  • scope to see the Client Scope that we created called custom-client-scope

• If you generate a token for law, you would see less roles when compared to paul.

Obtaining a Scope After Policy Evaluation

Continuing with our setup:

• I've created an account/{id} resource with two Authorization Scopes called account:read and account:modify like so

• Additionally, I've created two role based policies called Only Reader Role Policy and Only Admin Role Policy where the former requires the Reader realm role while the latter requires the Admin realm role. Here's an example for reference.

• Note that you can further enhance that policy at the client level if you wish but to keep things simple, I chose not to do so.

• Furthermore, I've created two scoped based permissions called Read Account Scope Permission and Modify Account Scope Permission.

• The Read Account Scope Permission will grant the account:read Authorization Scope if the user is either an Admin or a Reader. One key thing to notice here is the the Decision Strategy has to be set to Affirmative in order to achieve this behavior.

• Modify Account Permission on the other hand grants the account:modify Authorization Scope to users with the Admin role.

• Now, if you choose the evaluate the user paul (remember he is both Admin and Reader) against the Account Resource, he will be granted both the account:read and account:modify Authorization Scopes. Let's see if this true. Here's our Evaluate screen and notice that I did not associate any roles with paul since this was already done via the Users > Role Mappings tab

• And here are the results of that evaluation as predicted

• 这是 的评估结果law。因为他不是，所以Admin他将被拒绝该account:modify范围，但他将被授予该account:read范围。

• 最后，我们可以通过单击Show Authorization Data显示访问令牌内的权限来进一步确认这一点law

希望这可以帮助您了解每个难题在您的架构中的位置。干杯!