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

用户 和 有能力测试 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

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

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

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

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

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