Security Through Authorization

In the preceding section you saw that regardless of what means of authentication is used, all users will appear to ASP.NET pages as an instance of IPrincipal, which in turn has an Identity property of type IIdentity. Using these standard interfaces, your code can function properly under any authentication scheme. The next section of this chapter deals with the concept of authorization, which is the process by which an authenticated user is permitted or denied access to specific resources. In other words, authentication deals with who a user is, and authorization deals with what the user can do.

Authorization with Roles

As you saw in the preceding section of this chapter, authentication is supported largely by the Membership API and Membership providers like the SQL Membership provider. The Provider model is used throughout ASP.NET to create standard interfaces in commonly used design patterns. Membership is something that virtually every ASP.NET website has to deal with in some form, so the Membership provider was used to standardize how that is done, creating a huge benefit for developers.

Authorization in ASP.NET applications is largely supported by the Role provider. A Role provider is a pluggable provider that gives programmers a standard API for determining users' role membership as well as manipulating the roles to which users belong. If you use the provider model, the code for your role-based application will be identical whether the user role membership is stored in SQL Server, Access, Active Directory, or some other proprietary data store.

Just as with the Membership provider, you need to tell your application which Role provider you're using. The first step is to define a connection string. If you followed along with the preceding example, you already have a connection string in your Web.config file. The next step is to define the <roleManager> element. An example of a <roleManager> element is shown in the following code:

<roleManager   defaultProvider="SqlProvider"   enabled="true" cacheRolesInCookie="true"   cookieName=".ASPROLES" cookieTimeout="30"   cookiePath="/" cookieRequireSSL="false"   cookieSlidingExpiration="true" cookieProtection="All">   <providers>     <add name="SqlProvider"         type="System.Web.Security.SqlRoleProvider"         connectionStringName="LocalSqlServer"         applicationName="RolesDemo"/>   </providers> </roleManager> 

Access to the majority of the functionality available through the Role management provider is available through the Roles class. Table 28.3 lists some of the properties of the Roles class and Table 28.4 lists some of its methods that you will be using in your own role-based security implementation.

Table 28.3. Roles Properties

Property	Description
ApplicationName	The name of the application for which role data is stored.
CacheRolesInCookie	Indicates whether the role information is cached in a cookie. If there is more information than a cookie can hold, only recent Roles are stored in the cookie and the rest are fetched as needed.
CookieName	Gets or sets the name of the cookie used for role caching.
CookiePath	The path of the cookie that was set by CookieName.
CookieProtectionValue	Indicates how the role names are protected within the cookie.
CookieRequireSSL	Indicates whether the role name cache cookie requires SSL in order to be given to the server.
CookieSlidingExpiration	The sliding expiration period for the role name cache cookie.
CookieTimeout	The timeout period for the role name cache cookie.
CreatePersistentCookie	Indicates whether the cookie for storing role name caches is persistent or session-based.
Domain	The domain of the role name cache cookie.
Enabled	Indicates whether role management is enabled for the current application. The default is true.
MaxCachedResults	Indicates the maximum number of roles that can be cached for a user.
Provider	Gets the Role provider for the current application.
Providers	Gets the collection of all Role providers for the current application.

Table 28.4. Roles Methods

Method	Description
AddUsersToRole	Adds a list of users to a given role.
AddUsersToRoles	Adds a list of users to a list of roles.
AddUserToRole	Adds a user to a role.
AddUserToRoles	Adds the user to a list of roles.
CreateRole	Creates a new role in the underlying role store.
DeleteCookie	Deletes the role name cache cookie.
DeleteRole	Deletes a role from the data source. Existing users will no longer be a part of the deleted role.
FindUsersInRole	Returns the list of users in a given role that match the supplied username wildcard.
GetAllRoles	Returns the list of all roles configured in the system.
GetRolesForUser	Returns the list of all roles to which the user belongs.
GetUsersInRole	Returns the list of all users belonging to the supplied role.
IsUserInRole	Indicates whether the user (current or supplied) is in the supplied role.
RemoveUserFromRole	Removes the user from the indicated role.
RemoveUserFromRoles	Removes the user from the indicated roles.
RemoveUsersFromRole	Removes the specified list of users from the specified role.
RemoveUsersFromRoles	Removes the list of users from the specified roles.
RoleExists	Indicates whether a role with the supplied name exists in the data store.

As you will see in the next section, working with Users and Roles when using the Membership and Role providers has already been wrapped into a few extremely handy server controls that ship with ASP.NET 2.0. To see how the Role system works programmatically, try walking through a quick sample.

The first thing you need to do is create a user. To create a new user, you can use the Membership.CreateUser method as shown in the following code:

string newPassword = Membership.GeneratePassword(8, 2); MembershipCreateStatus status; Membership.CreateUser("kevin", newPassword,   "[e-mail]", "What is the answer?", "42", true,   out status); Response.Write("Attempt to create user 'kevin' with password '" +    newPassword + "' was " + status.ToString() + "<BR>"); 

When you have a user, you can start playing around with the Role membership system. For example, the following code creates several new Roles and adds the current user to a few of them:

Roles.CreateRole("Administrators"); Roles.CreateRole("Validated Users"); Roles.CreateRole("Applicants"); Roles.AddUserToRole("kevin", "Administrators"); Roles.AddUserToRole("kevin", "Validated Users"); Response.Write("User 'kevin' belongs to the following Roles:<BR>"); foreach (string roleName in Roles.GetRolesForUser("kevin")) {   Response.Write(     string.Format("<b><i>{0}</b></i><br>", roleName)); } 

I can't stress enough how important the impact of the provider model is. The common tasks of building a Membership and Role systemwhich most of us have built over and over again for many different ASP.NET applicationshave been completely abstracted into a provider model. This allows you to create standardized code that works against a standard Membership and Role system, and you will know that your code will work on any other application that is using the Membership and Role providers.