我想使用内置的ASP.NET成员机制，但这对我来说似乎还不够。它只允许人们执行一系列任务(角色)。我可以允许一个人，但似乎很难否认一个人；允许会计部门的人员查看敏感信息，但如何拒绝该部门的特定人员。？我必须创建AccountDept和AccountDeptNoSentiveData角色等等…如果有很多活动，那就会一团糟。
在我的情况下，具有允许/拒绝机制的旧经典组和用户要好得多。然而，我不想重新发明以前已经发明的东西，如果有的话，这就是我在这里所要求的：
对于基于表单的身份验证，是否有ASP.NET成员身份机制的扩展变体或另一种好的"框架/样板/就绪模式"，允许我授权/拒绝人们在我的应用程序中执行任务？
您可能正在寻找基于声明的授权。用户没有特定的角色和该角色附带的所有授权，而是携带一个声明，这可以实现更精细的允许/拒绝检查。
来自MSDN：
这实现了比纯RBAC更大的粒度(基于角色的访问检查)，其中通常有许多权限在单个角色下收集。也许，更重要的是，基于索赔授权使业务逻辑和授权策略，因为可以要求特定的对代码中资源的操作和后端策略可以用于配置呈现实体必须拥有的声明满足需求。
这里有一个来自.NET Rocks的非常好的播客来熟悉这个主题：Dominick Baier带领我们通过基于索赔的安全！。
在ASP.NET 4.5中，当使用带有System.Security.Claims命名空间的表单身份验证时，核心框架能够进行基于声明的授权。可以将Page.User对象强制转换为ClaimsPrincipal。你可以检查委托人的索赔，并根据索赔做出决定，即是否允许执行某项行动。有关如何在ASP.NET中完成此操作的描述，请参见ClaimsAuthorizationManager。
您的代码可能会变得更加复杂，但与尝试在多个角色定义中匹配所有可能的授权组合相比，这应该不那么令人头疼。
在我看来，缺少一块是下一级的权限或操作。授权管理器有这些，但没有本地API。使用基于AzMan的API是邪恶的。
本质上，当你想做某事时，你要检查用户是否拥有给定的权利。这些权限收集在您为其分配用户的角色中。这使您可以细粒度地控制角色可以做什么，而不需要数百万或角色。
遗憾的是，我不知道有什么东西能给你一个"权利API"。我为我的应用程序创建了自己的应用程序&我看过的大多数应用程序似乎都是自己的。
也许我可以继续使用内置的ASP.NET成员资格提供程序，将角色用作组，不再询问"用户是否在角色中"：
User.Identity.IsAuthenticated && Roles.IsUserInRole(user, role)
相反，我可以添加任务列表和权限列表如下：
Tasks
Task1 name="Accounting"
Allow roles="Accounting", "Executive"
Allow users="SalesPerson1", "OtherPerson2" //Granted people
Deny users="AccountingPerson1" //Banned person
并请求用户许可
User.Identity.IsAuthenticated && MyCustomSecurity.HaveRight(user, task)
好吧，有人已经做了我提到的：
http://permissionmanager.codeplex.com/
要回答您的问题，基本上有两种方法可以允许/拒绝用户访问资源或执行特定活动。
- 禁用一切或禁止一切(所有控件或组件)，然后通过打开可能性的权限授予访问权限。这种方式是最安全的方式，用户将不能做任何事情，除非他/她已经被允许采取行动
- 默认情况下允许所有操作，然后指定限制以禁止或禁用操作。这是一种更快的方法，在这种情况下，您需要通过权限来创建更少的限制
ASP.net成员身份是一个在粒度、安全性、操作审核等方面受到限制的功能，如果时间不受限制，您仍然可以扩展它。