使asp.net SimpleMembershipProvider角色具有层次关系的策略

本文关键字：层次 关系 策略 asp net SimpleMembershipProvider 角色 | 更新日期: 2023-09-27 18:27:16

我意识到这个问题可能很简单，但答案并不是我想要的。

一个更接近我想要的问题是这个SO问题。

目前的情况是，我正在使用和ASP.NET MVC4应用程序使用SimpleMemberShip Provider。我根据他们在Active Directory中喜欢的位置来定义角色。因此，登录和用户访问是基于他们在AD中居住的OU/组。当他们登录时，我会这样做：

在自定义登录界面的构造函数中

static UserAuthenticationManager()
    {
        //Create some roles for SimpleMembership 
        if (!Roles.RoleExists("IT"))
            Roles.CreateRole("IT");
        if (!Roles.RoleExists("Student"))
            Roles.CreateRole("Student");
        if (!Roles.RoleExists("Faculty"))
            Roles.CreateRole("Faculty");
        if (!Roles.RoleExists("Adjunct"))
            Roles.CreateRole("Adjunct");
    }

随着内联网应用程序向不同部门开放，这将随着时间的推移（大幅）增长。

这就是我分配角色的方式

if (StaffAd.UserIsInGroup(username, "IT"))
            Roles.AddUserToRole(username, "IT");
        if (StaffAd.UserIsInGroup(username, "Faculty"))
            Roles.AddUserToRole(username, "Faculty");
        if (StaffAd.UserIsInGroup(username, "Adjunct Faculty Current"))
            Roles.AddUserToRole(username, "Adjunct");
        if (StaffAd.UserIsInGroup(username, "Active_Student"))
            Roles.AddUserToRole(username, "Student");

在这种情况下，"UserIsInGroup（）"方法采用AD的用户名和名称，以验证用户是否是组的一部分。

我担心的问题是

  1. 角色的构造函数将被loooooong
  2. 分配的角色也会变长。用户可能属于多个组
  3. Authorize属性也将大幅增长

例如问题3：

[Authorize(Roles = "IT, DegreeTracker, Student")]

我希望能够确保我不会遇到一些障碍，比如角色更改（可能只是添加代码来查看一个人是什么角色，并在每次登录时更新到最新），以及管理很多角色。很多角色可以组合在一起，比如"DegreeTracker"answers"Student"都是AD组，所以我可以定义一个名为"DegreeUsers"的角色，它是两个子角色的父角色。

这似乎是一种管理情况和保持代码清洁的智能方法吗？如果是这样，那么重写Authorize属性是正确的方法吗

使asp.net SimpleMembershipProvider角色具有层次关系的策略

看看这篇关于将安全设计与应用程序设计脱钩的文章。我认为在这种情况下它可能很有用。本文展示了如何扩展SimpleMembership数据库，并创建一个自定义的authorize属性，该属性接受资源和操作作为参数，而不是角色。在这种情况下，您的资源将是Active Directory中的组织单位。然后，您可以修改角色到数据库中资源/操作的映射，而不是遍历所有代码并更改authorize属性、重新编译和重新部署。

相关文章：