Keycloak - 基于资源的角色和范围基础认证

Keycloak - Resource based Role & scope base auth

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

我有用户

用户可以访问多个帐户 在多个帐户中，可以使用 Admin 或 agent (reader)

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

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

任何参考文档任何示例都非常有用

也基于：

根据 Andy 的回答，我已经创建了一个资源 Account 和角色 admin & agent。

创建了与示例中相同的策略。

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

@changa, I've rewritten my answer based on our discussion. Hope this helps!

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

在 Keycloak 中，您会遇到客户端和授权范围。有关这些术语的正式定义，请查看服务器管理指南中的 Core Concepts and Terms，但只需输入：

客户端范围 是在通过 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 的内容。

    • 旁注：考虑到这个答案的长度，我决定跳过这个话题，但请查看这个 awesome video at around the 7 minute mark along with the associated GitHub Project 了解更多信息。 README 很不错。

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

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

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

    • 当涉及到 Keycloak 中授权过程的内部工作时，我几乎没有触及表面。有关详细信息，请查看此 practical guide。你可以用 UMA 做一些很酷的事情。

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

  • 一个叫做demo的领域
  • 一个客户叫 my-demo-client
  • 一个名为 client_roles
    • 的客户端作用域
  • 2 位用户 - paul 和 law
  • 两个领域级别的角色 - Admin 和 Reader
  • 两个客户级别角色 - demo-admin 和 demo-reader

Please note that I will using Keycloak 12.0.4 and I will skip almost all the basic setup instructions. I will only share the relevant bits. If you're not sure how to set this all up, please check out the Getting Started Guide or this . The answer contains steps for version 8 but the differences are very minor as far as I could tell.

关联用户和角色

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

  • 单击 Users > View all users > 单击 paul 的 ID 值 > 单击 Role Mappings > 在 Realm Roles 下移动Admin and Reader under Assigned Roles > Select my-demo-client under Client Roles select box and move demo-admin and demo-reader 在 Assigned Roles 下像这样

  • 至于law我们就把他与Reader和bank-reader联系起来。

将客户端范围与客户端相关联

通过以下方式创建客户端范围：

  • 单击左侧的 Client Scopes link > 单击 Create > 在 Name 字段中输入 custom-client-scope 并点击保存。它应该是这样的

  • 单击左侧的 Clients > Select my-demo-client > 单击顶部的 Client Scopes 选项卡 > 让我们将其移动到 Assigned Default Client Scopes 为了方便起见。

检查访问令牌

我们可以通过 Keycloak 轻松地为我们的设置生成一个访问令牌，看看它是什么样子。为此：

  • 单击 Client Scopes 下的 Evaluate 选项卡。

  • Select paul 作为用户

  • 单击蓝色 Evaluate 按钮

  • 点击 Generated Access Token。在检查令牌时，查找：

    • resource_access 查看与 paul
      • 关联的客户端级别角色
    • realm_access 查看 paul 的领域级别角色
    • scope 查看我们创建的 Client Scope 调用 custom-client-scope

  • 如果您为 law 生成令牌，与 paul 相比，您会看到更少的角色。

政策评估后获取范围

继续我们的设置：

  • 我创建了一个 account/{id} 资源，其中有两个 Authorization Scopes 分别称为 account:read 和 account:modify，就像这样

  • 此外，我创建了两个基于角色的策略，称为 Only Reader Role Policy 和 Only Admin Role Policy，其中前者需要 Reader 领域角色，而后者需要 Admin 领域角色。这里有一个例子供参考。

  • 请注意，如果您愿意，可以在客户端级别进一步增强该策略，但为简单起见，我选择不这样做。

  • 此外，我创建了两个基于范围的权限，称为 Read Account Scope Permission 和 Modify Account Scope Permission。

  • 如果用户是 Admin 或 ，Read Account Scope Permission 将授予 account:read Authorization Scope ]一个Reader。这里需要注意的一件关键事情是必须将决策策略设置为 Affirmative 才能实现此行为。

    另一方面，
  • Modify Account Permission 将 account:modify Authorization Scope 授予具有 Admin 角色的用户。

  • 现在，如果您选择评估用户 paul（记住他既是 Admin 又是 Reader）反对 Account Resource，他将同时获得account:read 和 account:modify Authorization Scopes。让我们看看这是不是真的。这是我们的 Evaluate 屏幕，请注意我没有将任何角色与 paul 相关联，因为这已经通过 Users > Role Mappings 选项卡
    • 完成

  • 下面是预测的评估结果

  • 这是law的评价结果​​。由于他不是 Admin，他将被拒绝 account:modify 范围，但他将被授予 account:read 范围。

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

希望这可以帮助您了解每个拼图在您的体系结构中的位置。干杯！