.NET应用程序的权限/正确的模型/模式

我需要实现灵活和简单（如果存在这种情况），并在可能的情况下同时利用内置方法

到目前为止，我已经实现了MembershipProvider和RoleProviders。这很酷，但是我下一步要去哪里？

我觉得我需要添加术语“特权”，而不是对应用程序内部的代码进行硬编码。用户将配置角色以将特权添加到角色，并将角色分配给用户。

听起来不错吗？除了将其添加到角色之外，我是否应该考虑在用户级别添加特权？我可能会，但我预想安装（混乱）和支持以下方面的问题。

如果我不这样做，则某些特定用户将需要较少的权限-管理员将不得不创建另一个角色，依此类推。

这样的系统有什么灵丹妙药吗？以及为什么Microsoft不只是会员资格和角色提供者而走得更远？

另一个想法：将角色保留为“特权”持有者并对其进行硬编码。然后，我可以使用所有可用的标记/属性等对应用程序内的那些角色进行编码-所有Microsoft。

添加新实体“组”并创建关系

• 用户数
• 用户组
• 团体
• 角色组
• 的角色

这样，我可以将角色收集到组中并将这些组分配给用户。听起来不错，并且与其他软件模式匹配。但是然后我真的不能在RoleProvider中实现诸如以下的功能：

• AddUsersToRoles
• RemoveUsersFromRoles

而且有些事情真的不再有意义了，因为它们将被硬编码

• DeleteRole
• 创建角色

如果基于角色的授权对您而言还不够细致，请考虑使用基于声明的授权。

声明描述了资源和活动-有点像ACL中的条目，但更灵活，因为“资源”不必一定是物理对象，它可以是您想要的任何东西，并且可以包含任何信息你要。

在此模型中，索赔等同于您所谓的“特权”，并且将索赔分组为索赔集，这大致相当于您所谓的“角色”。所有这些API以及更多API都已经在System.IdentityModel名称空间中。

当然，您提到过MembershipProvider，RoleProvider如果您试图将所有内容都塞入ASP.NET成员资格模型（正如这些名称所暗示的那样），那么就算了。如果要使用这些提供程序API，则必须按其方式进行操作，并且它们的方式不会比角色的概念更具体。

相反，在ASP.NET中，“特权”的概念实际上是在操作或操作级别编码的，您在其中声明允许哪些角色执行该操作。在ASP.NET MVC中，这实际上要容易得多，在ASP.NET MVC中，您只需[AuthorizeAttribute]对控制器或控制器动作打一下即可；在“老式” ASP.NET中，您正在处理事件，因此授权可能是临时的，也可能是页面级别的（或同时是两者）。