Multiple ASP.NET Membership roles in the same Website - asp.net

Question

In my MVC3 application I have ASP.NET Membership roles like - Manager, System Admin and Editor
I am using Windows Authentication for the website and I am adding the users in the Network to the Membership just like in the following example -
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
But, my problem is there are people who require multiple permissions. For example
User-John is the Manager of Department-ABC and he can see all the Actions in Department-ABC.
User-John is also Editor in Department-XYZ and he should be able to see all the Actions of an Editor in Department-XYZ;
but NOT the Actions of Manager; because he is not the Manager of Department-XYZ.
User Mathew is the Manager of Department-XYZ and he is an Editor in Department-ABC.
If I use normal role privileges, it will allow User-John to be the Manager of both departments and it is not right.
My solution is to store the DepartmentID, UserID and RoleID in a seperate table in SQL database and allow according to this table.
How can I get the role ID from ASP.NET Membership in C# and also in SQL?
Is it safe to do?
Is there a better solution?

Answer 1

Activity based membership would probably fit here.
In activity based membership your users get access to actions, not to roles.
Typical usage is:
One action = one activity
There are still roles given to users, but they are used to group activities
There is n..n relation between roles and activities
Activity is just a custom action filter that is applied to the action.
Typical example is here (although I don't like this approach, so I made my own implementation).
[Activity(Name="DoSomething")]
public ActionResult DoSomething()
{
...
return View();
}
Membership can be stored in ASP Membership database table, custom table or represented as AD group. Depends whether you implement custom membership provider or you use default implementation.
At the end, there has to be n..n relationship like RoleActivity, where you link the particular role to the activity (like Manager1 to both AddMemberToDepartment and AddComment, and Manager2 to just AddComment). This relation can be classic n..n database relation or 'virtual', where role is in AD and database table relates to it only via group name.
EDIT:
If you use default database role based authorization, table aspnet_Roles will be generated for you. To support activity based membership you will have to add your own activity table manualy, along with additional role-activity relation.
This schema should help you proceed.
aspnet_Roles (autogenerated)
* ApplicationId
* RoleId
* ...(other autogenerated columns)...
aspnet_MyActivity (add manually)
* ActivityId
* ApplicationId
* Name
* Description
aspnet_MyPermission (add manually)
* ApplicationId
* RoleId
* ActivityId
You can fill roles using membership provider.
Then fill manually your activities as your application needs them, say, one activity per action method.
Finally, manually add your activity permissions to roles.
Real world scenario
If your organization is small enough, it may be acceptable to add one role per department and one activity per action/deparment:
role: Dep. mgr. of ABC,
role: Dep. mgr. of XYZ,
activity: createAbcUser,
activity: createXyzUser
Connect them using appropriate permissions and you have your requirement covered.
However, for a large number of departments adding one role per department and giving activity permission for each of them can be a little awkward. In that case you should stick with simple role "Department manager" and simple activity "Create user", and give your manager permission to create user. However, you have to stop manager to create user in a different department - use your hierarchy for that, meaning, check if your user belongs to your manager.
Your action filter will then look like this:
check if any of current users roles has a permission to run that activity
check your hierarchy: does your current user have a permission to work on referenced user?
If both of these are true, action method can be executed.
NOTE: You will probably reference user by some input parameter, so your action filter has to access that parameter. See Getting the values of action parameters within an action filter to solve that.