我知道这是一个一直被问到的问题，但是我试图在ASP.NET MVC应用程序中实现基于权限而不是基于角色的授权。因此，我不需要像Manager，Admin或User这样的高级角色，而是需要拥有ViewTask，AddTask，DeleteTask等权限。我已经阅读了大量的评论，似乎最简单的解决方案是将角色视为权限，并定义ViewTask，AddTask和DeleteTask的“角色”。
这样的做法真的是个好主意吗？我的一些担忧是，根据应用程序的大小，您可以获得超过100个角色，然后排除在Cookie中执行角色缓存的能力，因此每次调用User.IsInRole都会触发数据库。如果每个操作方法都将使用[Authorize(Roles =“XXXX”)]进行装饰，我会看到严重的性能问题？
我的另一个问题是，我仍然希望保持角色的概念，以便管理员可以简单地将用户与具有预定义权限集的角色相关联。使用我以上思路的方法是在我的应用程序名为Group中创建一个单独的实体，该组将负责跟踪分配给该组的ASP.NET角色。因此，当用户与组关联时，我可以检索需要分配给用户的ASP.NET角色并添加所有角色。
有没有人以这样的方式实施系统？对这种方法的任何意见或想法将不胜感激。
谢谢
解决方法
我同意@jlew关于缓存用户的数据，以及缓存何时到期 – 只是重新加载它。没有任何努力强制这些数据保持持续。另外，如果你想离开ASP.net角色提供程序，你可以滚动自己的安全性，因为我有
described in this reply.这具有允许非常自定义安全解决方案角色/个人权限的优势。
以下只是一个想法，我最近一直在玩耍(只是一些食物的想法)。为什么不使用MVC的RESTful URL来定义“权限”。例如：
/ tasks / add可以定义添加任务的权限。这些可以以某种方式进行层次化，以便赋予用户对/ tasks / add的权限也赋予他们对/ tasks的权限。然后，您可以使用一个全局操作过滤器，该过滤器将在给定路由值的情况下构建URL。这也将允许通过运行时可配置的单个项目安全性的真正有趣的方法。例如，/ tasks / edit / 23可以以某种方式授予id 23的任务的编辑权限。无论如何，这甚至可能不是有帮助的…但是只是以为我想你可能会考虑。
干杯!
