我们的(ASP.NET Web)应用程序中有一个相当复杂的权限处理系统。用户可以对不同类型的对象拥有特定权限,某些权限甚至可以打包到分配给用户的组/角色中。总而言之,这最终会出现一个非常复杂的混乱局面,用于确定用户是否可以执行/查看您必须评估许多不同权限来源的内容,这可以按需按照特定情况以某种方式完成。
我的问题是(从高层次的角度来看)是否有一些建议/通用设计模式来处理一般的权限概念,也可能是您在架构中处理它们的经验。
答案 0 :(得分:6)
我见过几个复杂的许可方案。它始终是有道理的,但不幸的是,在某个时间点,它们都变得太复杂而无法处理并被简化为更简单的东西。
我个人的结论是:坚持角色基础访问控制(RBAC)这是每个人都理解的唯一合理的。它在某种程度上是有限的,但对大多数情况来说足够了。
此外,使用默认拒绝政策,即您仅授予权限。再次,我已经看到相反的系统(默认允许)或甚至可配置的默认策略(!),我认为这不合理。
答案 1 :(得分:5)
用户和群组能够测试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
然而,它并不适合所有情况。对于旧模型,我发现在权限检查期间使用memoization可以获得性能。这样我每次会话都不会去数据库n次来检查访问控制。 Memoization有效地在缓存中存储具有相同参数的调用结果,因此特定用户检查XYZ权限的所有调用都将返回相同的结果。当然,您需要确保在Session中存储了用户的memoized权限,这样每个用户就可以了。如果您在登录时加载权限,则不需要缓存它们,但在具有许多权限的大型系统中,有时最好只在需要时才能获取它们。
答案 2 :(得分:2)
我没有从应用程序开发的角度处理这个问题,但通常在处理权限时,最好使用角色为对象设置权限,而不是直接向用户授予权限。如果用户需要访问特定对象集,则不直接授予他们访问权限,而是为他们提供角色,而角色又具有所需的访问权限。这在某种程度上“重用”了创建角色的工作。
然而,在代码中处理此问题可能会变得复杂,因为您需要遍历每个用户的角色并确定角色是否为用户提供了对象的权限。除了试图将这种代码纳入自己的框架之外,我不知道有什么特别的建议可以处理。