何时在 Keycloak 中使用领域角色？答案

【问题标题】：When to use Realm roles in Keycloak?何时在 Keycloak 中使用领域角色？
【发布时间】：2020-08-27 20:04:56
【问题描述】：

我正在试验微服务和前端之间的角色映射（Keycloak 术语中的 keycloak-clients）。

假设我有两个 keycloak 客户端：

路由管理-api
路由管理-webapp

在 routemanagement-api 中，我定义了一些角色，假设其中之一：regular-user。此角色不是复合角色。

在 routemanagement-webapp 中，我将定义另一个角色，也称为常规用户。这个是一个复合角色。我会将其与 routemanagement-api 中的“常规角色”用户相关联。

然后，我创建一个用户。假设这个用户通过 routemanagement-webapp 注册。因此，我的注册逻辑会将“routemanagement-webapp:regular-user”角色分配给这个新创建的用户。

由于“routemanagement-webapp:regular-user”与“routemanagement-api:regular-user”角色相关联，对 routemanagement-api REST 端点的调用将成功。

你看，我不需要领域（上层）角色来实现这一点。我可以直接从一个客户跳到另一个客户。我会说我的方法是自上而下的方法；顶部是前端应用程序，底部是 API。我正在考虑使用单独的 webapp 来配置用户。用户将被授予她被允许使用的“webapps”角色。使用相关 API 的正确权限是在 keycloak UI 中通过这些复合角色技巧处理的。

您如何看待这种方法？这是一种正确的思维方式吗？我们需要领域角色做什么？

【问题讨论】：

我不明白你需要什么程序，当你基本上指的是同一个角色时？也许我不明白问题的重点，但这基本上就是领域角色的用途，用于在多个客户端中使用它们。如果您对某个客户有特定需求，请使用客户范围角色。
这也是我的想法（领域：更一般，客户：更具体）。我们可以这样想吗（在组织环境中）？： - 领域角色应该映射到组织中的层次结构（CEO、首席技术官、经理等）。 - 客户端角色，应映射到为其创建 API 的“工作域”/“任务组”中的功能角色。
是的，这似乎是一个正确的用法。
顺便说一句，@ExtremeBiker，我有理由支持该角色映射程序。当我们启动一个新的 web 应用程序时，团队不想被任何其他微服务中的角色所困。我们只关心他们的 webapp（前端）规范中的角色。对后端 API（其他微服务）的访问通过该过程（在 keycloak UI 中）以及资源授权策略和权限进行排序。
好的，我想你使用那个或领域角色本身是相似的，因为其他客户端角色在某种程度上是“公共的”，只要它们在同一个领域中。

标签： keycloak roles

【解决方案1】：

我建议您可能不需要复合角色。在我看来，api 拥有资源，因此您应该将客户端角色设计为 api，将 api 客户端设计为资源所有者。该角色可以命名为“动词资源”，例如“创建-x，读取-x，更新-x，删除-x”。

即使您使用 routemanagement-webapp 客户端进行身份验证，您仍然可以为 routemanagement-api 推断用户的资源角色。

示例 JWT

{
  "jti": "0ba58a94-d98e-4f29-abfa-ade95d96a62b",
  "exp": 1589264282,
  "nbf": 0,
  "iat": 1589263982,
  "iss": "http://localhost:8080/auth/realms/master",
  "aud": "routemanagement-webapp",
  "sub": "50b6d1f7-88ea-451c-92bb-fc7f5fcc6683",
  "typ": "Bearer",
  "azp": "routemanagement-webapp",
  "auth_time": 0,
  "session_state": "7a270756-917b-4afc-a06d-054b05e6d41a",
  "acr": "1",
  "allowed-origins": [],
  "realm_access": {
    "roles": [
      "offline_access",
      "uma_authorization"
    ]
  },
  "resource_access": {
    "routemanagement-api": {
      "roles": [
        "manage-regular-stuff"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Test User",
  "preferred_username": "test.user",
  "enabled": true,
  "email": "test.user@test.com"
}

如果您想获得更精细的信息，您可以使用授权和资源注册，而不是基于角色的“动词资源”命名策略。

【讨论】：