【问题标题】:Scalable role based authentication可扩展的基于角色的身份验证
【发布时间】:2009-05-25 20:04:39
【问题描述】:

我目前正在为许多用户对其具有不同访问权限的资源设计一个基于角色的身份验证系统。

一个角色可以是单个用户,也可以是一组角色(因此一个角色是一个角色树)。 (见下图)

一个资源可以有多个身份验证属性(如读取、写入、删除),其中每一个都是允许访问操作的角色列表。 (见下图)

问题是,如果我想检查用户是否有权访问某个属性,我必须在最坏的情况下遍历 n 棵树(其中 n 是分配给某个属性的角色数)。

例如,要检查“Max”是否可以读取属性,我可能必须检查 Marketing、Management 和 Administration 树是否包含“Max”。


您是否知道任何算法或替代方法可以消除相当昂贵的树搜索,同时保持角色系统或同样强大的东西。

完美的情况是对 n 个角色进行 O(log(n)) 之类的查找。

谢谢, 芬恩

【问题讨论】:

  • 据我所知,您对功能需求/规范的描述包括树。所以要么你需要改变规范,要么找到一种方法来防止树搜索“相当昂贵”。

标签: authentication scalable role-based


【解决方案1】:

您是否对此进行了测量并确定此遍历是性能瓶颈?

我从未见过具有如此多角色/级别的系统,以至于遍历这种结构的成本会成为一个问题。如果树真的那么大,我会更担心管理员很难理解谁有权做什么。

关于可扩展性,我通常会使用 ASP.NET 缓存来缓存在资源和角色之间映射的完整树,并使用合适的缓存超时。并单独缓存从用户到角色的映射(例如,在 Session 中或在 ASP.NET 缓存中使用用户特定的键)。

与每次访问数据库相比,从缓存中访问信息通常会快得令人眼花缭乱。

【讨论】:

    【解决方案2】:

    如果您将角色放在 SQL 数据库中,查找将按照您的描述进行。如果您有兴趣,我可以帮助您了解数据库结构。

    【讨论】:

    • SQL 数据库并不能真正消除树遍历的复杂性,相反在我看来,SQL 中的树是相当痛苦的。角色的深度并没有真正受到限制。
    • “嵌套集”模型是一种在 SQL 中快速选择子树的方法。
    • 这是一个很好的变化,它将在像 Bigtable 这样的数据库系统上运行 - 没有连接,只有普通表。即使嵌套集很快,我想它也不会很好地扩展,因为它远非标准表查找。
    • 不,嵌套集合方法使用标准 SQL。它使用的模式使插入速度变慢但选择速度非常快:它甚至不需要连接,更不用说递归连接了。
    【解决方案3】:

    你需要反转你的指针。

    “Harry”是“Site2 Admins”的成员,对“Site2”拥有“管理员”访问权限,因此他可以“删除”、“写入”和“读取该内容”。

    为什么“管理”应该是“哈利”和“乔”之间的共同点,我不清楚。 Harry 是一个站点的管理员,但只是另一个站点的用户,Joe 反之亦然。

    【讨论】:

    • 没有规则说管理员可以做任何事情,它可能只是被命名为 SomeUsers 角色,如果有人可以读、写或完全取决于是否将包含该用户的角色添加到财产。
    猜你喜欢
    • 2016-01-03
    • 1970-01-01
    • 1970-01-01
    • 2021-11-22
    • 2019-10-10
    • 2017-08-03
    • 1970-01-01
    • 2016-03-07
    • 2014-04-04
    相关资源
    最近更新 更多