Question

我正在设计授权服务。它根据分配给用户的角色和内容设置的权限执行访问控制。用户可以属于多个组。这些组也可以属于其他组。群体下群体的群体深度并不大。内容可以在用户级别或组级别共享。内容也可以与多个组共享。内容允许的操作为to-read或to-read-write。

以下是我对设计上述问题的解决方案的想法。问题是，它看起来很简单。 我担心我会遗漏一些会影响设计性能或可扩展性的点。这是设计。

数据存储： 每个用户可以拥有多个角色。角色是一个字符串，看起来像名称空间。 supergroup.group.subgroup.rolename。每个内容都可以拥有多个权限。权限是一个字符串，看起来像命名空间，操作类型为前缀。 canreadwrite.supergroup.group.subgroup.rolename

授权算法 授权函数算法看起来像这样（PS这只是为了显示基础知识，在实践中角色和权限数组将被排序，并且将使用某种形式的二进制搜索来进行此匹配）

public bool CanReadWrite(string[] roles, string[] permissions)
{
    foreach (var role in roles)
    {
        foreach (var permission in permissions.Where(s => s.StartsWith(canreadwrite)))
        {
            string barePermission = permission.Remove(0, canreadwrite.Length);

            if (role.StartsWith(barePermission))
            {
                return true;
            }
        }
    }

    return false;
}

你觉得这个设计有什么问题吗？任何性能问题？可扩展性问题？

Answer 1

您的应用程序不是很清楚，尤其是这些用户组层次结构与角色/权限设计的关系。

首先，我要避免自己实施二进制搜索，只是使用dictionaries。

其次我假设您可能拥有大量内容项和大量用户。看起来每个内容项可能会有大量的“虚拟权限字符串”，但是为了性能和可维护性，您应该保留每个内容的角色/权限条目数量。

也许您可以从这些用户组层次结构中拆分角色定义/维护，即内容项只“知道”某些角色，而不是“知道”这些组。

第三，如果你真的需要用户组的层次结构，我会考虑允许在更高级别的组中附加角色/权限，以避免需要在最低级别定义/维护角色/权限（假设许多低级别）级别组可能）。

S.A。 RBAC at wikipedia

Answer 2

除了名为canreadwrite或canread的两个非常奇怪的顶级群组之外，我找不到该方法的任何实际问题。如果一个愚蠢的管理员创建了这样的组，你的算法就会失败。

因此我建议使用类似canreadwrite:supergroup.group.subgroup.rolename的内容。

作为替代方案，您可以设置格式关联，例如rolehierarcy：权限，使用StartsWith(roleName)测试角色以及使用EndsWith(":" + permissionName)的权限。

例如supergroup.group.subgroup.rolename:canreadwrite

设计评审 - 基于角色的访问系统的性能和可伸缩性问题

2 个答案: