Professional ASP.NET 3.5 in C# and Visual Basic Part 81 pdf

Evjen c16.tex V2 - 01/28/2008 2:51pm Page 757 Membership and Role Management The authentication and authorization of users are important functions in many Web sites and browser-based applications. Traditionally, when working with Microsoft’s Windows Forms applications (thick-client), you depended on Windows Integrated Authentication; when working with browser-based applications (thin-client), you used forms authentication. Forms authentication enabled you to take requests that were not yet authenticated and redirect them to an HTML form using HTTP client-side redirection. The user provided his login information and submitted the form. After the application authenticated the request, the user received an HTTP cookie, which was then used on any subsequent requests. This kind of authentication was fine in many ways, but it required developers to build every element and even manage the back-end mechanics of the overall system. This was a daunting task for many developers and, in most cases, it was rather time-consuming. ASP.NET 3.5 includes an authentication and authorization management service that takes care of the login, authentication, authorization, and management of users who require access to your Web pages or applications. This outstanding membership and role management service is an easy-to- implement framework that works out of the box using Microsoft SQL Server as the back-end data store. This framework also includes an API that allows for programmatic access to the capabilities of both the membership and role management services. In addition, a number of membership and role management–focused server controls make it easy to create Web applications that incorporate everything these services have to offer. Before you look at the membership and role management features of ASP.NET 3.5, here’s a quick review of authentication and authorization. This is vital to understand before proceeding. Evjen c16.tex V2 - 01/28/2008 2:51pm Page 758 Chapter 16: Membership and Role Management Authentication Authentication is a process that determines the identity of a user. After a user has been authenticated, a developer can determine if the identified user has authorization to proceed. It is impossible to give an entity authorization if no authentication process has been applied. Authentication is provided in ASP.NET 3.5 using the membership service. Authorization Authorization is the process of determining whether an authenticated user is allowed access to any part of an application, access to specific points of an application, or access only to specific datasets that the application provides. When you authenticate and authorize users or groups, you can customize a site based on user types or preferences. Authorization is provided in ASP.NET 3.5 using a role management service. ASP.NET 3.5 Authentication ASP.NET 3.5 provides the membership management service to deal with authenticating users to access a page or an entire site. The ASP.NET management service not only provides an API suite for managing users, but it also gives you some server controls, which in turn work with this API. These server controls work with the end user through the process of authentication. You look at the functionality of these controls shortly. Setting Up Your Web Site for Membership Before you can use the security controls that are provided with ASP.NET 3.5, you first have to set up your application to work with the membership service. How you do this depends on how you approach the security framework provided. By default, ASP.NET 3.5 uses the built-in SqlMembershipProvider instance for storing details about the registered users of your application. For the initial demonstrations, the examples in this chapter work with forms-based authentication. You can assume for these examples that the application is on the public Internet and, therefore, is open to the public for registration and viewing. If it were an intranet-based application (meaning that all the users are on a private network), you could use Windows Integrated Authentication for authenticating users. ASP.NET 3.5, as you know, offers a data provider model that handles the detailed management required to interact with multiple types of underlying data stores. Figure 16-1 shows a diagram of the ASP.NET 3.5 membership service. From the diagram, you can see that, like the rest of the ASP.NET provider models, the membership providers can access a wide variety of underlying data stores. In this diagram, you can see the built-in Microsoft SQL Server data store. You can also build your own membership providers to get at any other custom data stores that work with user credentials. Above the membership providers in the diagram, you can see a collection of security-focused server controls that utilize the access granted by the underlying membership providers to work with the users in the authentication process. 758 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 759 Chapter 16: Membership and Role Management Server Controls Membership Server Controls <asp : Login>, etc. Membership API Custom Provider Custom SqlMembershipProvider SQL Server 7 .0/2000/2005/2008 Membership Providers Data Stores API Figure 16-1 Adding an < authentication > Element to the web.config File In order to have the forms authentication element in your Web application work with the membership service, the first step is to turn on forms authentication within the web.config file. To accomplish this, create a web.config file (if you do not already have one in your application). Next, add the section shown in Listing 16-1 to this file. Listing 16-1: Adding forms authentication to the web.config file < ?xml version="1.0" encoding="utf-8"? > < configuration > < system.web > < authentication mode="Forms" / > < /system.web > < /configuration > The simple addition of the < authentication > element to the web.config file turns on everything that you need to start using the membership service provided by ASP.NET 3.5. To turn on the forms authentication using this element, you simply give the value Forms to the mode attribute. This is a forms authentication example, but other possible values of the mode attribute include Windows , Passport , or None . IIS authentication schemes include basic, digest, and Integrated Windows Authentication. Passport authentication points to a centralized service provided by Microsoft that offers a single login and core profile service for any member sites. It costs money to use Passport, which has also recently been depre- ciated by Microsoft. Because the mode attribute in our example is set to Forms , you can move on to the next step of adding users to the data store. You can also change the behavior of the forms authentication system at this point by making some modifications to the web.config file. These possibilities are reviewed next. 759 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 760 Chapter 16: Membership and Role Management Adding a < forms > Element to the web.config File Using forms authentication, you can provide users with access to a site or materials based upon credentials they input into a Web-based form. When an end user attempts to access a Web site, he is entering the site using anonymous authentication, which is the default authentication mode. If he is found to be anonymous, he can be redirected (by ASP.NET) to a specified login page. After the end user inputs the appropriate login information and passes the authentication process, he is provided with an HTTP cookie, which can be used in any subsequent requests. You can modify the behavior of the forms-based authentication by defining that behavior within a < forms > section in the web.config file. You can see the possibilities of the forms authentication setting in Listing 16-2, which shows possible changes to the < forms > section in the web.config file. Listing 16-2: Modifying the forms authentication behavior < ?xml version="1.0" encoding="utf-8"? > < configuration > < system.web > < authentication mode="Forms" > < forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" timeout="30" path="/" requireSSL="false" slidingExpiration="true" cookieless="UseDeviceProfile" / > < /authentication > < /system.web > < /configuration > You can set these as you wish, and you have plenty of options for values other than the ones that are displayed. Also, as stated earlier, these values are not required. You can use the membership service right away with only the configuration setting that is shown in Listing 16-1. You can find some interesting settings in Listing 16-2, however. You can really change the behavior of the forms authentication system by adding this < forms > element to the web.config file. If you do this, however, make sure that you have the < forms > element nested within the < authentication > elements. The following list describes the possible attributes of the < forms > element: ❑ name : Defines the name used for the cookie sent to end users after they have been authenti- cated. By default, this cookie is named .ASPXAUTH . ❑ loginUrl : Specifies the page location to which the HTTP request is redirected for logging in the user if no valid authentication cookie ( .ASPXAUTH or otherwise) is found. By default, it is set to Login.aspx . ❑ protection : Specifies the amount of protection that you want to apply to the cookie that is stored on the end user’s machine after he has been authenticated. The possible settings include All , None , Encryption ,and Validation . You should always attempt to use All . ❑ timeout : Defines the amount of time (in minutes) after which the cookie expires. The default value is 30 minutes. 760 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 761 Chapter 16: Membership and Role Management ❑ path : Specifies the path for cookies issued by the application. ❑ requireSSL : Defines whether you require that credentials be sent over an encrypted wire (SSL) instead of clear text. ❑ slidingExpiration : Specifies whether the timeout of the cookie is on a sliding scale. The default value is true . This means that the end user’s cookie does not expire until 30 minutes (or the time specified in the timeout attribute) after the last request to the application has been made. If the value of the slidingExpiration attribute is set to false , the cookie expires 30 minutes from the first request. ❑ cookieless : Specifies how the cookies are handled by ASP.NET. The possible values include UseDeviceProfile , UseCookies , AutoDetect ,and UseUri . The default value is UseDevicePro- file . This value detects whether to use cookies based on the user agent of the device. UseCookies requires that all requests have the credentials stored in a cookie. AutoDetect auto-determines whether the details are stored in a cookie on the client or within the URI (this is done by sending a test cookie first). Finally, UseUri forces ASP.NET to store the details within the URI on all instances. Now that forms authentication is turned on, the next step is adding users to the Microsoft SQL Server Express Edition data store, ASPNETDB.mdf . Adding Users To add users to the membership service, you can register users into the Microsoft SQL Server Express Edition data store. The first question you might ask is, ‘‘Where is this data store?’’ Of course, there are a number of editions of Microsoft’s SQL Server that you can use to work through the examples in this book. With that said, this chapter uses the default database the membership system uses in creating users. The Microsoft SQL Server provider for the membership system can use a SQL Server Express Edition file that is structured specifically for the membership service (and other ASP.NET systems, such as the role management system). ASP.NET is set to automatically create this particular file for you if the appropriate file does not exist already. To create the ASPNETDB.mdf file, you work with the ASP.NET server controls that utilize an aspect of the membership service. When the application requires the ASPNETDB.mdf file, ASP.NET creates this file on your behalf in the App_Data folder. After the data store is in place, it is time to start adding users to the data store. Using the CreateUserWizard Server Control The CreateUserWizard server control is one that can be used in conjunction with the membership service. You can find this and the other controls mentioned in this chapter under the Login section in the Visual Studio 2008 Toolbox. The CreateUserWizard control enables you to plug registered users into your data store for later retrieval. If a page in your application allows end users to register for your site, you want, at a minimum, to retrieve a login and password from the user and place these values in the data store. This enables the end user to access these items later to log in to the application using the membership system. To make your life as simple as possible, the CreateUserWizard control takes complete control of registration on your behalf. Listing 16-3 shows a simple use of the control. 761 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 762 Chapter 16: Membership and Role Management Listing 16-3: Allowing end users to register with the site < %@ Page Language="VB" % > < html xmlns="http://www.w3.org/1999/xhtml" > < head runat="server" > < title > Creating Users < /title > < /head > < body > < form id="form1" runat="server" > < asp:CreateUserWizard ID="CreateUserWizard1" Runat="server" BorderWidth="1px" BorderColor="#FFDFAD" BorderStyle="Solid" BackColor="#FFFBD6" Font-Names="Verdana" > < TitleTextStyle Font-Bold="True" BackColor="#990000" ForeColor="White" >< /TitleTextStyle > < /asp:CreateUserWizard > < /form > < /body > < /html > This page simply uses the CreateUserWizard control and nothing more. This one control enables you to register end users for your Web application. This particular CreateUserWizard control has a little style applied to it, but this control can be as simple as: < asp:CreateUserWizard ID="CreateUserWizard1" Runat="server" > < /asp:CreateUserWizard > When this code is run, an end user is presented with the form shown in Figure 16-2. Figure 16-2 This screenshot shows the form as it would appear when filled out by the end user and includes informa- tion such as the username, password, e-mail address, as well as a security question-and-answer section. Clicking the Create User button places this defined user information into the data store. 762 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 763 Chapter 16: Membership and Role Management The username and password provided via this control enable the end user to log in to the application later through the Login server control. A Confirm Password text box is also included in the form of the CreateUser server control to ensure that the passwordprovidedisspelledcorrectly.Ane-mailaddress text box is included (in case end users forget their login credentials and want the credentials e-mailed to them at some later point in time). Then finally, the security question and answer are used to verify the identity of the end user before any credentials or user information is changed or later provided via the browser. After the Create User button on this form is clicked, the end user is presented with a confirmation of the information being stored (see Figure 16-3). Figure 16-3 Seeing Where Users Are Stored Now that the CreateUserWizard control has been used to add a user to the membership service, look at where this information is stored. If you used Visual Studio to create the Microsoft SQL Server Express Edition file in which you want to store the user information, the file is created when the previous example is run and you complete the form process as shown in the preceding figures. When the example is run and completed, you can click the Refresh button in the Solution Explorer to find the ASPNETDB.mdf file, whichislocatedinthe App_Data folder of your project. Many different tables are included in this file, but you are interested in the aspnet_Membership table only. When you open the aspnet_Membership table (by right-clicking the table in the Server Explorer and selecting Show Table Data), the users you entered are in the system. This is illustrated in Figure 16-4. The user password in this table is not stored as clear text; instead, it is hashed, which is a one way form of encryption that cannot be reversed easily. When a user logs in to an application that is using the ASP.NET 3.5 membership service, his or her password is immediately hashed and then compared to the hashed password stored in the database. If the two hashed strings do not compare, the passwords 763 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 764 Chapter 16: Membership and Role Management are not considered a match. Storing clear text passwords is considered a security risk, so you should never do so without weighing the risk involved. Figure 16-4 A note regarding the passwords used in ASP.NET 3.5: If you are having difficulty entering users because of a password error, it might be because ASP.NET requires strong passwords by default. All passwords input into the system must be at least seven characters, and contain at least one non-alphanumeric char- acter (such as [] , ! , @ , # ,or $ ). Whew! An example password of this combination is: Bevjen7777$ Although this type of password is a heck of a lot more secure, a password like this is sometimes difficult to remember. You can actually change the behavior of the membership provider so that it doesn’t require such difficult passwords by reworking the membership provider in the web.config file, as illustrated in Listing 16-4. Listing 16-4: Modifying the membership provider in web.config < configuration > < system.web > 764 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 765 Chapter 16: Membership and Role Management < membership > < providers > < clear / > < add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="LocalSqlServer" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" passwordFormat="Hashed" minRequiredNonalphanumericCharacters="0" minRequiredPasswordLength="3" / > < /providers > < /membership > < /system.web > < /configuration > In this example, you have reworked the membership provider for SQL Server so that it does not actually require any non-alphanumeric characters and allows passwords as small as three characters in length. You do this by using the minRequiredNonalphanumericCharacters and minRequiredPasswordLength attributes. With these in place, you can now create users with these password rules as set forth in these configuration settings. Modifying the membership provider is covered in more detail later in this chapter. Working with the CreateUserWizard Control When you work with the CreateUserWizard control, be aware of the ContinueButtonClick() and the CreatedUser() events. The ContinueButtonClick() event is triggered when the Continue button on the second page is clicked after the user has been successfully created (see Listing 16-5). Listing 16-5: The ContinueButtonClick event VB Protected Sub CreateUserWizard1_ContinueButtonClick(ByVal sender As Object, _ ByVal e As System.EventArgs) Response.Redirect("Default.aspx") End Sub C# protected void CreateUserWizard1_ContinueButtonClick(object sender, EventArgs e) { Response.Redirect("Default.aspx"); } In this example, after the user has been added to the membership service through the form provided by the CreateUserWizard control, she can click the Continue button to be redirected to another page in the application. This is done with a simple Response.Redirect statement. Remember when you use this event, that you must add an OnContinueButtonClick = "CreateUserWizard1_ContinueButtonClick" to the < asp:CreateUserWizard > control. The CreatingUser() event is triggered when a user is successfully created in the data store. The use of this event is shown in Listing 16-6. 765 Evjen c16.tex V2 - 01/28/2008 2:51pm Page 766 Chapter 16: Membership and Role Management Listing 16-6: The CreateUser event VB Protected Sub CreateUserWizard1_CreatingUser(ByVal sender As Object, _ ByVal e As System.EventArgs) ’ Code here End Sub C# protected void CreateUserWizard1_CreatingUser(object sender, EventArgs e) { // Code here } Use this event if you want to take any additional actions when a user is registered to the service. Incorporating Personalization Properties in the Registration Process As you saw in the previous chapter on personalization, it is fairly simple to use the personalization management system that comes with ASP.NET 3.5 and store user-specific details. The registration process provided by the CreateUserWizard control is an ideal spot to retrieve this information from the user to store directly in the personalization system. The retrieval is not too difficult to incorporate into your code. The first step, as you learned in the previous chapter on personalization, is to have some personalization points defined in the application’s web.config file. This is shown in Listing 16-7. Listing 16-7: Creating personalization properties in the web.config file < configuration > < system.web > < profile > < properties > < add name="FirstName" / > < add name="LastName" / > < add name="LastVisited" / > < add name="Age" / > < add name="Member" / > < /properties > < /profile > < /system.web > < /configuration > Now that these properties are defined in the web.config file, you can use them when you create users in the ASP.NET membership system. Again, using the CreateUserWizard control, you can create a process that requires the user to enter his preferred username and password in the first step, and then the second step asks for these custom-defined personalization points. Listing 16-8 shows a CreateUserWizard control that incorporates this idea. 766 . Authorization is provided in ASP. NET 3. 5 using a role management service. ASP. NET 3. 5 Authentication ASP. NET 3. 5 provides the membership management service to deal with authenticating users to access a. are included in this file, but you are interested in the aspnet_Membership table only. When you open the aspnet_Membership table (by right-clicking the table in the Server Explorer and selecting. weighing the risk involved. Figure 16-4 A note regarding the passwords used in ASP. NET 3. 5: If you are having difficulty entering users because of a password error, it might be because ASP. NET