Section 11.1. Authentication
Authentication is the process of ensuring that clients are who they claim to be. Authentication is accomplished using credentials , or some form of identification. The requesting client presents the credentials to IIS and the ASP.NET application, usually in the form of a username and password.
The credentials are validated against some authority. Depending on how authentication is configured, that authority might be Windows 2000/XP/2003 security, or it might be a store of names , passwords, and rights maintained in a configuration file such as web.config , a relational database such as SQL Server, or an XML file.
Authentication is not required. If no authentication is performed, then the client will be an anonymous user . By default, all web sites allow anonymous access . However, if you need to restrict access to any part of the web site, authentication is a necessary step.
If the system cannot identify a user based on the credentials presented and if anonymous users are disallowed , then access will be denied . If the system can identify the user, then that user will be considered an authenticated identity and allowed to proceed on to authorization. Sometimes the identity is known as a principal .
Authentication is provided through code modules called authentication providers . Authentication providers are enabled using the ASP.NET configuration files, either machine.config or the copy of web.config in the application virtual root directory. (For a complete description of the configuration files, see Chapter 18.)
A typical entry in a configuration file to enable authentication would look like the following:
<configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration>
The mode attribute determines which authentication provider is used. There are four possible values for the mode attribute, as shown in Table 11-1. Each of these authentication modes will be described in the following sections.
Table 11-1. Values of the Authentication key's mode attribute
| Mode value | Description |
|---|---|
| None | No authentication will be performed. Enables anonymous access. |
| Windows | Windows authentication will be used in conjunction with IIS. This is the default. |
| Passport | Centralized commercial authentication service offered by Microsoft to web site developers, providing single logon across web sites. |
| Forms | Unauthenticated requests are redirected to a web page that gathers credentials from the user and submits them to the application for authentication. |
11.1.1. Anonymous Access
Anonymous access occurs when a web application does not need to know the identity of users. In this case, credentials are not requested by IIS, and authentication is not performed. Allowing anonymous access is the default configuration for web sites.
To configure IIS to disable anonymous authentication, use the Computer Management console or the Internet Services console. Click Start 
Settings Control Panel Administrative Tools. Now you have a choice of two ways to get to the same place. Click on Internet Services Manager or Computer Management.
From either, you get the Microsoft Management Console (MMC) , which is used throughout Windows for displaying and controlling many system functions. In the left pane is a hierarchical tree structure showing resources relevant to the aspect(s) of the computer being managed. The right pane contains the child nodes of the currently selected node on the left.
From Computer Management, select Services and Applications in the left-hand pane, then drill down to IIS, then Web Sites, then Default Web Site. From Internet Services Manager go directly to IIS, then Web Sites, then Default Web Site. At this point, you can right-click on Default Web Site to set the properties for the entire server (that is, all the web applications on the server), or you can drill down further to the application virtual directory to set the properties for a specific application. In either case, right-clicking will present a menu, from which you select Properties. Select the Directory Security tab. This tab is shown in Figure 11-2.
Figure 11-2. ASPNet Directory Security tab
The Directory Security tab has sections for enabling server certificates and imposing restrictions based on Internet Protocol (IP) address and domain name . (This latter section will be available only for Windows 2000 Server and Windows 2003 and will be grayed out for Windows 2000 Professional and Windows XP Professional.)
Click the Edit button in the "Anonymous access and authentication control" section. You will get the dialog box shown in Figure 11-3.
Figure 11-3. Authentication Methods dialog box
If the "Anonymous access" checkbox is checked, then any request will be accepted by IIS without credentials being requested by IIS and with no authentication performed. This is the default configuration for web sites.
Since all requests made to IIS must have credentials, anonymous requests are assigned to a standard user account. This account defaults to IUSR_MachineName , where MachineName is the name of the web server. You can change the account assigned to anonymous access by clicking on the Edit button in that section. The IUSR_MachineName account is a built-in account, created when IIS is installed on the machine. It has a limited set of permissions, just enough to allow access to the web site.
Anonymous access is appropriate if your application has no need to know the username or password of the person or application calling on the application, and if the information or service contained in the application is considered public. It is also possible to personalize a site without requiring login through the use of cookies. This would be useful where the content on the site is public, but you want to preserve user preferences or previous selections.
Of all the security configurations available to a web site, anonymous access provides the best performance but is the least secure.
11.1.2. Windows Authentication
Windows authentication offers the developer a way to leverage the security built into the Windows 2000/XP/2003 platform and the NTFS filesystem. It takes advantage of the security built into IIS. Using Windows authentication, a high level of security can be built into an ASP.NET application with little or no code being written by the developer. The trade-off is that Windows authentication only works if the client is using a Windows platform and has a user account on the web server or in the Windows domain to which the web server belongs.
To configure IIS for Windows authentication, follow the steps above for configuring IIS for anonymous access, shown in Figures 11-2 and 11-3. Uncheck the "Anonymous access" checkbox. Check one or more of the checkboxes under "Authenticated access". There are three types of Windows authentication: basic, digest, and integrated Windows authentication. These are described in the following sections.
If more than one type of authentication access is checked, IIS will first attempt to use Integrated Windows authentication if it is checked. If that fails, it will attempt Digest authentication if that is checked. Finally, if all else fails, it will use Basic authentication .
To use the Windows identity that IIS authenticates with ASP.NET, you must include the following section in the appropriate web.config configuration file:
<configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration>
11.1.2.1. Basic authentication
Basic authentication is the simplest and least secure type of Windows authentication. In this type of authentication, the browser presents a standard Windows-supplied dialog box for the user to enter his credentials, consisting of a username and password. These credentials are compared against valid user accounts on the domain server or on the local machine. If the credentials match, the user will be authenticated and access to the requested resource will be provided.
The reason that basic authentication is the least secure method of authentication is that the username and password are sent to the server encoded as a Base64 string . However, they are not encrypted. The username and password are available to your application code in clear text. A skilled person using a network sniffer can easily intercept and extract the username and password. Therefore, basic authentication is best suited for those applications where a high level of security is not a requirement, or no other authentication method will work.
You can use basic authentication in conjunction with Secure Sockets Layer (SSL) to achieve a high level of security. This encrypts the information passed over the network and prevents the password from being deciphered, though the performance hit from SSL is significant.
To set the authentication method to Basic, refer back to Figure 11-3. Uncheck "Anonymous access", "Digest authentication ", and "Integrated Windows authentication" if any of them is checked. Then check "Basic authentication ". That is all that is necessary to implement basic authentication in IIS. To configure ASP.NET, include the following section in the relevant web.config configuration file:
<configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration>
By default, the local domain of the web server is active and is used for basic authentication. If you wish to authenticate against a different domain, click the Edit button and select a different default domain.
Basic authentication works across proxy servers and through firewalls . It is supported by essentially all browsers. Basic authentication allows for delegation from one computer to another but only for a single hop, i.e., only to one other computer. If you need to access resources beyond the first hop, you will need to log on locally to each of the other computers in the call chain. This is possible since the username and password are available to your application in clear text.
11.1.2.2. Digest authentication
Digest authentication is similar to basic authentication, except that the credentials are encrypted and a hash is sent over the network to the server. It is a fairly secure method of authentication though not as secure as basic authentication used with SSL, Windows integrated authentication, or certificate authentication. Like basic authentication, digest works through firewalls and proxy servers. Digest authentication does not support delegation, i.e., impersonated requests to remote machines.
Digest authentication works only with Internet Explorer 5.x and higher and .NET web services. It requires that the web server is running on Windows 2000, XP, or Server 2003 and that all users have Windows accounts stored in an Active Directory. Because of these requirements, digest authentication is generally limited to intranet applications.
When the user requests a resource that requires digest authentication, the browser presents the same credentials dialog box as with basic authentication. The username and password are combined with a server-specified string value and encrypted to a hash value. This hash value is sent over the network. Since the server knows the string used to create the hash, it is able to decrypt the hash and extract the username and password. These are compared with the user accounts to determine if the user is authenticated, and if so, if the user has permission to access the requested resource.
To set the authentication method to Digest, refer back to Figure 11-3. Uncheck "Anonymous access", "Basic authentication", and "Integrated Windows authentication " if any of them are checked. Then check "Digest authentication". The Digest authentication checkbox will be unavailable if the machine is unconnected to a domain.
In addition, to configure ASP.NET you must include the following section in the relevant web.config configuration file:
<configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration>
For a user to be able to use digest authentication, the user account must be set to store the password using reversible encryption. To do this, go to the management console for Active Directory Users and Computers on the domain controller. Open the domain you want to administer and double-click on the username that you want to use digest authentication. On the Account Options tab, select "Store password using reversible encryption ".
11.1.2.3. Integrated Windows authentication
Integrated Windows authentication uses the current users' credentials presented at the time they logged into Windows. A dialog box is never presented to the user to gather credentials unless the Windows logon credentials are inadequate for a requested resource.
Integrated Windows authentication comprises two different types of authentication: NT LAN Manager (NTLM) challenge/response, and Kerberos. NTLM is the protocol used in Windows NT, Windows 2000 work groups, and environments with mixed NT and 2000 domains. If the environment is a pure Windows 2000 or Windows XP Active Directory domain, then NTLM is automatically disabled and the authentication protocol switches to Kerberos.
|
Integrated Windows authentication works well in intranet environments, where all the users have Windows domain accounts and presumably all users are using IE 3.01 or later. It is secure since the encrypted password is not sent over the network. Integrated Windows authentication does not work through a proxy server. NTLM does not support delegation though Kerberos does.
Integrated Windows authentication does not require any login dialog boxes. This is more convenient for the user and is well suited to automated applications, such as those using web services.
To set the authentication method to Integrated Windows authentication, refer back to Figure 11-3. Uncheck "Anonymous access", "Basic authentication", and "Digest authentication" if any of them are checked. Then check "Integrated Windows authentication".
In addition, to configure ASP.NET, you must include the following section in the relevant web.config configuration file:
<configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration>
Kerberos is faster than NTLM though neither is as fast as basic authentication or well-designed custom authentication methods. If you are anticipating a large number of concurrent users or are delegating security to back-end servers (such as SQL Server), then scalability may become an issue with Integrated Windows Authentication.
11.1.2.4. Role-based security
Windows 2000/XP/2003 also provides role-based security . In this security scheme, roles , also known as groups , are defined. A role defines the range of actions and access that is permitted to users assigned to the role. Users are assigned to one or more roles, or groups. For example, if a user is a member of the Administrator role , then that person will have complete access to the computer and all its resources. If a user is a member only of the Guest group , then he will have very few permissions.
Groups and users are assigned by going to Control Panel, clicking on Administrative Tools, and then clicking on Computer Management. You will see the MMC console shown in Figure 11-4.
All the groups shown in Figure 11-4 were installed by default.
Figure 11-4. Groups in the Computer Management console
Windows users log in to the operating system, providing a username and password. These constitute their credentials . At login time, those credentials are authenticated by the operating system. Once their credentials are verified , they will have certain permissions assigned, depending on which role(s) they have been assigned. As you will see, these credentials and roles are used by ASP.NET if the web application makes use of Windows authentication.
When a client requests an ASP.NET page or web service, all the requests are handled by IIS. If Windows authentication is the currently configured authentication scheme, then IIS will hand off the authentication chores to the Windows NT, Windows 2000, or Windows XP operating system. The user is authenticated based on the credentials that were presented when they first logged into their Windows system. These credentials are verified against the Windows user accounts contained on the web server or on the domain controller that handles the web server.
11.1.3. Passport Authentication
Passport is a centralized authentication service provided by Microsoft. It offers a single logon for all web sites that have registered with the Passport service, accepted the license agreement, paid the requisite fee, and installed the Passport SDK.
When a client makes a request to a Passport protected site, the server detects that the request does not contain a valid Passport ticket as part of the query string. The client is redirected to the Passport Logon Service along with encrypted parameters about the original request. The Passport Logon Service presents the client with a logon form, which the user fills out and posts back to the logon server using the SSL protocol. If the logon server authenticates the user, the request is redirected back to the original site, this time with the authentication ticket encrypted in the query string. When the original site receives this new request, it detects the authentication ticket and authenticates the request.
Subsequent requests to the same site are authenticated using the same authentication ticket. Provisions exist for expiring the authentication ticket and for using the same ticket at other sites.
For sites that have implemented Passport and installed the Passport SDK, the PassportAuthenticationModule provides a wrapper around the SDK for ASP.NET applications.
Passport uses Triple-DES encryption to encrypt and decrypt the authentication key when passed as part of the query string. When a site registers with the Passport service, it is given a site-specific key that is used for this encryption and decryption.
Using delegation is impossible if you are using Passport authentication.
To use Passport authentication, ASP.NET must be configured by including the following section in the relevant web.config configuration file:
<configuration> <system.web> <authentication mode="Passport" /> </system.web> </configuration>
11.1.4. Forms Authentication
Integrated Windows authentication offers many advantages to the developer who is deploying to an environment where all the clients are known to have user accounts in the requisite Windows domain or Active Directory and are known to be using a recent version of Internet Explorer. However, in many web applications, one or both of these conditions will not be true. In these cases, forms authentication allows the developer to collect credentials from the client and authenticate them.
In forms authentication , a login form is presented to the user to gather credentials. This form does not necessarily authenticate the user, but submits the credentials, via form post, to application code that performs the authentication. The application code generally authenticates by comparing the credentials submitted with usernames and passwords contained in a data store of some sort . ASP.NET 2.0 does most of the work of setting up the database to support Forms Authentication as described below.
The credentials submitted by the login form are sent unencrypted over the network and are vulnerable to interception by a skilled and malicious user of a network sniffer. A forms authentication scheme can be made fully secure by sending the credentials and all subsequent authenticated requests using the SSL protocol.
Once the client is authenticated, the server returns a small piece of data, called a cookie , back to the client. This authentication cookie is then passed from the client to the server on each subsequent request, which tells the server that this client has been authenticated. If a request is made without a valid authentication cookie, then the user will be automatically redirected to the login form, where credentials are again gathered and authenticated.
EAN: 2147483647
Pages: 173