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