Fatal编程技术网
  • keycloak/
  • Keycloak 当角色数达到数百个时，KeyClope重定向失败

Keycloak 当角色数达到数百个时，KeyClope重定向失败

keycloak

Keycloak 当角色数达到数百个时，KeyClope重定向失败,keycloak,Keycloak,我有两个用户，一个少于30个角色，一个有400个角色。当我使用30个角色的用户登录时，我可以毫无问题地访问重定向URL。但是当我使用400角色用户登录时，对重定向URL的请求没有完成。如果我减少400个角色用户中的角色数量，那么它将起作用。那么，有没有一种方法可以禁用java访问令牌中的传递角色，或者在导致失败的地方增加一些限制？要解决这个问题，您应该从为每个应用程序（例如oidc客户端）定义开始。该工具的主要思想是，即使您的用户是具有所有现有角色的超级复制管理员，但任何特定应用程序实际上并不需

我有两个用户，一个少于30个角色，一个有400个角色。当我使用30个角色的用户登录时，我可以毫无问题地访问重定向URL。但是当我使用400角色用户登录时，对重定向URL的请求没有完成。如果我减少400个角色用户中的角色数量，那么它将起作用。那么，有没有一种方法可以禁用java访问令牌中的传递角色，或者在导致失败的地方增加一些限制？

要解决这个问题，您应该从为每个应用程序（例如oidc客户端）定义开始。该工具的主要思想是，即使您的用户是具有所有现有角色的超级复制管理员，但任何特定应用程序实际上并不需要他的所有角色。例如，客户端foo，它定义了以下角色：

  • foo_用户
  • foo_查看器
要执行其安全逻辑，只需知道当前登录的用户是否具有foo_user或foo_viewer，但它不关心该用户是否具有来自应用程序bar的bar_user或bar_admin角色。因此，我们的目标是使keydape返回任何客户端访问令牌，该令牌只包含该客户端的一组有价值的角色。角色范围映射是您的朋友。您可以为客户端foo范围设置如下：

  • foo.foo_用户
  • foo.foo_查看器
  • 酒吧管理员
现在，即使登录用户具有“bar.bar\u admin”角色，也不会访问\u令牌，因为客户端foo不考虑此角色。应用一些范围设置后，您可以在“客户端->$CLIENT\u OIDC\u ID->客户端范围选项卡->评估子选项卡”中测试它们

对于400个角色的情况，我很有信心，您的应用程序都不需要全部400个角色，因此应用程序的精确范围配置可以大大减少访问令牌的大小

但如果我错了，并且您确实有一个依赖大量角色的应用程序，那么您应该查看运行时设置

例如，如果在反向代理（如nginx）后面运行keydape，则大型令牌可能不适合默认的HTTP参数缓冲区大小（afaik约2-4kb），因此必须通过适当的nginx配置选项增加它。另一个例子是tomcat，它有大约16kb作为默认HTTP头缓冲区，因此如果您发送的请求在授权头中包含非常大的访问令牌，tomcat可能无法正确处理此请求。

我建议将重点放在角色缩减/优化上，而不是强制传输（提高限制）超过令牌（或任何其他地方）内的最大角色数

一些有趣的问题（除其他问题外）首先是：

  • 我将为哪些受保护的资源提供服务
  • 我想保护什么？相关风险是什么？（建立一个威胁模型）
  • 每个应用程序如何为资源提供服务？它们是如何分布在我的应用程序中的
  • 它们是什么样的资源？我如何将它们分组？哪些集合是可识别的？或者他们之间有什么关系？针对所有资源集可以采取哪些行动
  • 每个应用程序的用户是谁？他们将如何与我的资源互动？哪些流是敏感的
  • 我可以为所有资源定义哪些角色
  • 哪个角色可以应用于每个应用程序、资源类型或集合
  • 我可以创建什么类型的用户组
  • 我是否需要每组角色或用户/组的附加属性或声明
我坚信，如果你回答了所有这些问题，你最终将扮演一堆角色，而不是数百个。通过设计考虑安全性并遵循最小特权原则

关注你的用例 现在据我所知，您的阻塞点是假设每个资源都是唯一的、敏感的，并且需要它自己的权限，因此需要一个角色定义。虽然在某些情况下这可能是正确的，但在大多数其他情况下，这并不意味着您必须使用令牌角色/作用域/声明来保护资源级别的深层资产。我将试着用一个例子来说明这个句子

您的用例的RBAC和授权示例 让我们假设：

  • 你有数以百万计的敏感资源需要服务
  • 应用程序的每个注册用户都可以访问这些资源的（不同）集合
  • 您的资源分为3类（电子书、视频、音乐）
  • 每个资源都可以下载、上载、删除
  • 您的应用程序将遇到未注册用户、注册用户、贡献者和管理员
  • 注册用户将始终拥有对资源的读取权限（没有一个操作允许修改）
  • 贡献者是特定的注册用户，可以执行特殊操作，包括修改（“上载”、“编辑”）
  • 贡献者和管理员可以访问应用程序的各个管理部分
  • 您的应用程序将在将来通过提供其他类别的资源而不断发展，新的操作将在以后提供给用户（例如“标记”、“编辑”或“共享链接”）
然后，先做第一件事：

SCOPE / AUDIENCE
   MY_APP

ROLES
   USER
   CONTRIBUTOR
   ADMINISTRATOR

CLAIMS / ATTRIBUTES
   CATEGORIES
   ACTIONS


--> POSSIBLE USER GROUPS       
      USERS
         Roles: USER
         Claims: CATEGORIES(variable), ACTIONS('download')
      CONTRIBUTORS
         Roles: USER, CONTRIBUTOR
         Claims: CATERGORIES(variable), ACTIONS('download', 'upload', 'edit')
      ADMINISTRATORS
         Roles: USER, CONTRIBUTOR, ADMINISTRATOR
         Claims: CATEGORIES(*), ACTIONS(*)
  • 通过在分类路径（如：
    ../myapp/res/ebooks
    ，
    ../myapp/res/videos
    ，
    ../myapp/res/music
    ）后提供服务，相应地组织您的资源
  • 通过UUID识别您的资源，使资源看起来像：
    ../myapp/res/ebooks/duz7327abdhgsd95a
现在想象一下，您的业务风险或您希望避免的最大风险是：