RBAC - 如何实现每个实例的访问控制?(DDD) [英] RBAC - How to implement per instance access control? (DDD)

问题描述

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

In my DDD application written in javascript (Node.js), I am stumbling on the implementation of the authorization generic subdomain. I checked on the RBAC / ACL authorization models on how to implement this, but they don't seem to have per-instance permissions, which I need.

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

From what I understand, RBAC has role-based authorizations. Users are assigned to roles. Roles are hierarchical and inherit permissions. Roles can have multiple permissions. Permissions allow commands to be executed on resources.

但是，根据 RBAC 的定义，资源是通用的，如帖子"、评论"、书籍"等.它们不是特定于实例的(如 Post(id:9283984)).例如，无法在 RBAC 中定义只有创建 Post 的用户才能对其进行编辑.似乎不可能在给定的帖子(id:2398493)"上将角色管理员"分配给用户(id:(8290321)"

But, as defined by RBAC, resources are generic like "Posts", "Comment", "Book", etc. They are not instance-specific (like Post(id:9283984)). For example, it's not possible to define in RBAC that only a user that created a Post can edit it. It seems to be impossible to assign the role "Admin" to a "User(id:(8290321)" on a given "Post(id:2398493)"

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

It becomes even more complicated to define roles that have permissions to execute commands that modify other people's roles on a specific a resource.

我的申请要求是:

发出CreateLedger 命令的User 被自动分配为此Ledger 的Admin.他只能将其他人指定为他是 Admin 的账本的 Managers 或 Collaborators 或 Viewers.他也可以撤销这些角色.Managers 可以管理Ledger 的Accounts.Collaborators 可以在这个 Ledger 上编辑 Transactions，并且 Viewers 只能查看数据(只读).Admin 可以将 Admin 角色分配给他是 Admin 的书籍给另一个 User.

The User who issued the CreateLedger command is automatically assigned as the Admin of this Ledger. He can only assign other people as Managers or Collaborators or Viewers of the Ledgers he is Admin of. He can also revoke those roles. Managers are allowed to manage the Accounts of the Ledger. Collaborators are allowed to edit Transactions on this Ledger, and Viewers only able to view the data (read only). An Admin can assign the Admin role to books he is Admin of to another User.

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

My initial idea was that in order for a user to be able to manage user's roles on a resource, there would need to be a mapping between

user(id:X) ->角色(名称:Z)->权限 ->资源(id:Y)->命令

但在 RBAC 中只能赋值

but in RBAC it's only possible to assign

user(id:X) ->角色(名称:Z)->权限 ->资源(名称:分类帐")->命令

然后，为了克服 RBAC 的这个限制，我想用它们的 id 来命名资源，如

Then, to overcome this limitation of RBAC, I thought about naming resources with their ids like

user(id:X) ->角色(名称:Z)->权限 ->资源(名称:分类帐:39823847")->命令

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

But this seems wrong. I haven't seen any example of RBAC using resource names as mapping for actual instances.

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

I am using the wrong hammer? I am seeing this wrong? Is there some other access control model more suited to this task? Or is this the way to go? I would appreciate if someone would point me in the right direction.

感谢您的帮助

推荐答案

授权为通用子域

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

Authorization as generic subdomain

If you want to model authorization as generic subdomain, you indeed are using the wrong hammer. Take a look at claims-based authorization. Using claims, you could define a claim like modify-post:2937472. Or of course you could further abstract that information.

通过这种方法，通用授权子域提供了一个容器"，其他子域在其中存储关联.因此，这种方法需要仔细整合子域，以保持它们所属的位置.

With this approach, the generic authorization subdomain provides a "container" where the other subdomains store associations. Thus, this approach requires careful integration of the subdomains in order to keep things where they belong.

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

Note: If you concluded from careful analysis & design that authorization needs to be a generic subdomain, then the following is not what you want. I add it to my answer anyway, because it can be a viable solution for projects that don't require a separate authorization subdomain. So here it comes:

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

A fundamentally different approach is to design authorization as supporting subdomain that has a dependency on the core subdomain. With this, you can use the core model to define access rights, which makes it a lot simpler and easier to understand.

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

As an example, the authorization mechanism for a blog system can use the Author, Post, Moderator, etc concepts from the core domain. This is a big win if you have complex authorization requirements.

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

The obvious trade-off compared to the generic subdomain approach is that authorization will not be generic, but tied to a specific subdomain. This may or may not be acceptable for a specific project, but it is a pragmatic approach for smaller systems that don't need a separate, reusable authorization mechanism.

这篇关于RBAC - 如何实现每个实例的访问控制?(DDD)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！