如何在ASP.NET Membership中最好地处理权限（而不是角色），特别是在ASP.NET MVC中。

Question

如何在ASP.NET Membership中最好地处理权限（而不是角色），特别是在ASP.NET MVC中。

asp.net-mvcasp.net-membershipasp.net-rolesasp.net-authentication

11

有很多关于设置asp.net成员资格、角色提供程序等方面的问题（和信息）。无论您是否应该使用微软提供的内置平台，或者扩展基类并自己创建角色。

我决定扩展默认提供程序并实现自己的成员身份验证和角色提供程序。现在，我的问题是围绕角色认证的具体问题。

传统上，您可能会创建诸如“经理、管理员、员工、超级用户”之类的角色。但是对于我认为更精细的控制的权限，您应该怎么做？让我详细说明一下...

在我的asp.net mvc站点中，我有不同的区域，例如管理、管理、消息、报告等。我会为每个区域创建角色，如“管理员”、“经理”、“报告人”等。如果没有适当的角色，您将无法访问该站点的任何区域。因此，我会在类级别上锁定整个控制器。

但现在以一个区域为例; 消息，如果我想要更精细的CRUD操作权限，比如创建消息、查看/读取消息、编辑消息、删除消息等，该怎么办呢？

最后我的问题是，如何最好地实现这种更精细的控制？我看到的一个方法（不确定是否好），是为所有内容创建asp.net成员资格角色。因此，我可能会有...

信使（广泛的角色），CreateMessage，ReadMessage，EditMessage，DeleteMessage。

一方面，我希望某些用户能够阅读/查看消息。但并不一定要创建或删除它们。各个控制器操作可以应用特定的角色。

您是否认为这种方法存在问题？您有更好的想法吗？

目前的解决方案

我已经决定创建自己的架构并实现自定义成员身份验证和角色提供程序。我的架构包括;

User（用户）
UserProfile（用户资料）
Permission（权限）
PermissionAssignment（权限分配）
Role（角色）
RoleAssignment（角色分配）

接下来的一两天我会离开，但在我有机会时会更新更多信息。

- Joshua Hayes

3个回答

2

关于您的CRUD示例，您实际上在谈论授权，那么在成员角色“Manager”和“Reporter”之间，授权是否会有所不同？如果角色不能区分消息的读写授权，我认为您需要为这些更细粒度的活动创建一个单独的机制。

如果您为每个操作创建一个角色-EditMessage，DeleteMessage-当A经理不应该能够删除B经理的消息时，您将怎么做？

- David Robbins

嗨，大卫，感谢您的意见。“我认为，如果角色在消息之间没有区分读取和写入授权，则需要为这些更细粒度的活动创建单独的机制。”好吧，这正是我想知道的。至于您的情况...不确定。不过说得好。我不认为那会成为问题。我主要考虑到高级经理将完全访问站点的某个区域，而他们可能会给予下属员工部分访问权限（只读？）等。与一般角色相比，我还没有看到有关权限的讨论。 - Joshua Hayes

去年我在一个项目中遇到了同样的情况，我有AgentManager和Agent等角色，但授权规则是只有代理人David Robbins可以看到他自己的记录，而AgentManager只能看到她直接报告的记录。我通过在SQL中使用几个表来表示代理人和代理经理以及他们各自的记录之间的关系来解决了这个问题。 - David Robbins

-1

除了在控制器上方添加[Authorize(Roles="Administrator")]等内容之外，您还可以将该属性放置在各个操作上

- BritishDeveloper

我在我的问题中确实提到了这一点。“...个别控制器操作可以应用特定的角色。” - Joshua Hayes

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- JOBG · Accepted Answer

我认为你应该忘记授权机制中的角色，而是请求权限（最终一个角色是权限的集合），因此，如果你这样考虑，你的Authorize属性应该请求实体和操作，而不是特定的角色。类似于：

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

那样你的角色可以做到最好的事情，即抽象权限收集，而不是确定一种不灵活的访问级别方式。

编辑：为了处理像David Robbins指出的特定规则，例如Manager A不允许删除Manager B创建的消息，假设他们都有所需的访问权限来访问此控制器操作，Authorize不负责检查这种类型的规则，即使您尝试在Action Filter级别检查也会很麻烦，因此您可以将Authorize验证扩展到ActionResult（注入一个保存验证结果的操作参数），并让ActionResult在那里使用所有参数进行逻辑决策。这是一个类似的问题，虽然不完全是在这里指出的情况，但它是用Action参数扩展Authorize验证的良好起点。