Strategies for making asp.net SimpleMembershipProvider Roles have hierarchical relationships

Question

I realize this may be simple to this Question, but the answer is not quite what I am looking for.

A closer question that may be what I want is this SO question.

The situation is I am using and ASP.NET MVC4 application using SimpleMemberShip Provider. I am defining roles based off of where they like in out Active Directory. So the login and user access is based on what OU/Group they live in inside AD. I do something like this when they login:

In the Constructor of the custom login interface

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

This will grow (substantially) over time as the intranet app opens to different departments.

This is how I assign the roles

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

In this the 'UserIsInGroup()' method takes the username and the name of the AD which verifies the user is part of the group.

The issues I am concerned about coming up are that

1. The constructor for the Roles is going to get loooooong.
2. Assigned Roles will get long as well. And Users could potentially belong to multiple Groups.
3. The Authorize Attribute will grow substantially as well.

For example of concern number 3:

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

I want to be able to make sure I don't run into a couple of roadblocks, such as Role changes (Probably just add code to see what Roles a person is and update to latest every time they log in), as well as Managing a lot of roles. A lot of the roles can be grouped together, like 'DegreeTracker' and 'Student' are both AD groups, so I could define a role called 'DegreeUsers' that is a parent role of the two child roles.

Does that seem like an intelligent way to manage the situation and keep the code cleaner? If so, is overriding the Authorize attribute the way to go?

Answer 1

Take a look at this article on decoupling your security design from application design. I think it might serve well in this scenario. This article shows how to extend the SimpleMembership database and create a custom authorize attribute that accepts resources and operations as parameters instead of roles. In this case your resources would the Organizational Unit in your Active Directory. You can then modify the mapping of roles to resources/operations in your database instead of going through all of the code and changing authorize attributes, recompiling, and redeploying.