ASP.NET Custom Role Provider - Additional Fields

Question

I am faced with a security model problem when migrating my code to ASP.NET.

In the application:

1. There are multiple roles. (Role A, Role B etc)

2. There are multiple input/output fields. (Field A, Field B etc)

3. There are multiple permission levels controlling access to each field. (Read, Direct Edit, Edit With Approval, None)

4. Each role has its own permissions to fields. (Role A has Read Permission to Field A; Role B has Direct Edit permission to Field A etc)

5. Every role can be assigned to users and they are assigned by Geographic information. (User A is assigned to Role A for Continent: Europe - Country: Germany; User B is assigned to Role A for Continent: Europe - Country: France; User A is assigned to Role B for Continent: Europe - Country: France etc)

6. Users can have multiple roles

7. User identity is coming from Windows Authentication.

So my question/problem is: is it possible to represent this type of kind of multi-layered security model using ASP.NET internal membership/role providers?

If so, what should my starting point be? Creating only custom role provider with custom methods and fields be enough?

Answer 1

Even with the built in features of ASP.NET, the Membership Provider, and user controls, you will still have to write and manage the custom behaviors and interactions.

As example, the Membership Provider has easy ways for your to create roles and check for the existence of roles. But you will have to create the business specific dashboard call the features of the API that are appropriate to expose for your application. As example, at many of the organization that I have worked with role creation was a database only activity. User controls or site behaviors based on role were a code only activity. Managing which roles were assigned to users was a feature exposed via an admin page in the application. If a need for a new role was identified, it had to be first created by a DBA, then code/controls that were responsive to that role had to be written. After these items were deployed, application administrators could assign or remove roles to users.

To address you comment to your question, if you have Europe_Germany_RoleA, the Membership API provides methods for you to create that role, map it to a user, and to check for its existence on a particular user. like...

if(User.Roles.Contains("Europe_Germany_RoleA")) {
//your code here
}

but you would need to map that particular role to information or features specific to your application.

In retrospect, maybe what you really want to look at is the Profile Provider. Still part of the Membership set (Membership, Roles, Profiles), it is more designed to carry information. You could customize the Profile object to meet the needs of your application. For example, if you looked at this as Sectors (for lack of a better term) that could be loaded when the user logged in, you could do queries like...

if(Profile.Sectors.FirstOrDefault(sd=> sd.Name == "Europe_Germany_RoleA") !=  null) {
//bind to a grid, show a control, do something significant
}

and that might fit your problem better. Roles are truly only meant to act as flags (Does he have this role or not, then do something or dont), but the Profile object is designed to be customized to carry pertinent data for a user.

Answer 2

You can always extend it. The ASP.NET Membership model uses GUIDs as IDs for users and roles. You can add new tables that represent the added functionality and have them reference the original Membership tables.