同一网站中的多个ASP.NET成员身份角色

时间:2013-06-14 11:34:22

标签: asp.net sql sql-server asp.net-mvc-3

在我的 MVC3应用程序中,我有 ASP.NET成员角色,如经理,系统管理员和编辑 我正在为网站使用 Windows身份验证,我正在将网络中的用户添加到成员资格中,就像在以下示例中一样 -

http://weblogs.asp.net/scottgu/pages/Recipe_3A00_-Implementing-Role_2D00_Based-Security-with-ASP.NET-2.0-using-Windows-Authentication-and-SQL-Server.aspx

但是,我的问题是需要多个权限的人。例如

User-John Department-ABC经理,他可以看到Department-ABC中的所有操作。 User-John 也是Department-XYZ的编辑,他应该能够在Department-XYZ中看到编辑器的所有动作; 但不是经理的行为;因为他不是Department-XYZ的经理

用户Mathew是Department-XYZ的经理,他是Department-ABC的编辑。

如果我使用普通角色权限,它将允许User-John成为两个部门的经理,但这是不对的。

我的解决方案是将DepartmentID,UserID和RoleID存储在SQL数据库的单独表中,并根据此表允许。

如何从C#和ASP.NET中的ASP.NET成员身份获取角色ID?

安全吗? 有更好的解决方案吗?

1 个答案:

答案 0 :(得分:0)

基于活动的会员资格可能适合这里。

在基于活动的成员资格中,您的用户可以访问操作,而不是角色。 典型用法是:

  1. 一个动作=一个活动
  2. 仍有给用户的角色,但它们用于分组活动
  3. 角色和活动之间存在n..n关系
  4. 活动只是应用于操作的自定义操作过滤器。 典型的例子是here(虽然我不喜欢这种方法,所以我自己实现了。)

     [Activity(Name="DoSomething")]
     public ActionResult DoSomething()
     {
         ...
         return View();
     }
    

    成员资格可以存储在ASP成员资格数据库表,自定义表中或表示为AD组。取决于您是实现自定义成员资格提供程序还是使用默认实现。

    最后,必须有n..n关系,例如 RoleActivity ,您可以将特定角色链接到活动(例如,将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
    

    您可以使用会员提供者填写角色。 然后在应用程序需要时手动填写您的活动,比如每个操作方法一个活动。 最后,手动将您的活动权限添加到角色。

    真实世界情景

    如果您的组织足够小,可以为每个部门添加一个角色,每个操作/部门添加一个活动:

    • 角色:Dep。经理。 ABC,
    • 角色:Dep。经理。 of XYZ,
    • 活动:createAbcUser,
    • activity:createXyzUser

    使用适当的权限连接它们,并满足您的要求。

    但是,对于大量部门而言,每个部门添加一个角色并为每个部门提供活动权限可能会有点尴尬。在这种情况下,您应该坚持使用简单的角色“部门经理”和简单的活动“创建用户”,并授予您的经理创建用户的权限。但是,您必须停止经理在其他部门创建用户 - 使用您的层次结构,这意味着,检查您的用户是否属于您的经理。

    您的操作过滤器将如下所示:

    • 检查当前用户角色是否具有运行该活动的权限
    • 检查您的层次结构:您当前的用户是否有权使用引用的用户?

    如果两者都为真,则可以执行操作方法。

    注意:您可能会通过某个输入参数引用用户,因此您的操作过滤器必须访问该参数。请参阅Getting the values of action parameters within an action filter以解决此问题。