Question

When Roles are created/deleted I wouldn’t want to modify the code.

if (HttpContext.Current.User.IsInRole("Super Admin") ||
    HttpContext.Current.User.IsInRole("Admin") ||
    HttpContext.Current.User.IsInRole("Support"))
{
    if (HttpContext.Current.User.IsInRole("Admin"))
    {
        ListBox1.DataSource = Roles.GetAllRoles().Except(
            new[] { "Super Admin" });

    }
    if (HttpContext.Current.User.IsInRole("Support"))
    {
        ListBox1.DataSource = Roles.GetAllRoles().Except(
            new[] { "Super Admin", "Admin" });
    }
    fillDropDownCustomers();
}

Answer 1

Roles work by assigning a value to something a user can do. The Roles dont change but the behaviour for those roles does. Ultra dynamic solutions tend to be overkill.

So perhaps you have the following roles

• Super Admin
• Support
• Admin

You can have different Actions (This would depend on your system)

• View
• Edit
• Approve

Etc

• Super Admin [View, Edit, Approve]
• Support [View]
• Admin [View, Edit]

The dynamic part comes in the assignment of Actions. Doing things this way you dont care what Role someone is in but what actions they have. The Actions are the dynamic aspect in this relationship. When a request is made you will use the users Role to fetch the assigned Actions to that role (Database Driven to make modifiable)

Incorporating this into your Database structure as “Role has many Actions“, means that if things change in the future you will need to update the relationship in the database but not code.

A database structure could look something like this, depends on your needs.

• UserRole [ID, UserName, RoleID] (If user is assigned more than one role they inherit all actions, which might be duplicated and therefore selected DISTINCT or prevent this scenario, but I believe the former provides greater flexibility without complexity and limitation. NOTE: the UserRole table could be further denormalized to make UserNames unique.)
• Role [ID, Name]
• Action [ID, Name]
• RoleAction [ID, RoleID, ActionID] (Unique Key Constraint on RoleID and ActionID)

When a request is made, you identify the user etc UserName, Then workout which Role(s) they are in by quering the RoleAction and thereby load their associated Actions

I would use enums for your Action and Role values. This makes it easier to work with. To ensure that the Database and Code are in sink, ensure that you write a Unit Test reconcile the database values against the enum values.