Authorization RBAC-如何实现每个实例的访问控制？（DDD）

在我用javascript（Node.js）编写的DDD应用程序中，我在授权通用子域的实现上遇到了障碍。我检查了RBAC/ACL授权模型，了解如何实现这一点，但它们似乎没有我需要的每个实例的权限

据我所知，RBAC具有基于角色的授权。用户被分配到角色。角色是分层的，并继承权限。角色可以有多个权限。权限允许在资源上执行命令

但是，正如RBAC所定义的，资源是通用的，如“Posts”、“Comment”、“Book”等。它们不是特定于实例的（如Post（id:9283984））。例如，在RBAC中无法定义只有创建帖子的用户才能编辑帖子。似乎不可能将角色“Admin”分配给给定“Post（id:2398493）”上的“User（id:（8290321）”

定义具有执行命令权限的角色变得更加复杂，这些命令可以修改其他人在特定资源上的角色

我的申请要求如下：

发出

CreateLedger

命令的

用户

被自动指定为该

Ledger

的

管理员

。他只能将其他人指定为他所属的

分类账的
经理
或
合作者
或
查看者
。他还可以撤销这些角色。
M允许管理者
管理
分类账
的
账户
，
合作者
可以编辑此
分类账
上的
交易
，
查看者
只能查看数据（只读）.a
管理员
可以将
管理员
角色分配给另一个
用户

我最初的想法是，为了让用户能够管理用户在资源上的角色，需要在

user（id:X）->role（name:Z）->权限->资源（id:Y）->命令

但在RBAC中，只能分配

用户（id:X）->角色（名称：Z）->权限->资源（名称：“分类账”）->命令

然后，为了克服RBAC的这一限制，我考虑使用资源的ID命名资源，如

用户（id:X）->角色（名称：Z）->权限->资源（名称：“分类账：39823847”）->命令

但这似乎是错误的。我没有看到任何RBAC使用资源名称作为实际实例的映射的例子

我用错了锤子？我看错了？是否有其他更适合此任务的访问控制模型？或者这是解决方法？如果有人能为我指出正确的方向，我将不胜感激

感谢您的帮助
授权为通用子域
如果您想将授权建模为通用子域，您确实使用了错误的锤子。请看一看。使用声明，您可以定义一个声明，如
modify post:2937472
。当然，您也可以进一步抽象该信息

通过这种方法，通用授权子域提供了一个“容器”，其他子域在其中存储关联。因此，这种方法需要仔细地集成子域，以便将事物保持在它们所属的位置

作为支持子域的授权
注意：如果您通过仔细的分析和设计得出结论，授权需要是一个通用子域，那么以下内容不是您想要的。我还是将其添加到我的答案中，因为对于不需要单独授权子域的项目，它可能是一个可行的解决方案。因此，下面是：

一种根本不同的方法是将授权设计为支持子域，该子域依赖于核心子域。这样，您可以使用核心模型来定义访问权限，从而使其更加简单和易于理解

例如，博客系统的授权机制可以使用核心领域中的作者、帖子、版主等概念。如果您有复杂的授权需求，这将是一个巨大的成功

与通用子域方法相比，一个明显的权衡是授权不是通用的，而是绑定到特定子域。这对于特定的项目来说可能是可以接受的，也可能是不可以接受的，但对于不需要单独的、可重用的授权机制的较小系统来说，这是一种实用的方法。
您能再详细介绍一下吗作为支持子域的授权。我不确定使用核心模型来定义访问权限是什么意思。如果您认为您的子域名是支持的，那么它似乎是向后的。其他子域应该使用支持的子域来定义访问权限。要验证的内存？如果是，如何只加载与操作相关的声明？无法加载整个ACL。@plalx：在这种情况下，支持的子域不支持核心域，而是支持应用程序本身。我想有些人会争辩说，在这种情况下，授权不是一个单独的子域，而是核心域的一部分。@plalx:N请注意，如果您想要构建一个可重用的授权机制，这不是一个好的解决方案，通常情况下，如果您将授权作为通用子域进行设计，这是一个很好的解决方案。因此，这有点与这里的问题相反。我只想提到它，因为它是一个简单的解决方案，适用于具有“隔离”的应用程序授权机制。我将更新我的答案，使其清晰可见。@theDmi混合解决方案是否可取？通过实现一个通用授权子域，该子域可以被支持的LedgeraAuthorization子域使用？LedgeraAuthorization子域将负责通用授权子域之间的映射域名和账本域名？@Ludo你这么认为吗