Authenticating Users on a Website

---

Many applications that you build will need to identify the user connecting to the web server. This is necessary to protect the parts of the application and to find out who the user is for logging and authorization purposes. There are many ways of authenticating users with an IIS server, and each method has its strengths and weaknesses depending on the security level that you require.

Design Scenario: Designing for Minimum Services with IIS

You have installed an IIS server in the perimeter network of Wonder, Inc. It will host the company’s e-commerce website and a sales application through which the direct sales staff in the field can verify customer orders and specifications. The e-commerce application is written in ASP and the direct sales application is written in ASP.NET. The CIO is concerned about security. The application is updated using FTP, which is started only when the application is updated. Content updates need to be secure. The server needs to support sending e-mail notifications.

1. Question: What application server components should you install on the server? Answer: World Wide Web Publishing, File Transfer Protocol, Simple Mail Transfer Protocol, ASP.NET, IPSec.

2. Question: What Web Service Extensions should you enable for the e-commerce website? Answer: ASP.

3. Question: What Web Service Extensions should you enable for the sales support website? Answer: ASP.NET.

You will have the ability to let a Windows domain controller authenticate the user with basic, digest, anonymous, .NET Passport or integrated Windows authentication. You can also use certificate authentication or other servers to authenticate your users through ASP.NET forms-based authentication or RADIUS.

Using Internet Information Server Authentication

IIS supports five main authentication mechanisms for authenticating users coming to a website:

• Anonymous access

• Integrated Windows authentication

• Digest authentication for Windows domain servers

• Basic authentication

• .NET Passport authentication

All of these authentication methods can be set in the Authentication Methods dialog box, as see in Figure 7.3. To open this dialog box, open the website’s Properties dialog box, click the Directory Security tab, and click the Edit button in the Authentication Methods section.

Figure 7.3: Setting authentication mechanisms in the Authentication Methods dialog box

The default configuration is anonymous access and integrated Windows authentication.

Using Anonymous Access

It can be a difficult problem to authenticate large numbers of users on the Internet. Many web applications don’t require knowing who the user is because their purpose is to disseminate information and not differentiate between users. Even though these users don’t “authenticate” with the web server, they still need to get access to resources on the server. Every user who connects to an IIS server must exist in some security context. When a user connects to IIS through anonymous access, they are authenticated as the IUSR_ServerName account by default, where ServerName is the name of your IIS server.

You will typically use anonymous access when you set up a web server to serve the public on the Internet. The Internet anonymous user is the default authentication for users, so if it is enabled, all of the other authentication mechanisms will be ignored unless you deny access to the anonymous user account (by default this account is IUSR_computer name).

You can configure the account and password that will be used for everyone that will connect to the web server via anonymous access.

Using Basic Authentication

Basic authentication allows clients to authenticate with the domain or local server using a username and password. The main problem with basic authentication is that it sends the passwords over the network in the clear text. This means that anyone with access to any network that the password crosses over will potentially be able to view the credentials. As you can see, an attacker could then use the captured credentials to impersonate you.

You would use basic authentication to provide a client authentication mechanism that supports the greatest number of browsers. You would need to use an encryption mechanism like SSL or IPSec to guard against password theft.

Using Digest Authentication for Windows Domain Servers

Digest authentication provides support for encrypting passwords, even over an unencrypted connection. Digest authentication hashes the user credentials using the Message Digest 5 (MD5) algorithm. This will prevent someone who intercepts the credentials from reading the password. IIS 6 supports advanced digest authentication, in which the password is pre-hashed and stored in Active Directory. This eliminates the need to store the passwords with reversible encryption in Active Directory when using digest authentication as you had to in the past.

You would use digest authentication in situations in which you need to authenticate users with a mechanism that supports most HTTP 1.1–compliant web browsers and you don’t want to use an encryption mechanism like SSL (usually due to unacceptable overhead or expense). It provides a reasonably secure way to protect the password. Digest authentication requires Active Directory on Windows Server 2003 and is evaluated before basic authentication if you had both enabled.

Using Integrated Windows Authentication

Integrated Windows authentication uses the mechanism that Windows uses to authenticate computers and users in a domain. The client will not present the user with a logon dialog; it sends the logon credentials that it used when the user logged on to their Windows operating system. It will either use the NTLM protocol for authentication or Kerberos v5, depending on the client operating system. If you are using Windows 2000 or greater, Kerberos v5 will be used. Otherwise, the client will use NTLM authentication.

