基于活动的会员资格可能适合这里。
在基于活动的成员资格中,您的用户可以访问操作,而不是角色。典型用法是:
- 一项行动 = 一项活动
- 仍然为用户分配了角色,但它们用于对活动进行分组
- 角色和活动之间存在 n..n 关系
Activity只是应用于操作的自定义操作过滤器。典型的例子是here(虽然我不喜欢这种方法,所以我做了自己的实现)。
[Activity(Name="DoSomething")]
public ActionResult DoSomething()
{
...
return View();
}
成员资格可以存储在 ASP Membership 数据库表、自定义表中或表示为 AD 组。取决于您是实现自定义成员资格提供程序还是使用默认实现。
最后,必须有类似RoleActivity的 n..n 关系,您可以在其中将特定角色链接到活动(例如 Manager1 到 AddMemberToDepartment 和 AddComment,Manager2 到 AddComment)。这种关系可以是经典的 n..n 数据库关系或“虚拟”关系,其中角色在 AD 中,数据库表仅通过组名与其相关。
编辑:
如果您使用基于默认数据库角色的授权,将为您生成表 aspnet_Roles。要支持基于活动的成员资格,您必须手动添加自己的活动表,以及额外的角色-活动关系。此架构应该可以帮助您继续进行。
aspnet_Roles (autogenerated)
* ApplicationId
* RoleId
* ...(other autogenerated columns)...
aspnet_MyActivity (add manually)
* ActivityId
* ApplicationId
* Name
* Description
aspnet_MyPermission (add manually)
* ApplicationId
* RoleId
* ActivityId
您可以使用会员提供者来填充角色。然后根据应用程序的需要手动填充您的活动,例如,每个操作方法一个活动。最后,手动将您的活动权限添加到角色。
真实世界场景
如果您的组织足够小,则可以为每个部门添加一个角色,每个行动/部门添加一个活动:
- 角色:部门 经理。ABC的,
- 角色:部门 经理。XYZ 的,
- 活动:createAbcUser,
- 活动:createXyzUser
使用适当的权限连接它们,您就可以满足您的要求。
但是,对于大量部门而言,为每个部门添加一个角色并为每个部门授予活动权限可能会有些尴尬。在这种情况下,您应该坚持简单的角色“部门经理”和简单的活动“创建用户”,并授予您的经理创建用户的权限。但是,您必须阻止经理在不同部门创建用户 - 为此使用您的层次结构,这意味着检查您的用户是否属于您的经理。
您的操作过滤器将如下所示:
- 检查任何当前用户角色是否有权运行该活动
- 检查您的层次结构:您当前的用户是否有权在引用的用户上工作?
如果这两个都为真,则可以执行 action 方法。
注意:您可能会通过某些输入参数引用用户,因此您的操作过滤器必须访问该参数。请参阅在操作过滤器中获取操作参数的值以解决该问题。