API 和数据库访问控制架构

Question

我正在尝试为调查应用程序实施基于访问的控制，但在设计功能架构时遇到了麻烦。看起来 DAC 很适合我正在尝试做的事情，但我不确定。

层次结构

调查系列 -> 多个调查集合（多人必须完成的一项调查）-> 调查。

示例

我有需要分配集合创建者的调查经理。集合创建者将用户分配给属于集合的调查。每个用户可以根据每个系列、集合或调查拥有不同的访问控制。

• 用户 1 只能查看分配给他的调查，但也可以将属于特定收藏的调查分配给其他用户，因为他被另一个收藏创建者授予了访问权限。

• 用户 2 只能查看他创建的集合，并且有权访问和查看每个集合中分配的调查。

• 用户 3 可以创建系列，但不能查看他未指定为收藏创建者的用户的任何收藏。

总结 访问应该是分层的。每条记录（系列、收藏、调查）都有自己的一组用户委派的访问控制 [创建、读取、查看、更新]。我可以在设计模型方面获得一些帮助吗？

Answer 1

不幸的是，在数据库中实现这样一个复杂的分层授权模型……并不简单。鉴于提出的要求（跨多种资源类型的类似角色），以及这些角色的“继承”需求，我概述了一个可能的模型来存储这些角色：

Name	Kind	Description
user_id	Foreign Key	The user that has this role
role	Enum	The role
survey_id	FK or NULL	The survey to which the role applies
collection_id	FK or NULL	The collection to which the role applies
series_id	FK or NULL	The series to which the role applies

表中的每一行都将包含一个用户、他们的角色以及该角色适用的 {survey, collection, series} 之一。这将允许您的应用程序轻松查找您正在检查的给定资源的角色（标准化）。这是一个类似于 Django 中的Generic Foreign Key 的模式。但是，它仍然留下一个关键问题：等级制度。

一个选项是在您的代码中定义一个函数，该函数知道要为您的层次结构的每个级别查找哪些角色，因此如果给它一个survey，它会在所有级别中查找用户的角色 (@987654326 @、collection、series) 并返回具有最大检查权限的角色。否则，您可能需要使用一系列连接来为用户和传入资源选择所有角色，随着表变大，这可能会变得非常慢。这也仅在您的角色在每个级别保持相同时才有效；否则，你会发现自己很快 比较不同的角色枚举。

此类分层问题经常出现在权限检查中，而您的不安是认识到在传统关系数据库中很难将它们映射到这一事实：权限关系的核心是图，而关系数据库的设计并不是为了方便地遍历图。

由于这种复杂性，services（这是我的）为您抽象出这种复杂性，因此您可以定义自己的角色和关系，而不必担心遍历。作为演示，我采用了您上面列出的要求，并在我们的playground 中编写了一个示例，这可能有助于您可视化和测试这些关系。