These protocols do not require encryption because they have mechanisms to guard against the credentials being captured. Integrated Windows authentication requires the use of Internet Explorer, so it tends to work best on intranets where the user won’t need to log on to the server and will be using Internet Explorer. This mechanism will be evaluated before basic authentication.

Using Microsoft .NET Passport Authentication

Microsoft .NET Passport authentication is an authentication method that doesn’t require the user to have their credential checked directly. The credentials are not sent to the IIS server; they are sent to a .NET Passport web service over SSL. If the credentials are correct, a cookie that contains a valid ticket will be written to the client. The server will check for a cookie that contains a Passport authentication ticket. If the cookie contains valid credentials, the server will authenticate the user. If the ticket is not valid, the client is redirected to the Passport Logon Service. Upon successful authentication, the client is redirected back to the original URL.

You would use .NET Passport authentication on sites that need to participate in a single logon for the Internet. This would allow the user to manage their information in a single place.

In the Design Scenario “Designing an Authentication Strategy with IIS Authentication,” you will decide on an authentication strategy for IIS.

Design Scenario: Designing an Authentication Strategy with IIS Authentication

Wonder, Inc. has created a new web application that will be used in the corporate network to provide reports on the company’s store activity and the effectiveness of the sales staff. Much of the information is confidential and the CIO wants to make sure that it is available only to authenticated users. All computers are running Windows XP and the employees use Internet Explorer.

1. Question: What should you do to confi gure the server? Answer: You should disable anonymous access and mak e sure that integrated Windows authentication is enabled. Also, apply the proper permissions on the directories and files in the web application.

Using Forms-Based Authentication

Web applications can also take advantage of ASP.NET forms-based authentication to provide for custom authentication of users. The developer would need to create a page to capture the profile information of the user and a page to capture the username and password. You would then need to configure the ASP.NET application to support forms-based authentication.

You specify the web page to redirect the user to if they have not successfully authenticated. This is handled in the web.config file that is located in the ASP.NET web application’s directory. The web.config is an Extensible Markup Language (XML) file that is used to configure an ASP.NET application. The settings in the web.config file will override the settings configured in IIS for the application. This makes it easier for developers to deploy the application. There is a tag in the web.config file that is called <authorization>.

In order to use forms-based authentication, you will need to determine which parts or pages of the application will require authentication. You will use the <authorization> tag in the web.config file to deny or allow users to access parts of the application as follows:

 <location path="AdminPage.aspx">  <system.web>     <authorization>        <deny users="?"/>     </authorization>  </system.web>  </location> 

This section taken from a web.config file is denying the anonymous user, represented by the question mark, access to the AdminPage.aspx page. This will force the user to authenticate when trying to access the AdminPage.aspx page. ASP.NET will look at the authentication tag to determine what method to use for authentication. You would set the authentication tag to the following to use forms-based authentication:

   <system.web>    <authentication mode="Forms">    <forms name="MyAppAuth" loginUrl="login.aspx" protection="All" path="/"/>    </authentication>    </system.web> 

This will set the authentication mode to Forms and then specify the page to handle the logon as login.aspx. The user will be redirected to the login.aspx page if they do not have a valid authentication token in the cookie. The developer would then provide the code to test the credentials and either redirect the user to the page they originally requested or redirect them back to the login.aspx page for another try.

Forms-based authentication provides the best integration into the look and feel of the website because its authentication and account maintenance are done through web pages that are part of the website. It also provides the greatest flexibility in the data sources against which the users are authenticated. The user accounts can be contained in anything from an XML file to a SQL Server or Oracle database to Active Directory. The problem is that a developer will need to write code that will authenticate the user against the data source, so this option is not readily available to administrators.

In the Design Scenario “Designing an Authentication Strategy with Forms-Based Authentication,” you will decide on a forms-based authentication mechanism.

Using Certificate Authentication

Certificate authentication allows users to authenticate with the IIS server using a digital certificate. The certificate can be obtained from a third-party certificate vendor or from your own public key infrastructure (PKI). The client certificate validation is a feature of SSL. Just remember that certificate authentication can not be used if SSL is not enabled.

Design Scenario: Designing an Authentication Strategy with Forms-Based Authentication

Wonder’s developers have created a new application for the Internet site that will allow the user to register. This will allow the marketing department to collect information and suggestions from customers. The customer will also need to register on the site to purchase products. As a convenience to the user, you will allow them to log in and not have to reenter their information again.

