代码之家  ›  专栏  ›  技术社区  ›  Tomas Vana

权限处理的模式/设计建议

  •  8
  • Tomas Vana  · 技术社区  · 15 年前

    在我们的(ASP.NETWeb)应用程序中有一个相当复杂的权限处理系统。用户可以对不同类型的对象拥有特定的权限,有些权限甚至打包到分配给用户的组/角色中。总而言之,这一切最终都会导致一个相当复杂的混乱局面,为了确定用户是否可以做/看到一些事情,你必须评估许多不同的权限来源,这是根据特定的情况以某种方式按需完成的。

    我的问题是(从高层次的角度)是否有一些建议/通用的设计模式来处理一般的权限概念,可能还有您在体系结构中处理它们的经验。

    3 回复  |  直到 15 年前
        1
  •  6
  •   Keith Adler    15 年前

    用户 有能力测试 bool UserHasPermission( SOME_PERMISSION ) 因为与组关联的原子权限是授权的标准方法,但是情况正在向基于声明的方式转变:

    http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

    http://msdn.microsoft.com/en-us/magazine/cc163366.aspx

    http://www.infoq.com/news/2009/10/Guide-Claim-Based-Identity

    然而,它并不适用于所有情况。

    对于旧模型,我发现在权限检查期间使用记忆可以获得性能。这样,我就不会每次会话都访问数据库n次来检查访问控制了。Memoization有效地将具有相同参数的调用结果存储在缓存中,因此特定用户检查XYZ权限的所有调用都将返回相同的结果。当然,您应该确保您在会话中存储了该用户的memoized权限,因此它是针对每个用户的。如果在登录时加载权限,则不需要缓存它们,但在具有许多权限的大型系统中,有时最好只在需要时获取它们。

    http://www.infoq.com/news/2007/01/CSharp-memory

        2
  •  8
  •   ewernli    15 年前

    我见过几个复杂的许可计划。它总是有理由的,但不幸的是,在某个时间点上,它们都变得太复杂而无法处理,并被简化为更简单的东西。

    我个人现在的结论是:坚持 角色库访问控制 ( RBAC )这是所有人都理解的唯一合理的解释。这是有限的,但对大多数情况来说已经足够了。

    默认拒绝 政策,也就是说,你只授予权利。同样,我也看到过相反的系统(默认情况下允许),甚至是可配置的默认策略(!)我觉得这不合理。

        3
  •  2
  •   AaronLS    15 年前

    我没有从应用程序开发的角度来处理这个问题,但是在处理权限时,通常使用角色为对象设置权限是一种好的做法,而不是直接向用户授予对象权限。如果用户需要访问一组特定的对象,您不会直接给他们访问权限,而是给他们一个角色,而角色又拥有所需的访问权限。这在某种程度上“重用”了创建角色所做的工作。

    然而,在代码中处理这个问题可能会变得复杂,因为您需要遍历用户的每个角色,并确定该角色是否授予用户对对象的权限。我不知道有什么具体的建议来处理这个问题,除了试图将这种代码纳入它自己的框架之外。