RBAC 嵌套权限
RBAC nested permissions
我正在尝试在网站上实施 RBAC（基于角色的访问控制）。
问题是嵌套对象的权限。
假设我们在网站上有一些项目。每个用户都可以在每个项目中扮演一个角色。例如user1 在 project1 中具有 admin 角色，在 project2 中具有 customer 角色。
例如，Admin 角色包含一些权限，如添加子项目、删除子项目等
我读过的关于 RBAC 的所有文档都定义了一般权限，例如 添加子项目 ，但是当用户拥有此权限时，它可以为 所有项目 [=28= 添加子项目] 不是特定项目（此处为项目 1）。
我如何才能将此类权限限制在特定项目中？
一个糟糕的解决方案是为每个项目定义新的权限。所以权限将是 Add subproject to project1, Delete subproject from project1, 等等，并定义相应的角色，如 project1 Admin .
但我对这种裁员感觉不太好；而项目本身可以是动态的 added/removed。
免责声明：我是 RBAC 初学者
我对 RBAC 的理解是，您拥有结合了实际资源和操作的权限。
在您的情况下：资源将是“project1”，操作将是“create_subproject”，因此权限将被称为“project1.create_subproject”，这表明您对每个资源拥有一个权限，因此提到冗余。
针对你的问题我的建议是引入一个ResourceGroup。不过，这不是 NIST RBAC 标准的一部分。 ResourceGroup 将组合通用类型的资源。
访问检查遍历 ResourceGroup 中的所有对象，如果它找到您的特定资源，它可以评估允许的操作
好的。对于这种情况，我有 解决方案 解决方法。
我的粒度问题是由于超大上下文而提出的：项目本身被认为是具有 independent 权限的资源。但问题是有了这样的权限，其他嵌套的权限就不再独立了。 （即 create_subproject 权限取决于 project_access 权限；这会破坏粒度。
所以解决方法是在项目级别定义权限（假设项目本身是可访问的），并定义 的元组来指定每个项目中哪个用户具有哪些角色。
我认为您已经 运行 了解 RBAC 的已知限制之一：权限只能分配给用户角色（不能分配给资源或操作）。
最近，基于 Google 的 Zanzibar paper 的权限服务得到了不断发展，它描述了一个更通用的权限系统，支持描述资源、用户以及它们之间的关系。
在基于 Zanzibar 的系统中，您将为 Projects 定义资源，为 Projects 定义管理员和客户关系，然后定义元组以显示代表您的数据的实际关系。因此，您可以定义 和 ，这是一种表示和检查资源细粒度权限的直接方法。这是一个概念性的概述，但也有具体的服务，您可以在其中阅读其具体实施细节并进行试用。
作为我新工作的一部分，我在研究授权时偶然发现了您的 post，所以我添加了这个答案，以防其他人遇到类似的挑战。我们整理的一些资源可能会有用：
- What is Zanzibar?：博客 post 提供概述
- Playground：一个用于编写和测试命名空间的交互式工具（有一个预先编写的 RBAC 示例，您也可以测试）
我正在尝试在网站上实施 RBAC（基于角色的访问控制）。
问题是嵌套对象的权限。
假设我们在网站上有一些项目。每个用户都可以在每个项目中扮演一个角色。例如user1 在 project1 中具有 admin 角色，在 project2 中具有 customer 角色。
例如，Admin 角色包含一些权限，如添加子项目、删除子项目等
我读过的关于 RBAC 的所有文档都定义了一般权限，例如 添加子项目 ，但是当用户拥有此权限时，它可以为 所有项目 [=28= 添加子项目] 不是特定项目（此处为项目 1）。
我如何才能将此类权限限制在特定项目中？
一个糟糕的解决方案是为每个项目定义新的权限。所以权限将是 Add subproject to project1, Delete subproject from project1, 等等，并定义相应的角色，如 project1 Admin .
但我对这种裁员感觉不太好；而项目本身可以是动态的 added/removed。
免责声明：我是 RBAC 初学者
我对 RBAC 的理解是，您拥有结合了实际资源和操作的权限。 在您的情况下：资源将是“project1”，操作将是“create_subproject”，因此权限将被称为“project1.create_subproject”，这表明您对每个资源拥有一个权限，因此提到冗余。
针对你的问题我的建议是引入一个ResourceGroup。不过，这不是 NIST RBAC 标准的一部分。 ResourceGroup 将组合通用类型的资源。 访问检查遍历 ResourceGroup 中的所有对象，如果它找到您的特定资源，它可以评估允许的操作
好的。对于这种情况，我有 解决方案 解决方法。
我的粒度问题是由于超大上下文而提出的：项目本身被认为是具有 independent 权限的资源。但问题是有了这样的权限，其他嵌套的权限就不再独立了。 （即 create_subproject 权限取决于 project_access 权限；这会破坏粒度。
所以解决方法是在项目级别定义权限（假设项目本身是可访问的），并定义
我认为您已经 运行 了解 RBAC 的已知限制之一：权限只能分配给用户角色（不能分配给资源或操作）。
最近，基于 Google 的 Zanzibar paper 的权限服务得到了不断发展，它描述了一个更通用的权限系统，支持描述资源、用户以及它们之间的关系。
在基于 Zanzibar 的系统中，您将为 Projects 定义资源，为 Projects 定义管理员和客户关系，然后定义元组以显示代表您的数据的实际关系。因此，您可以定义
作为我新工作的一部分，我在研究授权时偶然发现了您的 post，所以我添加了这个答案，以防其他人遇到类似的挑战。我们整理的一些资源可能会有用：
- What is Zanzibar?：博客 post 提供概述
- Playground：一个用于编写和测试命名空间的交互式工具（有一个预先编写的 RBAC 示例，您也可以测试）