在我用javascript（Node.js）编写的DDD应用程序中，我对授权通用子域的实现感到磕磕绊绊。我查看了如何实现这一点的RBAC / ACL授权模型，但他们似乎没有我需要的每个实例权限。
据我所知，RBAC具有基于角色的授权。用户被分配到角色。角色是分层的并且继承权限。角色可以拥有多个权限。权限允许在资源上执行命令。
但是，正如RBAC所定义的那样，资源是通用的，例如＆＃34;帖子＆＃34;，＆＃34;评论＆＃34;，＆＃34;书＆＃34;等等。它们不是特定于实例的（喜欢Post（id：9283984））。例如，在RBAC中无法定义只有创建帖子的用户才能编辑它。似乎无法分配角色＆＃34; Admin＆＃34;到＃34;用户（id：（8290321）＆＃34;在给定的＆＃34;帖子（id：2398493）＆＃34;
定义具有执行修改其他人在特定资源上的角色的命令的权限的角色变得更加复杂。
我的申请要求是：
发出User命令的CreateLedger会自动分配为此Admin的{{1}}。他只能将其他人分配为他Ledger的Ledgers的Managers或Collaborators或Viewers。他也可以撤销这些角色。 Admin被允许管理Managers的{{1}}。允许Accounts在此Ledger上修改Collaborators，Transactions只能查看数据（只读）。 Ledger可以将Viewers角色分配给另一个Admin的{{1}}个书籍。
我最初的想法是，为了让用户能够管理用户在资源上的角色，需要在
之间进行映射。 Admin
但在RBAC中，它只能分配
Admin
然后，为了克服RBAC的这种限制，我想到了用它们的id命名资源，比如
User
但这似乎不对。我还没有看到RBAC使用资源名称作为实际实例的映射的任何示例。
我正在使用错误的锤子？我看错了吗？是否有其他一些更适合此任务的访问控制模型？或者这是要走的路？如果有人能指出我正确的方向，我将不胜感激。感谢您的帮助
答案 0 :(得分：3)
如果您想将授权建模为通用子域，那么您确实使用了错误的锤子。看看claims-based authorization。使用声明，您可以定义modify-post:2937472之类的声明。或者您当然可以进一步抽象出这些信息。
通过这种方法，通用授权子域提供了一个＆＃34;容器＆＃34;其他子域存储关联的位置。因此，这种方法需要仔细整合子域，以保持它们所属的位置。
注意：如果您通过仔细分析得出结论＆amp;设计授权需要是一个通用子域，然后以下不你想要的。无论如何，我将它添加到我的答案中，因为对于不需要单独的授权子域的项目来说，它可以是一个可行的解决方案。所以它来了：
一种根本不同的方法是将授权设计为支持子域，该子域依赖于核心子域。有了这个，您可以使用核心模型来定义访问权限，这使得它更容易理解。
例如，博客系统的授权机制可以使用核心域中的Author，Post，Moderator等概念。如果您有复杂的授权要求，这将是一个巨大的胜利。
与通用子域方法相比，明显的权衡是授权不是通用的，而是绑定到特定的子域。对于特定项目而言，这可能是可接受的，也可能是不可接受的，但对于不需要单独的，可重复使用的授权机制的小型系统来说，这是一种实用的方法。