1. Question: What authentication mechanism should you recommend that the developers use? Answer: Create a web page that allows the user to register their information, and then create a form to capture logon information. Next, confi gure the ASP.NET application to use forms-based authentication that uses this form. The developers would provide the code to store and authenticate the user with information in a SQL Server database.

Certificates are extremely difficult to forge and are appropriate for extranet applications or situations in which you require stronger security than just a user ID and password. You will need to configure the website to accept client certificates or require client certificates to be able to enable client certificates through the Secure Communications dialog box, shown in Figure 7.4.

Figure 7.4: Requiring client certificates to access the website

You can access the Secure Communications dialog box by opening the Properties dialog box for the website and choosing the Directory Security tab. On the Directory Service tab, click the Edit button in the Secure Communications section. This option will be grayed out unless you have installed a server certificate on the web server.

Note

See Chapter 6, “Designing a Public Key Infrastructure with Certificate Services,” for more information on server certificates and SSL.

Client certificates can be mapped to user accounts to control access to resources based on certificates (technically, you control access through the account mapped to the certificate). You can use a one-to-one mapping, where you have one certificate mapped to one account. Or you can create a many-to-one mapping that is based on a rule that will match the certificate to a user account. This means that more than one certificate can be associated with a single user account or with a few. You can configure the account mappings through the Account Mappings dialog box shown in Figure 7.5 by clicking on the Edit button under the Enable Client Certificate Mappings check box on the Secure Communications dialog box.

Figure 7.5: Mapping your certification using the Account Mappings dialog box

You can also control which root certificate authority (CA) servers you trust. If the client certificates don’t come from a trusted root CA, they will be rejected. This will allow you to trust only your company’s and partner company’s root CAs.

In the Design Scenario “Designing an Authentication Strategy with Certificate Authentication,” you will design an authentication strategy using certificates.

Using RADIUS Authentication

You can control access to an IIS server from a remote connection through Remote Authentication Dial-in User Service (RADIUS). RADIUS authentication allows the RADIUS client to authenticate against a RADIUS server and has become the standard for integrating various vendors’ products. RADIUS is typically used by Routing and Remote Access Services (RRAS) to authenticate, authorize, and audit logon requests in a standard way. Microsoft calls its RADIUS server Internet Authentication Service (IAS), and it can be configured either as an end point for the RADIUS client or to forward authentication, authorization, and accounting traffic to another RADIUS server.

Design Scenario: Designing an Authentication Strategy with Certificate Authentication

Wonder, Inc. has ventured into a partnership with Elektronics R Us to produce a complicated component for a customer. It needs to coordinate communication and various other aspects of the project closely. The CIO wants a secure solution for use over the Internet. Wonder, Inc. has a PKI. Due to firewall issues, the protocol should work over HTTP or HTTPS.

1. Question: What should you recommend for authenticating users? Answer: Certificate authentication with a one-to-many mapping to Windows user accounts would work over SSL and provide a great deal of security. This mechanism would work well because Wonder has a PKI.

IAS can act as an end point to authenticate and authorize requests from the RADIUS client against the Active Directory. The client will connect to the RRAS server and request that it authenticate. The RRAS server, configured as a RADIUS client, will forward the request to the IAS server. The IAS server is installed on a domain controller and will use the Active Directory to attempt to authenticate the user. If successful, it will notify the RADIUS client (RRAS server) and the account will be allowed on the network.

An IAS server configured to forward RADIUS traffic to another server is called IAS proxy. This is most useful when the RRAS and RADIUS infrastructures are maintained by different organizations or where the authentication database (Active Directory) is not directly accessible because the IAS server is located in a perimeter network. You create rules in the Connection Request Policies section of the IAS MMC snap-in. These rules control how the request will be processed and handled.

You can use RADIUS to manage the accounts of users that connect over a VPN through an RRAS server, so it is usually appropriate with partner organizations. Its main benefit is that it provides a standard way to authenticate, authorize, and audit logons, so both organizations don’t need to be using the same vendors for their network infrastructure or operating systems. It also will ease management of duplicating accounts on IIS or in your organization because you can configure IAS to forward RADIUS traffic to the partner organization to verify the account.

In the Design Scenario “Designing an Authentication Strategy with RADIUS,” you will determine the authentication strategy for Wonder, Inc.

---