RBAC - 如何实现每个实例的访问控制？(DDD)

Question

在我用javascript(Node.js)编写的DDD应用程序中,我对授权通用子域的实现感到磕磕绊绊.我查看了如何实现这一点的RBAC/ACL授权模型,但它们似乎没有我需要的每实例权限.

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

但是,正如RBAC所定义的那样,资源是通用的,如"帖子","评论","书籍"等.它们不是特定于实例的(如Post(id:9283984)).例如,在RBAC中无法定义只有创建Post的用户才能编辑它.似乎无法将角色"Admin"分配给给定"Post(id:2398493)"上的"User(id:(8290321)"

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

我的申请要求是:

该User谁发布的CreateLedger命令被自动分配为Admin这Ledger.他只能分配给其他人作为Managers或Collaborators或Viewers横木的他Admin的.他也可以撤销这些角色.Managers被允许来管理Accounts的Ledger.Collaborators允许Transactions对此进行编辑Ledger,并且Viewers只能查看数据(只读).一个Admin可以分配Admin角色的书,他Admin的另一个User.

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

user(id:X) -> role(name:Z) -> permissions -> resource(id:Y) -> commands

但在RBAC中,它只能分配

user(id:X) -> role(name:Z) -> permissions -> resource(name:"Ledger") -> commands

然后,为了克服RBAC的这种限制,我想到了用它们的id命名资源

user(id:X) -> role(name:Z) -> permissions -> resource(name:"Ledger:39823847") -> commands

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

我用错了锤子？我看错了吗？是否有其他一些更适合此任务的访问控制模型？或者这是要走的路？如果有人能指出我正确的方向,我将不胜感激.

谢谢您的帮助

Answer 1

授权为通用子域

如果您想将授权建模为通用子域，那么您确实使用了错误的锤子。看看基于声明的授权。使用声明，您可以定义像modify-post:2937472. 或者你当然可以进一步抽象这些信息。

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

授权为支持子域

注意：如果您从仔细的分析和设计中得出结论，授权需要是一个通用的子域，那么以下不是您想要的。无论如何，我将它添加到我的答案中，因为对于不需要单独授权子域的项目来说，它可能是一个可行的解决方案。所以它来了：

一种根本不同的方法是将授权设计为依赖于核心子域的支持子域。有了这个，你可以使用核心模型来定义访问权限，这使得它更简单、更容易理解。

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

与通用子域方法相比，明显的权衡是授权不是通用的，而是绑定到特定的子域。对于特定项目，这可能会也可能不会被接受，但对于不需要单独的、可重用的授权机制的较小系统来说，这是一种实用的方法。