首页 文章

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

提问于
浏览 次
2

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

以下是我对设计上述问题的解决方案的想法 . 问题是，它看起来很简单 . I'm concerned I'm missing some point which will hurt in performance or scalability of the design . 这是设计 .

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

Authorization algorithm 授权函数算法看起来像这样（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;
}

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

security permissions authorization roles

2 回答

  • 2

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

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

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

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

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

    股份公司RBAC at wikipedia

    回复于
  • 0

    除了两个非常奇怪的顶级组叫 canreadwrite 或 canread 之外，我找不到任何真正的问题 . 如果一个愚蠢的管理员创建了这样的组，你的算法就会失败 .

    因此我建议使用像 canreadwrite:supergroup.group.subgroup.rolename 这样的东西 .

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

    例如 supergroup.group.subgroup.rolename:canreadwrite

    回复于

相关问题