我们的（ASP.NET Web）应用程序中有一个相当复杂的权限处理系统。用户可以对不同类型的对象拥有特定的权限，一些权限甚至被打包到分配给用户的组/角色中。总而言之，这最终导致了一个相当复杂的混乱，要确定用户是否可以执行/查看某些内容，您必须评估许多不同的权限来源，并且这是根据特定情况按需完成的。
我的问题是（从高层次的角度来看）是否有一些建议/通用设计模式来处理一般的权限概念，以及您在架构中处理它们的经验可能是什么。
【问题讨论】：
标签： c# .net asp.net design-patterns permissions
我见过几个复杂的权限方案。它总是有理由的，但不幸的是，在某个时间点，它们都变得太复杂而无法处理，并被简化为更简单的东西。
我现在的个人结论是：坚持Role base access control (RBAC) 这是唯一一个大家都理解的合理的。它在某种程度上是有限的，但对于大多数情况来说已经足够了。
另外，使用默认拒绝策略，即您仅授予权限。同样，我看到系统具有相反的（默认允许）甚至可配置的默认策略（！），我认为这不合理。
【讨论】：
Users 和 Groups 能够测试 bool UserHasPermission( SOME_PERMISSION ) 以获得与 Group 关联的原子权限是授权的标准方法，但是情况正在改变为 Claims-基于：
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 权限的所有调用都将返回相同的结果。当然，您要确保将用户的记忆权限存储在 Session 中，因此它是每个用户的。如果您在登录时加载权限，则不需要缓存它们，但在具有许多权限的大型系统中，有时最好仅在需要时获取它们。
【讨论】：
我没有从应用程序开发的角度处理过这个问题，但是在处理权限时，使用角色为对象设置权限而不是直接授予用户对对象的权限是一种很好的做法。如果用户需要访问一组特定的对象，您不要直接授予他们访问权限，而是授予他们一个角色，而该角色又具有所需的访问权限。这在某种程度上“重用”了创建角色所投入的工作。
然而，在代码中处理这个问题可能会变得复杂，因为您需要遍历每个用户的角色并确定该角色是否授予用户对该对象的权限。除了尝试将这种代码纳入自己的框架之外，我不知道任何关于处理该问题的具体建议。
【讨论】：