Section 4.11. Use Role-Based Authorization

4.11. Use Role-Based Authorization

In many web applications, all users are not equal. Some might be allowed to perform a carefully restricted set of actions, while others are given free reign to perform more advanced administrative tasks. ASP.NET 2.0 makes it easier than ASP.NET 1.x to assign permissions to different groups of users using the new role-management service.

---

Note: Do you need to give different privileges to different types of users? The easiest way to implement this logic is by using ASP. NET's new role-management service.

---

4.11.1. How do I do that?

ASP.NET uses a role-management service to manage the storage and retrieval of role-based information. ASP.NET gives you the flexibility to use different role-manager providers to store the role information in different data sources. Usually, you'll use the same data store that you use for membership (as described in the lab "Easily Authenticate Users"). Because the membership provider and the role-manager provider use different tables, you don't need to worry about a conflict.

Role management is not enabled by default. You can enable it by using the WAT, as described in the lab "Administer a Web Application." Just select Website ASP.NET Configuration and choose the Security tab. Then click the "Enable roles" link in the Roles box. This modifies the web.config as needed. However, you'll still need to configure the roles you want to use.

The easiest way to add role information is also through the WAT. To do so, click the "Create or Manage roles" link in the Roles box on the Security page. This presents a page where you can add new roles and assign users to existing roles. To add a new role, type in the role name and click Add Role. You'll see the role appear in the list below. Figure 4-14 shows an example with two groups, Administrators and Sales Officials. Note that you won't see group membership on this page.

Figure 4-14. Adding a new role

To change group membership, click the Manage link next to the appropriate role. Because a typical system could easily have hundreds of users, the WAT does not attempt to show all the users at once. Instead, it allows you to specify the user that you want to add to the role by typing in the name, browsing an alphabetical directory, or using a search with wild cards (as in John* to find usernames starting with John). Once you've found the appropriate user, place a checkmark in "User Is In Role" column to add the user to the role, or clear the checkbox to remove the user, as shown in Figure 4-15.

Figure 4-15. Assigning a role to a user

Using this tab, you can examine the list of users (including the test user you added in the previous step) and modify their information. What you really need to do, however, is click the "Create access rules" link to restrict access to the Secured directory. Select the directory in the list, choose the Deny Permission option, and select Anonymous users, as shown in Figure 4-13. Then, click OK to add this rule.

When a user logs in using forms authentication (as described in the lab "Easily Authenticate Users"), the role-management service automatically retrieves the list of roles that the user belongs to and stores them in an encrypted cookie. After this point, it's easy to test the role membership of the currently logged-in user.

For example, the following code checks if the user is an Administrator. In order for this to work, the user must have logged in:

If Roles.IsUserInRole("Administrator") Then     ' (Allow the code to continue, or show some content     ' that would otherwise be hidden or disabled.) End If

And, finally, this code displays a list of all the roles that the user belongs to:

For Each Role As String In Roles.GetRolesForUser( )     lblRoles.Text &= Role & " " Next

Clearly, none of these tasks requires much work!

You can also set and retrieve role information using the System.Web.Security.Roles class. Here are the core methods you'll want to use:

CreateRole( )

This creates a new role with the designated name in the database. Remember, roles are just labels (like Administrator or Guest). It's up to your code to decide how to respond to that information.

DeleteRole( )

Removes a role from the data source.

AddUserToRole( )

Adds a record in the data store that indicates that the specified user is a member of the specified role. You can also use other methods that work with arrays and allow you to add a user to several different roles at once, or add several different users to the same role. These methods include AddUserToRoles( ), AddUsersToRole(), and AddUsersToRoles( ).

RemoveUserFromRole( )

Removes a user from a role.

GetRolesForUser( )

Retrieves an array of strings that indicate all the roles a specific user belongs to. If you're retrieving roles for the currently logged-in user, you don't need to specify a username.

GetUsersInRole( )

Retrieves an array of strings with all of the usernames that are in a given role.

IsUserInRole( )

Tests if a user is in a specific role. This is the cornerstone of role-based authorization. Depending on whether this method returns true or False, your code should decide to allow or restrict certain actions. If you're testing the group membership of the currently logged-in user, you don't need to specify a username.

The following code snippet creates a role and adds a user to that role:

Roles.CreateRole("Administrator") Roles.AddUserToRole("testUser", "Administrator")

4.11.2. What about...

...performance? At first glance, role management might not seem very scalable. Reading the role information for each web request is sure to slow down the speed of your application, and it may even introduce a new bottleneck as ASP.NET threads wait to get access to the database. Fortunately, the role-management service is quite intelligent. It won't make a trip to the database with each web request; instead, it retrieves role information once, encrypts it, and stores it in a cookie. For all subsequent requests, ASP.NET reads the roles from the encrypted cookie. You can remove this cookie at any time by calling Roles.DeleteCookie(), or you can configure settings in the web.config file to determine when it should expire on its own.

If you have an extremely large number of roles, the cookie might not contain them all. In this case, ASP.NET flags the cookie to indicate this fact. When your code performs a role check, ASP.NET will try to match one of the roles in the cookie first, and if it can't find a match, it will double-check the data source next.

4.11.3. Where can I learn more?

For more information, look up the index entry "role-based security ASP.NET in the MSDN Help.