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

问题描述

在用javascript（Node.js）编写的DDD应用程序中，我绊倒了授权通用子域的实现。我检查了RBAC / ACL授权模型的实现方式，但它们似乎没有我需要的基于实例的权限。

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

但是，按照RBAC的定义，资源是通用的，例如帖子，评论，书等。它们不是特定于实例的（例如Post（ id：9283984））。例如，无法在RBAC中定义只有创建帖子的用户才能编辑它。在给定的 Post（id：2398493）上，似乎不可能将角色 Admin分配给 User（id：（8290321）

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

我的应用程序的要求是：

发出 CreateLedger 命令的用户被自动分配为<此分类帐的code>管理员。他只能将其他人分配为经理或协作者或浏览者他是管理员 经理可以管理的帐户分类帐。允许合作者在此分类帐上编辑交易 和 Viewers 仅能查看数据（只读）。 Admin 可以分配 Admin 角色来预订他是另一个 User 的 Admin 的书。

我的最初想法是，为了使用户能够管理用户在资源上的角色，需要在$ p之间进行映射
$ b

user（id：X）->角色（名称：Z）->权限->资源（id：Y）->命令

，但是在RBAC中只能分配

user（id：X）->角色（名称：Z）->权限->资源（名称：分类帐）->命令

然后，为了克服RBAC的这一局限性，我想到了使用ID命名资源的想法，例如

user（id：X）->角色（名称：Z）->权限->资源（名称：分类帐：39823847）->命令

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

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

感谢您的帮助

解决方案

作为通用子域的授权

如果要将授权建模为通用子域，则确实使用了错误的锤子。查看基于声明的授权。使用声明，您可以定义一个声明，例如 modify-post：2937472 。当然，或者您当然可以进一步抽象该信息。

通过这种方法，通用授权子域提供了一个容器，其他子域用于存储关联。因此，此方法需要仔细集成子域，以使事物属于它们。

授权为支持子域

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

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

例如，博客系统的授权机制可以使用核心域中的Author，Post，Moderator等概念。如果您具有复杂的授权要求，这将是一个巨大的胜利。

与通用子域方法相比，显而易见的折衷方案是授权将不是通用的，而是与授权相关联。特定子域。对于一个特定的项目而言，这可能是可接受的，也可能是不可接受的，但是对于不需要单独的，可重复使用的授权机制的小型系统，这是一种实用的方法。

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.

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.

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.

The requirements of my applications are :

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) -> role(name:Z) -> permissions -> resource(id:Y) -> commands

but in RBAC it's only possible to assign

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

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

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

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.

Thank you for your help

解决方案

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.

Authorization as supporting subdomain

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屋！