Evjen c21.tex V2 - 01/28/2008 3:15pm Page 998 Chapter 21: Security As you can see, a couple of methods are at your disposal for building an authentication/authorization model for your ASP.NET applications. We start by examining the Windows mode of authentication. Windows-Based Authentication Windows-based authentication is handled between the Windows server where the ASP.NET a pplica- tion resides and the client machine. In a Windows-based authentication model, the requests go directly to IIS to provide the authentication process. This type of authentication is quite useful in an intranet environment where you can let the server deal completely with the authentication process — especially in environments where users are already logged onto a network. In this scenario, you simply grab and utilize the credentials that are already in place for the authorization process. IIS first takes the user’s credentials from the domain login. If this process fails, IIS displays a pop-up dialog box so the user can enter or re-enter his login information. To set up your ASP.NET application to work with Windows-based authentication, begin by creating some users and groups. Creating Users You use aspects of Windows-based authentication to allow specific users who have provided a domain login to access your application or parts of your application. Because it can use this type of authentication, ASP.NET makes it quite easy to work with applications that are deployed in an intranet environment. If a user has logged o nto a local computer as a domain user, he will not need to be authenticated again when accessing a network computer in that domain. The following steps show you how to create a user. It is important to note that you must have sufficient rights to be authorized to create users on a server. If you are authorized, the steps to create users are as follows: 1. Within your Windows XP or Windows Server 2003 server, choose Start ➪ Control Panel ➪ Administrative Tools ➪ Computer Management. If you are using Windows Vista, choose Start ➪ Control Panel ➪ System and Maintenance ➪ Administrative Tools ➪ Computer Man- agement. Either one opens the Computer Management utility. It manages and controls resources on the local Web server. You can accomplish many things using this utility, but the focus here is on the creation of users. 2. Expand the System Tools node. 3. Expand the Local Users and Groups node. 4. Select the Users folder. You see something similar to the results shown in Figure 21-2. 5. Right-click the Users folder and select New User. The New User dialog appears, as shown in Figure 21-3. 6. Give the user a name, password, and description stating that this is a test user. In this example, the user is called Bubbles. 7. Clear the check box that requires the user to change his password at the next login. 8. Click the Create button. Your test user is created and presented in the Users folder of the Computer Management utility, as shown in Figure 21-4. Now create a page to work with this user. 998 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 999 Chapter 21: Security Figure 21-2 Figure 21-3 Authenticating and Authorizing a User Now create an application that enables the user to enter it. You work with the application’s web.config file to control which users are allowed to access the site and which users are not allowed. Add the section presented in Listing 21-1 to your web.config file. 999 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1000 Chapter 21: Security Figure 21-4 Listing 21-1: Denying all users through the web.config file < system.web > < authentication mode="Windows" / > < authorization > < deny users="*" / > < /authorization > < /system.web > In this example, the web.config file is configuring the application to employ Windows-based authentica- tion using the < authentication > element’s mode attribute. In addition, the < authorization > element is used to define specifics about the users or groups who are permitted access to the application. In this case, the < deny > element specifies that all users (even if they are authenticated) are denied access to the application. Not permitting specific users with the < allow > element does not make much sense, but for this example, leave it as it is. The results are illustrated in Figure 21-5. Any end user — authenticated or not — who tries to access the site sees a large ‘‘Access is denied’’ statement in his browser window, which is just what you want for those not allowed to access your application! In most instances, however, you want to allow at least some users to access your application. Use the < allow > element in the web.config file to allow a specific user. Here is the syntax: < allow users="Domain \ Username"/ > Listing 21-2 shows how the user is permitted access. Listing 21-2: Allowing a single user through the web.config file < system.web > < authentication mode="Windows" / > < authorization > 1000 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1001 Chapter 21: Security < allow users="REUTERS-EVJEN \ Bubbles"/ > < deny users="*"/ > < /authorization > < /system.web > Figure 21-5 Even though all users (even authenticated ones) are denied access through the use of the < deny > element, the definitions defined in the < allow > element take precedence. In this example, a single user — Bubbles — is allowed. Now, if you are logged on to the client machine as the user Bubbles and run the page in the browser, you get access to the application. Looking Closely at the < allow > and < deny > Nodes The < allow > and < deny > nodes enable you to work not only with specific users, but also with groups. The elements support the attributes defined in the following table. Attribute Description Users Enables you to specify users by their domain and/or name. Roles Enables you to specify access groups that are allowed or denied access. Verbs Enables you to specify the HTTP transmission method that is allowed or denied access. When using any of these attributes, you can specify all users with the use of the asterisk ( * ): < allow roles="*" / > 1001 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1002 Chapter 21: Security In this example, all roles are allowed access to the application. Another symbol you can use with these attributes is the question mark ( ? ), which represents all anonymous users. For example, if you want to block all anonymous users from your application, use the following construction: < deny users="?" / > When using users , roles ,or verbs attributes with the < allow > or < deny > elements, you can specify multiple entries by separating the values with a comma. If you are going to allow more than one user, you can either separate these users into different elements, as shown here: < allow users="MyDomain \ User1" / > < allow users="MyDomain \ User2" / > or you can use the following: < allow users="MyDomain \ User1, MyDomain \ User2" / > Use the same construction when defining multiple roles and verbs. Authenticating and Authorizing a Group You can define groups of individuals allowed or denied access to your application or the application’s resources. Your server can contain a number of different groups, each of which can have any number of users belonging to it. It is also possible for a single user t o belong to multiple groups. Pull up the Computer Management utility to access the list of the groups defined on the server you are working with. Simply click the Groups folder in the Computer Management utility, and the list of groups is displayed, as illustrated in Figure 21-6. Figure 21-6 1002 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1003 Chapter 21: Security Right-click in the Groups folder to select New Group. The New Group dialog displays (see Figure 21-7). Figure 21-7 To create a group, give it a name and description; then click the Add button and select the users whom you want to be a part of the group. After a group is created, you can allow it access to your application like this: < allow roles="MyGroup"/ > You can use the roles attribute in either the < allow > or < deny > element to work with a group that you have created or with a specific group that already exists. Authenticating and Authorizing an HTTP Transmission Method In addition to authenticating and authorizing specific users or groups of users, you can also authorize or deny requests that come via a specific HTTP transmission protocol. This is done using the verb attribute in the < allow > and < deny > elements. < deny verbs="GET, DEBUG" / > In this example, requests that come in using the HTTP GET or HTTP DEBUG p rotocols are denied access to the site. Possible values for the verbs attribute include POST , GET , HEAD ,and DEBUG . 1003 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1004 Chapter 21: Security Integrated Windows Authentication So far, you have been using the default Integrated Windows authentication mode for the authentication/ authorization process. This is fine if you are working with an intranet application and each of the clients is using Windows, the only system that the authentication method supports. This system of authentication also requires the client to be using Microsoft’s Internet Explorer, which might not always be possible. Integrated Windows authentication was previously known as NTLM or Windows NT Challenge/ Response authentication. This authentication model has the client prove its identity by sending a hash of its credentials to the server that is hosting the ASP.NET application. Along with Microsoft’s Active Directory, a client can also use Kerberos if it is using Microsoft’s Internet Explorer 5 or higher. Basic Authentication Another option is to use Basic authentication, which also requires a username and password from the client for authentication. The big plus about Basic authentication is that it is part of the HTTP specification and therefore is supported by most browsers. The negative aspect of Basic authentication is that it passes the username and password to the server as clear text, meaning that the username and password are quite visible to prying eyes. For this reason, it is important to use Basic authentication along with SSL (Secure Sockets Layer). If you are using IIS 5 or 6, to implement Basic authentication for your application, you must pull up IIS and open the Properties dialog for the Web site you are working with. Select the Directory Security tab and click the Edit button in the Anonymous Access and Authentication Control box. The Authentication Methods dialog box opens. Uncheck the Integrated Windows Authentication check box at the bottom and check the Basic Authen- tication check box above it (see Figure 21-8). When you do, you are warned that this method transmits usernames and passwords as clear text. Figure 21-8 1004 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1005 Chapter 21: Security End by clicking OK in the dialog. Now your application uses Basic authentication instead of Integrated Windows authentication. If you are using Windows Vista, it is not easy to find the option to enable Basic authentication. Instead, you first have to enable IIS 7 to use Basic authentication by selecting Start ➪ Control Panel ➪ Programs ➪ Programs and Features ➪ Turn Windows features on or off. From the provided dialog box, nav- igate to the Internet Information Services section and expand until you arrive at World Wide Web Services ➪ Security. From here, check the Basic Authentication option and press OK to install. This option is presented in Figure 21-9. Figure 21-9 Once this option is installed, you can then return to the Internet Information Services (IIS) Manager and select the Authentication option in the IIS section for the virtual directory you are focusing o n. From there, highlight the Basic Authentication option and select Enable from the Actions pane. This is illustrated in Figure 21-10. Digest Authentication Digest authentication is the final mode you explore in this chapter. The model alleviates the Basic authen- tication problem of passing the client’s credentials as clear text. Instead, Digest authentication uses an algorithm to encrypt the client’s credentials before they are sent to the application server. To use Digest a uthentication, you are required to have a Windows domain controller. One of the main issues that arises with Digest authentication is that it is not supported on all platforms and requires 1005 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1006 Chapter 21: Security Figure 21-10 browsers that conform to the HTTP 1.1 specification. Digest authentication, however, not only works well with firewalls, but it is also compatible with proxy servers. You can select Digest authentication as the choice for your application in the same Authentication Meth- ods dialog — simply select the Digest Authentication check box from the properties dialog if you are using IIS 5 or 6. If you are using IIS 7, you need to install Digest Authentication just as you installed Basic Authentication. Once installed, you will find this option and will be able to enable it from the Authentication section within the IIS Manager. Forms-Based Authentication Forms-based authentication is a popular mode of authenticating users to access an entire application or specific resources within an application. Using it enables you to put the login form directly in the application so that the end user simply enters his username and password into an HTML form contained within the browser itself. One negative aspect of forms-based authentication is that the usernames and passwords are sent as clear text unless you are using SSL. It is easy and relatively straightforward to implement forms-based authentication in your Web applica- tion. To begin with, you make some modifications to your application’s web.config file, as illustrated in Listing 21-3. 1006 Evjen c21.tex V2 - 01/28/2008 3:15pm Page 1007 Chapter 21: Security Listing 21-3: Modifying the web.config file for forms-based authentication < system.web > < authentication mode="Forms" > < forms name="Wrox" loginUrl="Login.aspx" path="/" / > < /authentication > < authorization > < deny users="?" / > < /authorization > < /system.web > You must apply this structure to the web.config file. First, using the < authorization > element described earlier, you are denying access to the application to all anonymous users. Only authenticated users are allowed t o access any page contained within the application. If the requestor is not authenticated, what is defined in the < authentication > element is put into action. The value of the mode attribute is set to Forms to employ forms-based authentication for your Web appli- cation. The next attribute specified is loginUrl , which points to the page that contains the application’s login form. In this example, Login.aspx is specified as a value. If the end user trying to access the appli- cation is not authenticated, his request is redirected to Login.aspx so that the user can be authenticated and authorized to proceed. After valid credentials have been provided, the user is returned to the location in the application where he originally made the request. The final attribute used here is path .Itsimply specifies the location in which to save the cookie used to persist the authorized user’s access token. In most cases, you want to leave the value as / . The following table describes each of the possible attributes for the < forms > element. Attribute Description name This name is assigned to the cookie saved in order to remember the user from request to request. The default value is .ASPXAUTH . loginUrl Specifies the URL to which the request is redirected for login if no valid authentication cookie is found. The default value is Login.aspx . protection Specifies the amount of protection you want to apply to the authentication cookie. The four available settings are: ❑ All : The application uses both data validation and encryp- tion to protect the cookie. This is the default setting. ❑ None : Applies no encryption to the cookie. ❑ Encryption : The cookie is encrypted but data valida- tion is not performed on it. Cookies used in this man- ner might be subject to plain text attacks. ❑ Validation : The opposite of the Encryption setting. Data val- idation is performed, but the cookie is not encrypted. path Specifies the path for cookies issued by the application. In most cases you want to use / , which is the default setting. 1007 . by examining the Windows mode of authentication. Windows-Based Authentication Windows-based authentication is handled between the Windows server where the ASP. NET a pplica- tion resides and the. begin by creating some users and groups. Creating Users You use aspects of Windows-based authentication to allow specific users who have provided a domain login to access your application or parts. the verbs attribute include POST , GET , HEAD ,and DEBUG . 10 03 Evjen c21.tex V2 - 01/28/2008 3: 15pm Page 1004 Chapter 21: Security Integrated Windows Authentication So far, you have been using the default Integrated