0

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

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

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

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

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");
    }

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

这就是我分配角色的方式

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. 角色的构造函数将变得很长。
  2. 分配的角色也会变长。并且用户可能属于多个组。
  3. 授权属性也将大幅增长。

例如关注点 3：

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

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

这似乎是一种管理情况并保持代码清洁的智能方法吗？如果是这样，覆盖 Authorize 属性是要走的路吗？

4

1 回答 1

1

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

于 2013-08-15T14:52:14.943 回答