ASP.NET Custom Role Provider - Additional Fields

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开发者_Python百科 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?

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.

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.

Your problem is not in the role provider, or the membership system. This system is suitably flexible enough for your needs, and allows you to assign multiple roles to individual users. You can either use a SQL table to store these roles, or you can use Active Directory, AD is probably easier to manage the users with.

Your primary problem is going to be how you assign permissions to the fields and other objects. This means you can't just use standard drag and drop web forms, but will have to build your fields dynamically.

It's easy enough to check whether a user is in a role, this is a one-line call. But, your roles will likely not be hard coded, so you need a way to store fields and the roles associated with them, and a way to build the fields based on the users privileges.

EDIT:

Another option is to build the forms as if there was no security, then in your pre-render event go through and apply your security to each field, disabling and/or hiding fields you don't want the users to see. This may require relaying out the fields if you choose to hide them.