在大型系统中使用基于角色的问题始终存在问题。在此类软件中，我们希望超级用户能够设置其组织用户权限。我们可以创建许多原子角色并创建一个控制台，用于将角色分配给用户。然后我们必须创建许多角色，例如：
AddProduct，RemoveProduct，EditProduct，AcceptPurchase，DenayPurchase，...
通过这种方式，对于中型系统，我们至少应该有50个角色！然后管理员如何为每个用户分配这些角色？
我们乍一看有两个解决方案：
在数据库中创建一个表（例如组）以放在用户和角色之间。然后，管理员应创建一组角色，然后将一个组分配给多个用户。
将角色用作一组权限。例如，创建PermissionInRoles表并为每个角色分配权限，然后将角色分配给用户。
我们很快发现第一种方法是无稽之谈。我们用第二种方法实施了几个项目。但是现在我们想在除了WCF RIA身份验证服务之外的一个sivlerlight项目中使用它。它只支持角色。例如，每个用户实例都有一个 IsInRole 方法，我们实现了 IsInPermission 方法。
对服务使用 RequiresRole 属性时还有另一个问题。我不能也不想为每种服务方法设置硬编码角色名称。
知道我们对基于角色的安全设计感到困惑！我们如何在这些情况下使用它？
答案 0 :(得分：2)
您基于“角色”的授权概念似乎有点瑕疵。然而，这并不罕见，因为有各种各样的定义并不完全是暴力协议，至少在他们更精细的细节中。他们都倾向于共同的唯一事情是授权尝试通过或失败的主要决定因素是用户的属性，而不是计划执行操作的目标属性。除此之外，如果授权系统声称“基于角色”，您可能不应该过多地考虑授权系统实际做了什么。
例如，在您现在使用的基于ASP.NET角色的授权范例中，实际的“角色”对应于固定的（即编译时已知的）操作集。例如，您可能希望看到固定的“产品经理”角色，而不是您在原始帖子中列出的细粒度“AddProduct”，“RemoveProduct”和“EditProduct”权限。如果你想在更细粒度的层次上进行授权，那么这种“纯粹的”基于角色的方法并不适合，而IPrincipal.IsInRole可能根本不是你应该使用的东西。
听起来您想要授权粒度“操作”，操作通过运行时配置分组为“角色”。某些“管理”用户将拥有管理此配置的权限。他们可以根据需要创建，修改和删除“角色”，每个“角色”是一组由您的应用程序识别的“操作”（即：“角色”是“操作”，因为“组”是“用户”）。您的应用程序无需了解角色。相反，它会授权操作。用户将通过以下任何方式被授予操作权限：
当仅使用方法＃4时，授权的管理大大简化，但用于授予权限的实际方法应该对在执行操作之前验证权限的代码完全没有影响。
虽然对.NET Framework的支持尚未内置，但这种情况并不常见。有一些工具可以帮助至少部分内容（例如：AzMan），但我不知道.NET方面提供所有必需部分的任何商业框架，而不需要至少一些自定义编码。 （这个领域有一些小型的开源项目，但你需要在你的应用程序的上下文中评估它们的优缺点。）