Authentication in ASP.NET: .NET Security Guidance

Introduction

Security is a major concern for both application architects and developers. Applications that store sensitive information need to be protected from malicious attacks and from competitors attempting to steal information or intellectual property. When designing a security model for your application, you need to be aware of security requirements from a business perspective and the implications that a chosen security model can have on performance, scalability, and deployment.

Security Considerations

If you are designing a server application, your design specification should contain a section that addresses security issues. You should consider and possibly address the following items in the application's functional specification:

Security goals. Understand what you are securing and make sure that you can describe it.
Security risks. Understand your application's vulnerabilities. You must also understand the significance of potential threats as they relate to your business.
Authentication. This is the process of accepting credentials from a user and validating those credentials against a designated authority. The user's (or potentially an application's or computer's) identity is referred to as a security principal. The client must provide credentials to allow the server to verify the identity of the principal. After the identity is known, the application can authorize the principal to access resources on the system. Various criteria, which help you choose the appropriate authentication mechanism, are presented in the next section of this document.
Authorization. This is the process of determining whether the proven identity is allowed to access a specific resource.
Securing data transmission. By encrypting your data as it crosses the network, you can ensure that it cannot be viewed or tampered with while in transit. You must consider the degree to which your data needs to be secured while in transit.
Impersonation. This mechanism allows a server process to run using the security credentials of the client. When the server is impersonating the client, any operations performed by the server are performed using the client's credentials. Impersonation does not allow the server to access remote resources on behalf of the client. This requires delegation.
Delegation. Like impersonation, delegation allows a server process to run using the security credentials of the client. However, delegation is more powerful and allows the server process to make calls to other computers while acting as the client.
Operating system security. This refers to the establishment of appropriate Access Control Lists (ACLs), and network security to prevent intruders from accessing secured resources. You must set the appropriate ACLs on the appropriate resources to allow access by only the relevant principals.
Securing physical access. This refers to locating your server computer in a secure room. You should not overlook this fundamental issue.
Code access security. This allows code to be trusted to varying degrees depending upon where it has come from and from other aspects of the code's identity. You should be aware of how to create your own access permissions.

Relationship Between IIS and ASP.NET

You should understand the relationship between Internet Information Services (IIS) authentication and the Microsoft® ASP.NET security architecture when designing your application. This will allow you to authenticate your users appropriately and obtain the correct security context within your application. You should note that ASP.NET application security configuration and IIS security configuration are completely independent and can be used independently or in conjunction with each other.

IIS maintains security related configuration settings in the IIS metabase. However, ASP.NET maintains security (and other) configuration settings in XML configuration files. While this generally simplifies the deployment of your application from a security standpoint, the security model adopted by your application will necessitate the correct configuration of both the IIS metabase and your ASP.NET application via its configuration file (Web.config).

Figure 1 illustrates the relationship between IIS and ASP.NET.

Figure 1. The security relationship between IIS and ASP.NET

ASP.NET Authentication Providers and IIS Security

ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:

Forms Authentication. Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
Passport Authentication. This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
Windows Authentication. This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.

To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:

// web.config file
<authentication mode = "[Windows/Forms/Passport/None]">
</authentication>

In addition to authentication, ASP.NET provides an impersonation mechanism to establish the application thread's security token. Obtaining the correct token relies upon you configuring IIS authentication, ASP.NET authentication providers, and ASP.NET impersonation settings appropriately. Figure 2 shows the most likely combinations between IIS authentication and ASP.NET providers.

Figure 2. ASP.NET and IIS security settings matrix

Authentication using Windows accounts

If you plan to authenticate users using accounts maintained by a Microsoft Windows NT® domain controller or within Microsoft Windows® 2000 Active Directory™, you should use IIS Authentication coupled with the Windows Provider for ASP.NET, as illustrated in Figure 2. By using this approach, you do not need to write any specific authentication code. When authentication happens using this method, ASP.NET constructs and attaches a Windows Principal object to the application context based on the authenticated user. As a result, the ASP.NET thread can run as the authenticated user and can obtain the user's group membership.

In some cases, you may want to bypass IIS authentication and implement a custom solution. This is also possible with ASP.NET. For example, you can write a custom ISAPI filter that checks the user's credentials against Active Directory and the creation of the Windows Principal object would be performed manually. There are other methods besides this one that will work, but they all require more code than using the .NET provider directly.

Authentication using non-Windows accounts

If you are planning to authenticate users at the application level, and the users do not have Windows accounts, you will typically configure IIS to use Anonymous authentication. In this configuration, consider the following .NET authentication modules:

None: Use when you are not authenticating users at all, or developing custom authentication code.
Forms: Use when you want to provide users with a logon page.
Passport: Use when you are using Passport services.

Impersonation and delegation

With impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they're operating. Impersonation is usually performed for resource access control. You should carefully consider whether or not impersonation is required, as it consumes additional server resources. Delegation is a more powerful form of impersonation and allows remote resources to be accessed by the server process while acting as the client.

If impersonation is enabled, ASP.NET will receive the token to impersonate from IIS. You have more granular control of impersonation in a Web application when using ASP.NET in comparison to traditional Active Server Pages (ASP). This is controlled by specifying a value in the application's Web.config file.

You have the following three options when specifying the required impersonation setting:

Impersonation enabled. In this instance, ASP.NET will impersonate the token passed to it by IIS, which will either be an authenticated user or the anonymous Internet user account.
```
<identity impersonate="true"/>
```
Impersonation enabled, with a specific impersonation identity specified. In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable, is not used.
```
<identity impersonate="true" name="domain\user" password="pwd"/>
```
Impersonation is disabled. This is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used.
```
<identity impersonate="false"/>
```

If the application resides on a UNC share, ASP.NET will always impersonate the IIS UNC token to access that share unless a configured account is used. If an explicitly configured account is provided, ASP.NET will use that account in preference to the IIS UNC token.

Table 1 shows the thread token ASP.NET uses to execute the request based on three different Web.config configuration settings. Note that the IUSR_SERVER account indicates the account configured for anonymous access for the current URL (that is, this doesn't have to be an IUSR_ account). The process account is the account the application worker process is running as: by default this is the System Account, unless specifically configured.

Table 1. ASP Thread Token for ASP and IIS Configurations

ASP.NET Impersonation	IIS is using Anonymous	IIS is not using Anonymous	Application resides on UNC Share
Disabled	Process Account	Process Account	IIS UNC Token
Enabled	IUSR_SERVER	Authenticated user	IIS UNC Token
Enabled with a specified user "Jeff"	"Jeff"	"Jeff"	"Jeff"

Application identities

You are advised to run the ASP.NET application worker process (aspnet_wp.exe) using a specifically configured account, with weaker privileges than the default System account. This is for two main reasons. Firstly, if security is breached, the intruder does not have administrative access. Secondly, it allows Application Service Providers (ASPs) to run applications using weaker accounts, so hosted applications cannot compromise the integrity of the server computer or perform actions that require administrative privileges.

To run the ASP worker process using a specified account, add a <processModel> element to the root configuration file (machine.config), located in the \WINNT\Microsoft.NET\Framework\Version\Config folder, as shown below:

<system.web>
  <processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

In addition to specifying a particular user account, you can also set the username attribute to one of two specially recognized values, "SYSTEM" and "MACHINE". In both cases, the password attribute must be set to "AutoGenerate", as specific credentials are not required. The "SYSTEM" setting runs the worker process using the System account, while "MACHINE" (which is the default) causes the worker process to run with a special account named with an ASPNET prefix. This account is similar to the IWAM_MACHINENAME account, used by IIS for running instances of dllhost.exe when hosting regular ASP applications. The ASPNET account is created during .NET installation.

If you use a custom account, that account must have the necessary access rights to the following directories.

Read/write access is required to the %installroot%\ASP.NET Temporary Files directory. Sub-directories beneath this root are used for dynamically compiled output.
Read/write access is required to the %temp% directory. This is used by the compilers during dynamic compilation.
Read access is required to the application directory.
Read access is required to the %installroot% hierarchy to allow access to system assemblies.

Note that the relevant ACEs are defined during the installation process for the ASPNET account.

If you use a specifically configured process account, you should be aware of a restriction that this places on the use of impersonation. While you can still impersonate the identity of the client, you can't use the extended form of impersonation where a specified impersonation account is defined within the application's Web.config file. This is because this option requires that the worker process has the SE_TCB_NAME ("Act as part of the operating system") privilege, which the weaker process identity generally won't have. Per request impersonation still works, because IIS creates the logon session and passes the impersonation token directly to the worker process. Note that this restriction only applies to Windows 2000 and Windows NT 4. Microsoft Windows XP contains enhancements that allow specific logon sessions to be generated without requiring this privilege.

For more information, read the following chapters from the .NET Framework Developers Guide:

"How ASP.NET Security Works"
"ASP.NET Authentication"
"ASP.NET Configuration Concepts"
"Using IIS Authentication With ASP.NET Impersonation"

For information about authentication in IIS 5.0, see the article Internet Information Services 5.0 Authentication Methods.

Authentication Methods

You have a variety of options for authentication within your .NET Web applications. For example, you may choose to utilize one of the supported IIS authentication mechanisms, or you may instead decide to perform authentication within your application code. You should consider some or all of the following factors when choosing an authentication method:

Server and client operating systems
The client browser type
The number of users, and the location and type of the user name and password database
Deployment considerations, such as whether your application is Internet or intranet based and whether it is located behind a firewall
The application type; for example, is it an interactive Web site or a non-interactive Web service
Sensitivity of the data you are protecting
Performance and scalability factors
Application authorization requirements; for example, you may want your application to be available to all users, or you may need to restrict certain areas to registered users, and other areas to "administrators only."

Determining an Authentication Method

You can use the flow chart shown in Appendix A to help determine the most appropriate authentication method, based on the requirements of your individual application. To use the chart, answer the questions concerning the nature of the user base and the deployment model. The chart endpoints contain the appropriate candidate authentication methods.

After you examine the flow chart, you should study the following subsections, each of which provide more detailed information about the various authentication methods and provide further guidance that will help you fine tune your decision-making process. At the end of this section, you should be able to select a candidate authentication method.

Explanation of flowchart decision points

Do users have to log in? Is a user name and password required to access the site or service?
Is personalization required? Will the site provide personalized content, without requiring the users to log on?
User Accounts? Are user accounts stored in Windows NT domain accounts, Active Directory, or are they stored in some other data store, for example a relational database, an alternate LDAP (Lightweight Directory Access Protocol) directory service, or an XML file?
Is single sign-on or seamless logon required? Do you want the users to log on from a logon page, or do you need authentication to happen automatically? For example, you may require automatic authentication for an automated Business-to-Business (B2B) transaction.
Do you need a secure logon? Do you need to make the system extremely hard for hackers to steal user names and passwords over the network? This decision is typically made based on the sensitivity of the data available on the site.
Will the application run on the Internet? Will the application be behind a firewall, where users are not authenticated to a domain, or will the application be intranet-based where the end users may already be authenticated to a domain?
Do you need to delegate security context? Do you need business components to run with the caller's identity? If so, impersonation is required. Furthermore, if you need to access system resources such as message queues, databases, or file systems on remote computers, delegate-level impersonation will be required.
Are servers and clients running only Windows 2000? Are you running a homogeneous environment of computers running Windows 2000, or are there clients running other operating systems, such as Windows 9x and Windows NT 4.0?

Anonymous Authentication

With Anonymous authentication, the server does not request the client to send user credentials. It is a good choice when your site or service is publicly available and you do not need to know the identity of the caller. Additionally, there are typically no browser restrictions which stem from incompatibilities with supported authentication mechanisms. When a site is configured for Anonymous authentication, all users are allowed access. It is important to note that although you may have IIS configured for Anonymous authentication, you may be authenticating at the ASP.NET layer, which is not true Anonymous authentication. This section assumes that both IIS and the application do not require a login.

Typical usage scenarios

You should consider Anonymous authentication when:

You do not need to know the name and/or password of the caller for either login or business logic components.
The information you are protecting is considered "public."

You should not consider Anonymous authentication when:

You are restricting your user base to require a login name and password.

Other considerations

You should also consider the following when choosing Anonymous authentication.

Sites containing personalized content only

If you are designing a site that is providing personalized content only, Anonymous authentication may be a good choice. An example of this is a news site that provides local information based on a user's zip code but does not require the user to explicitly log on. The personalization functionality can be performed using cookies separately from authentication. For further information about cookies, see the Cookies section later in this document.

Impersonation

When using Anonymous authentication, the application thread will run as either:

The built-in anonymous Internet account, IUSR_MACHINENAME.
The account configured in IIS for the anonymous user.
The IIS system account.

If your application is using other resources, such as COM+ components, databases, message queues, or UNC file shares, you will need to enable the appropriate permissions for the anonymous user. If this is the case, consider the following options:

Set up a domain controller that includes all of your Web and application servers. Configure the anonymous user to run as a domain user with the appropriate permissions for resource access. This method will give you easier manageability because your account management is centralized.
If you are not running in a domain, you can create a user with the same name and password on each of the Web and application servers. This is not recommended due to the complexities with duplicate account management.

Performance

Having an anonymous Web site and not using ASP.NET impersonation will give you the highest performing, but the least secure, application configuration.

Implementation

To implement Anonymous authentication, configure IIS for Anonymous authentication and configure the appropriate anonymous user account. Configure ASP.NET using the Web.config file to use no authentication.

// web.config file
<system.web>
   <authentication mode="None" />
</system.web>

Basic Authentication

When IIS is configured for Basic authentication, it instructs the browser to send the user's credentials over HTTP. Passwords and user names are encoded using Base64 encoding. Although the password is encoded, it is considered insecure due its ability to be deciphered relatively easily. The browser prompts the user with a dialog box, and then reissues the original anonymous request with the supplied credentials, including the user name and password. A pop-up logon dialog box may or may not be appropriate, depending upon your user interface design requirements. Most Internet browsers support Basic authentication.

Typical usage scenarios

You should consider Basic authentication when:

Your users have Windows NT Domain or Active Directory accounts.
You need to support multiple browser types, including Netscape Navigator and all versions of Internet Explorer (including the Pocket PC and Windows CE platforms).
You need to support authentication over the Internet.
You need to access the clear text password in your application code.
You need to support delegation.

You should not consider Basic authentication when:

You require a secure login and are not using a secure channel, such as that provided by Secure Sockets Layer (SSL).
Your users are stored in a custom database, and do not have Windows accounts.
You require a customized form presented to the user as a login page.

Other considerations

You should also consider the following when choosing Basic authentication.

Delegation using Basic authentication

You can delegate from one computer to another (but not beyond) using Basic authentication. Delegation happens because the IIS server will log on the user locally via a call to the Win32 API LogonUser. Because IIS has the clear text password of the user, it can respond to challenges from remote computers, allowing the Web server to act on behalf of the client. If you need to delegate security context to other computers (beyond a single hop), you will have to log on locally to the other computers in the call chain. It is possible to do this using Basic authentication because you have access to the user name and clear text password, which you can pass to other applications such as those based on ISAPI or CGI.

Making Basic authentication secure

It is important to remember that the password can be deciphered relatively easily, so you should limit the use of Basic authentication to non-secure, or at most, semi-secure applications when used by itself.

You can secure Basic authentication by combining it with SSL. This will prevent passwords from being deciphered. This combination of Basic authentication coupled with SSL is used by many Internet applications in production today.

Implementation

To implement Basic authentication, configure it within IIS and make sure that your users have the "log on locally" privilege on the Web server. If your ASP.NET application needs to run as the user authenticated by Basic authentication, use the following Web.config file configuration.

// web.config file
<system.web>
   <authentication mode="Windows" />
</system.web>

Digest Authentication

Digest authentication is new to Windows 2000 and IIS 5.0. This form of authentication encrypts the user's password information and provides a mechanism that helps prevent some common server attacks (such as a replay attack). Digest authentication does not send the credentials over the network using clear text as Basic authentication does. Instead, it uses a hashing mechanism called MD5 developed by RSA. (For details, see "The MD5 Message-Digest Algorithm" at http://www.ietf.org/rfc/rfc1321.txt.) Although it is a viable authentication option for Internet scenarios, the client and server requirements limit its widespread use. Unlike Basic authentication, and in a similar fashion to NTLM and Kerberos, IIS does not log on the user locally to the Web server so you cannot perform delegation.

Typical usage scenarios

You should consider Digest authentication when:

Your Web server is running Windows 2000 and your users have Windows accounts stored in Active Directory.
All of your clients use either the .NET platform or Internet Explorer 5.x.
You need a stronger level of password encryption than that provided by Basic authentication.
You need to support authentication over the Internet.

You should not consider Digest authentication when:

You have clients using platforms other than .NET or Internet Explorer 5.0 or later.
Your users do not have Windows accounts stored in Active Directory.
You require delegation.

Other considerations

You should also consider the following when choosing Digest authentication.

Making Digest authentication secure

The intent of Digest authentication is to provide a more secure means of logging on than that provided by Basic authentication. However, it is not as secure as Basic authentication coupled with SSL, NTLM, Kerberos, or Certificate authentication.

The use of Digest authentication over SSL is a secure solution; however, its deployment requirements currently limit its widespread usage.

Specific platform requirements for Digest authentication

Digest authentication requires that clients run using .NET or Internet Explorer 5.x. User accounts must be stored in Active Directory, which must be configured for Digest authentication.

Implementation

You must configure IIS for Digest authentication. For more information see the Microsoft Knowledge Base article Q222028, Setting Up Digest Authentication for Use with Internet Information Services 5.0.

If your ASP.NET application needs to run as the user authenticated by IIS Digest authentication, use the following Web.config configuration:

// web.config file
<system.web>
<authentication mode="Windows" />
</system.web>

To use Digest authentication in Windows 2000, the server must have access to an Active Directory server that is set up for Digest authentication.

For more information about Digest authentication, see the specification RFC 2069 at http://www.ietf.org/rfc/rfc2069.txt.

Integrated Windows Authentication

Integrated Windows authentication (using either NTLM challenge/response or Kerberos) involves authenticating a user with a Windows NT Domain or Active Directory account. Unlike Basic and Digest authentication, the encrypted password is not sent across the network, which makes this method very secure. If Active Directory Services is installed on the server and the browser is compatible with the Kerberos V5 authentication protocol, both the Kerberos V5 protocol and the challenge/response protocol are used; otherwise only the challenge/response protocol is used. It is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every computer is running Microsoft Internet Explorer version 3.01 or later.

Typical usage scenarios

You should consider Integrated Windows authentication when:

Your users have Windows NT Domain or Active Directory accounts.
Your application runs on an intranet (behind a firewall).
All of your clients are running Internet Explorer version 3.01 or later.
You need to perform delegation (this requires Kerberos).
You need a seamless logon procedure for domain users (for example, without pop-up logon dialog boxes).

You should not consider Integrated Windows authentication when:

Your user accounts are stored in an external database rather than a Windows NT Domain database or Active Directory.
You need to support authentication over the Internet.
Your clients are using Netscape Navigator or other non-Microsoft browsers.
You need to obtain the client's clear text password.

Other considerations

You should also consider the following when choosing Integrated Windows authentication.

Security level of NTLM and Kerberos

Both of these protocols are considered highly secure. With NTLM and Kerberos, the password is not transmitted over the network. NTLM uses a challenge/response mechanism. Kerberos is considered even more secure because it supports mutual authentication (that is, clients can verify the server with which they are communicating).

Delegation issues

The NTLM protocol does not support delegation. After the client's credentials are passed to the IIS server, they cannot be passed to a back-end server for authentication. However, Kerberos supports delegation, which allows the client credentials to be delegated to other processes on multiple downstream computers. For example, you can use Kerberos to present a Web user's credentials to a COM+ middle tier and through to a Microsoft SQL Server™ database, configured with Windows Integrated Security. Kerberos authentication is not enabled in a default Active Directory configuration. You must ensure your environment will support Kerberos before depending on it as a delegation solution.

Internet usage

Neither the NTLM nor Kerberos protocols are commonly used over the Internet. The key issue with using Kerberos over the Internet is that the security authority needs to be centralized and available to all users. The infrastructure needs to be in place to do this. Another issue with Internet deployment is that these protocols are not supported by non-Microsoft browsers, which may be a limiting factor depending on your particular client base.

Performance and scalability

Kerberos is faster than NTLM. However, both of these protocols are not as fast as Basic authentication or certain custom authentication methods. If you are expecting large numbers of users to log on concurrently, you need to carefully design your Active Directory configuration. Where you have potentially millions of users, you may consider using a high-performance database such as SQL Server to store your user names and passwords. If you are delegating security context in a multi-tier application, it is likely that you will run into scalability issues. Specifically, middle-tier solutions such as database connection pooling cannot be used.

Implementation

To implement Kerberos or NTLM, you will need to configure IIS to use Integrated Windows authentication. If you need to support clients other than those running Internet Explorer, you may want to enable Basic authentication in conjunction with NTLM or Kerberos.

You need to consider these specific details when configuring Kerberos:

The client and server computers must all be running Windows 2000 in a Windows 2000 domain.
The client's user account must be enabled for delegation.
The service's account must be enabled for delegation.

If your ASP.NET application needs to run as the user authenticated by IIS using Integrated Windows authentication, use the following Web.config configuration:

// web.config file
<system.web>
   <authentication mode="Windows" />
</system.web>

For more information about using Kerberos, see:

Certificate Authentication

A certificate is a digital "key" installed on a computer. When the computer tries to access a server, the key will be automatically presented to authenticate the user. Client certificates can be mapped to Windows accounts in either a Domain or Active Directory. If you use the Windows Authentication Provider in ASP.NET, the application thread will run as the user to which the certificate is mapped. You may also implement custom authentication in ASP.NET where, for example, you could use the e-mail address (or a similarly unique field) contained within the certificate. From the client's perspective, security is seamless as the client is not required to log in using a logon page. This makes certificates an attractive option for automated business processes.

Typical usage scenarios

You should consider Certificate authentication when:

The data you are protecting is considered very sensitive and you require a very secure solution.
You require mutual authentication.
You want a third party to be able to manage the relationship between the server and the certificate holder.
You want the client interaction to be seamless; for example, for an automated B2B exchange.

You should not consider Certificate authentication when:

The cost of issuing and managing client certificates outweighs the value of the added security.

Other considerations

You should also consider the following when choosing Certificate authentication.

Deployment

You will need to physically deploy the client certificate to the client workstation. There are different methods of doing this, ranging from a Web deployment to installing the certificate from a CD-ROM. The deployment issues are generally the reason why certificates are not as common as other authentication modes that are used in conjunction with SSL.

Mapping to Windows accounts

It is possible to map certificates to Domain or Active Directory accounts. If you need to authenticate individual users, you can use a technique known as one-to-one mapping where a certificate is mapped to an individual account. There is no limit on one-to-one mapping if you use Active Directory mapping.

If you need to authenticate all of the users from a particular group or organization, you can use many-to-one mapping where, for example, any certificate containing a common company name is mapped to a single account.

For example, consider the following B2B scenario:

Company A allows their partner company, Company B, to view a portion of their internal Web site.
Computers in Company B have a certificate installed.
The many-to-one mapping results in the ASP.NET application running as the generic "CompanyB" Windows account.

For more in-depth information about certificates, see the book Designing Secure Web-Based Applications for Microsoft Windows 2000 by Michael Howard.

Implementation

You must configure IIS for Certificate authentication. For information about mapping public key certificates to Windows 2000 user accounts, see the Step-by-Step Guide to Mapping Certificates to User Accounts.

Passport Authentication

Passport authentication is a centralized authentication service provided by Microsoft. When you use Passport, you do not need to implement your own authentication code, logon page, and user table in some cases. Passport works using a cookie mechanism. If clients have previously authenticated to Passport, they are allowed access to your site. If not, they are automatically re-directed to the Passport site for authentication.

Passport is a good choice if you require single sign-on capability across multiple domains that also support Passport. Passport provides additional services beyond its role as an authentication service, including profile management and purchasing services.

On the Windows 2000 platform, there is no direct integration of Passport to any authentication and authorization mechanisms built into the operating system. While the .NET Framework does check for Passport cookies, if you maintain your own user database, you must implement your own code to map the Passport user to your own user, as well as implement your own authorization mechanism.

Typical usage scenarios

You should consider Passport authentication when:

Your site will be used in conjunction with other Passport-enabled sites and you want to give single-sign-on capability to users accessing these sites.
You do not want to maintain a user name and password database.

You should not consider Passport authentication when:

You want to exploit usernames and passwords already stored in your own database or Active Directory. (Although, with additional code, you can potentially map a Passport ID to a user account.)
Your clients are other computers that access the site programmatically.

Other considerations

You should also consider the following when choosing Passport authentication.

Enabling Passport

Using Passport authentication requires site registration with the Passport service and installation of the Passport SDK on the server.

Delegation

On Windows 2000, it is not possible to delegate a user's Passport security credentials from one server to another.

Mapping to user accounts

The Passport User ID (PUID) is an identity only. If your user accounts are defined within Active Directory or any custom database, and you need to map the PUID to a user, you will need to implement your own custom code. Future versions of Windows may provide native support of mapping PUIDs to Windows accounts.

Making Passport secure

The nature of the encrypted cookie makes Passport secure when used as a stand-alone authentication method. However, to avoid replay attacks and to maintain the highest-security level, Passport needs to be used in combination with SSL.

Implementation

To implement Passport, you need to install the Passport SDK on the server. You also need to register with Passport to use the service. You must configure your web.config file as follows:

// web.config file
<system.web>
   <authentication mode="Passport" />
</system.web>

For more information about the Passport service, see:

The Passport Authentication Provider
Passport technical white paper
Passport developer information

Forms Authentication

Forms authentication refers to a custom user interface component that accepts user credentials; for example, a user name and password. Many Internet applications used today present such forms for users to log on. It is important to note that the form itself does not perform the authentication and is provided solely as a way of obtaining the user credentials. The authentication is performed by accessing the user name and password database using custom code.

When the user is authenticated, the server typically gives the client some means to indicate that it has already been authenticated for subsequent requests. If required, you can force the client to authenticate upon every request, although this impacts performance and scalability. There are two basic approaches that you should consider to identify a client who has previously logged on:

Cookies. A cookie is a small piece of data initially presented by the server to the client. It is subsequently presented by the client back to the server within each HTTP request. This can be used as an indication that the client has already been authenticated. ASP.NET provides a mechanism for you to use cookies for Forms authentication in the CookieAuthenticationProvider module. Cookies are supported by most Web browsers, including Internet Explorer and Netscape Navigator.
Custom. You can implement your own custom mechanism to identify the client to the server. If your clients have disabled cookies, you may consider storing a unique identifier within each URL query string. You can also use hidden form fields, which are stored in a persistent top-level or non-visible frame. In either case, you need to make sure that a hacker cannot simulate being authenticated to your application programmatically.

Cookies are widely utilized by Web sites that implement Forms authentication. The initial release of .NET will support only Forms authentication using cookies.

Typical usage scenarios

You should consider Forms authentication when:

User names and passwords are stored somewhere other than Windows Accounts. Note that it is possible to use Forms authentication with Windows Accounts.
You are deploying your application over the Internet.
You need to support all browsers and client operating systems.
You want to provide your own user interface form as a logon page.

You should not consider Forms authentication when:

You are deploying an application on a corporate intranet and can take advantage of Integrated Windows authentication.
You are unable to perform programmatic access to verify the user name and password.

Other considerations

You should also consider the following when choosing Forms authentication.

Making Forms authentication secure

If users are submitting passwords via the logon page, you can secure the channel using SSL to prevent passwords from being stolen. If you are using cookies to maintain the identity of the user between requests, you should be aware of the potential security risk of a hacker "stealing" the user's cookie using a network-monitoring program. The only true way to make the site completely secure when using cookies is to use SSL for all communications with the site. For most commerce sites, this will be impractical due to the significant performance overhead. With ASP.NET you can have the server regenerate cookies at timed intervals. This policy of cookie expiration is designed to prevent another user from accessing the site with a stolen cookie.

Performance and scalability

You need to consider the performance implications of authenticating users when designing a high-volume Web site. If you expect large numbers of users to log on concurrently, you need to make the credential verification as fast as possible.

If you are using SSL, there is a noticeable performance hit due to the additional encryption steps that must be performed. You may need to separate your servers that are performing the secure logon from the content servers in a Web farm to achieve your performance requirements.

Checking the cookie exists

If you are using .NET, the process to check that a cookie exists is performed automatically. However, without .NET, you have two basic approaches:

You can implement an ISAPI filter that confirms the presence of a cookie on a client's request, which proves that the client has been authenticated. If the cookie exists, you can allow the request to proceed. If the cookie does not exist, you can redirect the client to the logon page. An ISAPI filter such as the one described is implemented by Microsoft® Commerce Server 2000.
You can write code at the start of each Web page that checks for the existence of the cookie or some other custom value that is passed by the Web page. If the token is not present, the code can re-direct the user to the logon page. This is a simple implementation; however, you may not be able to protect resources other than ASP pages. For example, image files might still be accessible.

If you are using ASP.NET, you can take advantage of the built-in functionality provided by Forms authentication.

Using Forms authentication with Windows accounts

If you are deploying an Internet application and your users have Windows accounts on the server, it is possible to use Forms authentication or Forms authentication over SSL as an alternative to using Basic authentication or Digest authentication.

This may not be a good solution if your application is intranet-based and can already take advantage of Integrated Windows authentication. Your corporate security policy also may not approve of users entering their passwords into an HTML form.

Implementation

To implement Forms authentication you must create your own logon page and redirect URL for unauthenticated clients. You must also create your own scheme for account lookup. Using ASP.NET, you can use the following Web.config configuration:

// web.config file
<system.web>
   <authentication mode="Forms" />
</system.web>

Because you are implementing your own authentication, you will typically configure IIS for Anonymous authentication.

For information about implementing SSL, see the following articles.

Untangling Web Security: Getting the Most from IIS Security
"Configuring IIS 5.0 Security" in the Internet Information Services 5.0 Resource Guide

Cookies

A cookie is a small text file placed on your hard disk drive by a Web server. Its primary purpose is to allow the server to identify a returning client. You can use cookies with or without an authentication mechanism. Consider the following usage scenarios:

Use in conjunction with Forms authentication. The server issues the client with a cookie upon authentication and subsequent requests are verified based on the cookie presented to the server.
Use for personalization only, where customized content is provided to the user.

ASP.NET provides a mechanism to create cookies and automatically checks for their existence on client requests. The cookies created by ASP.NET can optionally be encrypted using a triple DES scheme supported by the .NET Framework. You can also implement your own implementation of a cookie provider and use it with Forms authentication.

For more information about cookies, see Information About Cookies.

Other considerations

There are possible size limitations on cookies depending on the browser type. The RFC 2019 specifies a 4 KB limit. Internet Explorer 5 does not impose a size limit. Browsers must have their security settings configured to accept cookies for them to work correctly.

Security for Web Services

A Web service is an application based on the ASP.NET infrastructure that can be invoked programmatically across the Internet. From a security standpoint, you have similar issues as you do when developing an interactive Web site. You also use the same mechanisms to secure a Web service as you do any other ASP.NET resource (such as IIS and ASP.NET authentication providers). However, you should consider these additional factors in your design:

Client Interaction. Your Web service may not have interactive users connecting and entering their security credentials. Instead, your "users" may be applications.
Method Level Security. You may need to authorize users at the method level to restrict usage to particular methods; you may do this in a similar fashion to the way method level security works for COM+ components.
Delegation. Your Web service may or may not need to call other services and maintain the security context of the original caller.

Web Service Authentication

Web services will need to accept user credentials in some manner. If the service is non-interactive, it will need to either obtain the security token of the caller, or it will need to expose the appropriate methods to allow credentials to be supplied. The following authentication methods can be easily used and do not require users to input credentials, making them good choices for programmable Web services:

Basic, Digest, and Integrated Windows authentication
Certificate Mapping authentication
Application specific or custom authentication

Potentially, you could also use:

Internet Protocol Security
Passport

Using Windows accounts and IIS authentication

You need to consider the same issues as described in the Authentication Methods section of this document. This implementation requires the least amount of custom coding and you will be able to authorize access to other resources using Windows ACLs.

Using certificates and Certificate Mapping

When using Certificate authentication, the interaction between the client and server can be seamless; that is, the client will not have to programmatically supply the user name and password. Additionally, this is a highly-secure mechanism. B2B transactions, such as purchase order submissions, provide an ideal scenario for using certificates. If you use Certificate Mapping to obtain Windows user accounts, you can also use Windows ACLs to authorize access to resources.

Custom authentication

You can implement Custom authentication solutions. The advantages of these solutions over the Integrated Windows authentication approach are that applications are no longer required to maintain separate Windows accounts for each user. You can also bypass IIS authentication altogether and use your own custom method in your Web service code and optimize it based on application-specific needs.

Possible Custom authentication solutions for Web services include:

Accept a user name and password as a parameter to your method calls.
Provide a logon method that must be called before any other calls to other methods. You can use the cookie functionality of the Microsoft .NET Framework to verify calls have been made to the logon method.
Use the SOAP header or SOAP body to store the credentials.
Create a custom HTTP header or body to store the credentials.

Internet Protocol Security

If you know the IP address of the client computer, for example if the client is a Web server invoking business logic encapsulated in Web services on the middle tier, Internet Protocol Security (IPSec) may be a viable option. This method allows you to restrict computers connecting to your Web service based on their IP address.

This is not a viable approach in Internet scenarios, where you do not know your client's IP addresses in advance.

Using Passport with Web services

In some cases, Passport authentication may by used by a Web service for authentication. However, its usage can be limited due to the requirement to redirect non-authenticated clients to the Passport site. Redirection could cause problems for non-interactive clients unless they are programmed specifically to handle the case of being redirected to the Passport server.

Authorization

After you authenticate the user, you may need to authorize them to access the Web service. The following are several authorization options:

Using Windows ACLs
Using URL Authorization
Using .NET Principal Objects

Using Windows ACLs

Using Windows ACLs, you can create file system permissions on specific application files. This solution works if your Web service is authenticating users to Windows accounts and uses impersonation.

Using URL authorization

The URLAuthorizationModule maps users and roles to elements within the URI namespace. This module implements both positive and negative authorization assertions. That is, the module can either be used to selectively allow or deny specific users access to arbitrary elements of the URI namespace, based, for example, on their role membership. The following example grants access to several domain users, while denying it to everyone else.

<configuration>
   <system.web>
         <authentication mode="Windows" />
          <authorization>
              <allow users="domain1\user, domain2\user2, domain1\user3 />
              <deny users="*" />
          </authorization>
    </system.web>
</configuration>

Windows Principal object

The System.Security.Principal namespace within the .NET Framework Class Library (BCL) provides a WindowsPrincipal object to represent the security context under which the code is running. This object is created for you automatically when you use Windows authentication in IIS. It allows you to check the Windows group membership of a Windows user and restrict access accordingly.

Generic Principal object

A Generic Principal object can be created based on your own custom roles. You will use this when you have your own user/role database. The Principal object is populated in the OnAuthenticate event. You may have a custom table mapped to Windows accounts that you map in this event. In any case, you can create a custom Principal object for that particular user.

For returning users who have already been authenticated, you could use a cookie to recreate the Principal object for the returning user.

Roles and method level security

You may need to use method level security to restrict particular methods being called by particular client principals. There are several approaches to this problem.

If you are using Windows accounts, create roles for your users in the form of Windows Groups. Because the ASP thread will be impersonating the client and you will have a Windows Principal object available; use the following approaches:

Create ACLs on protected resources accessed by the ASP.NET thread.
Call the IsInRole method on the WindowsPrincipal object from each method to verify the caller has the appropriate permissions. You may also implement a logic statement in code that calls a particular sub-routine based on the client's group membership.

If you are using a Generic Principal object created from users and roles contained in a custom database:

You can programmatically check role membership by calling the IsInRole method on the Principal object in the same fashion as with the Windows Principal object described above.

If you are not using a Principal object, you have other options:

Accept user credentials as parameters to the method call and perform a lookup.
Verify the existence of a cookie as the first operation of the method call.
Create a logon method that returns a custom key value. Subsequent methods accept the key value as a parameter. This is similar to using browser-supported cookies; however, it could be used in cases where cookies are not supported by the client.

Delegation

The same delegation issues exist for Web services as for ASP.NET Web sites. To delegate security context to a Web service, you will need to use Kerberos authentication, or you will have to pass the credentials so that Web services running on other computers can call LogonUser if they are Windows servers, or the equivalent authentication API if they are non-Windows servers.

Client Access

If you connect to a Web service programmatically, you can take advantage of the .NET classes for client connectivity. The supported authentication protocols from .NET clients are:

Basic
Digest
Windows Integrated (NTLM and Kerberos)
Certificate
Custom

Code Access Security

To protect computer systems from malicious code and to provide a way to allow mobile code to run safely, the .NET Framework provides a security mechanism called Code Access Security (CAS). While CAS is a .NET security feature, it applies to all .NET managed code such as ASP.NET Web applications. While CAS applies to all managed code, you may need to specifically code with it in mind when:

You are designing browser-hosted controls
You are hosting third-party applications
You are hosting assemblies from different vendors on a shared server
You want to prevent certain native functions, such as file write APIs, to be available to certain assemblies

CAS allows code to be trusted to varying degrees, as determined by security policy, depending on where the code comes from and on other aspects of the code's identity, such as its strong assembly name. CAS reduces the likelihood of your code being misused by other malicious code. It allows you to specifically set the operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Specifically, CAS supports a permission support mechanism by which code can explicitly request particular permissions and explicitly refuse others that it knows it never needs.

Code access permissions

Code access security relies upon the notion of code access permissions. Each permission represents the right for code to access a protected resource such as a file, directory, or registry entry, or the right for it to perform a protected operation such as calling into unmanaged code. Permissions can be demanded by code and the runtime security policy determines which permissions to grant. For a complete list, see Code Access Permissions.

.NET allows administrators to assign a pre-defined set of permissions to an application. These permission sets vary based on the level of trust accorded to the application. By default, applications receive a level of trust dependent upon the evidence presented about the code's digital signature, origin, and the location of the application.

For example, applications running on a UNC share (running in the Intranet security zone) receive the LocalIntranet permission set. Applications running on the local machine (running in the MyComputer security zone) receive the FullTrust permission set.

ASP.NET Web applications can be further configured by assigning them trust levels. Trust levels are configured using the <trust> element within the configuration file.

<trust level="Full | High | Low | None" originUrl="url" />

Each level determines the application's permissions, the details of which are specified by an XML security policy file. Each level maps to a specific file. The default mappings for ASP.NET are:

High—maps to web_hightrust.config
This level provides permissions that grant applications read/write access to the application directory (subject to operating system permissions) and allows the application to replace the authentication principal object. It also restricts applications from calling into non-managed code.
Low—maps to web_lowtrust.config
This level allows applications to read from the application directory and provides limited network connectivity. Applications can connect back to their host site, assuming the originUrl attribute of the <trust> element is configured appropriately.
None—maps to web_notrust.config
This level provides basic execution permission and supports the application's use of isolated storage (a mechanism which allows code to be safely associated with saved data).

Note that Full trust has no associated configuration file as Full trust allows applications to use all resources (subject to operating system permissions), which is just like running without code access security (although CAS cannot be switched off for managed code). You can override these mappings within the <securityPolicy> element of the configuration file and can customize and extend each level. You can also create your own levels that define arbitrary permission sets. The default <securityPolicy> mapping set is shown below.

<securityPolicy>
   <trustLevel name="Full" policyFile="internal" />
   <trustLevel name="High" policyFile="web_hightrust.config" />
   <trustLevel name="Low"  policyFile="web_lowtrust.config" />
   <trustLevel name="None" policyFile="web_notrust.config" />
</securityPolicy>

Locking configuration settings

ASP.NET configuration is hierarchical in nature, with configuration files optionally at the machine, application, and sub-application levels. Sub-level configuration files can be used to override settings made at a higher level or can be used to add additional configuration information. While this provides a high degree of flexibility, administrators may sometimes want to enforce the configuration settings and not allow them to be overridden by specific applications. For example, an administrator of a hosted Web site may wish to specify the code access security level and not allow it to be changed by individual applications. This can be achieved using the <location> element coupled with the allowOverride attribute.

For example, an administrator of a hosted Web site may wish to ensure that no applications are allowed to call into unmanaged code. The following configuration file fragment shows how an administrator could lock down the code access configuration settings for a whole site and restrict applications with the High trust level (which does not allow calls into unmanaged code):

<location path="somesitepath" allowOverride="false">
  <trust level="high" originUrl="http://somesite.com" />
</location>

The path attribute may refer to a site or a virtual directory and it applies to the nominated directory and all sub-directories. In the example above, if you set allowOverride to "false", you can prevent any application within the site from overriding the configuration settings specified within the <location> element. Note that the ability to lock configuration settings applies to all settings, and not just security settings such as trust levels.

For more information, see:

Security in .NET: Enforce Code Access Rights with the Common Language Runtime
Code Access Security

Channel Security

Channels transport messages across remoting boundaries, such as AppDomains, processes, and computers. The .NET Framework provides two remoting channels, HTTP and TCP.

You need to consider using a secure channel when you want to protect confidential or sensitive information that is transmitted with these protocols. Using network monitoring software, this information can be easily intercepted and read unless the information is protected using encryption.

The following are some key points of channel security:

The HTTP channel hosted in IIS with ASP.NET supports the transmission and receipt of secure data using SSL. SSL is the most common mechanism for setting up a secure communications channel and can be configured within IIS.
If you want to use a non-secure channel such as HTTP/Port 80 or TCP, you can still encrypt the data manually using the Cryptographic API.
It is possible to implement a channel security mechanism below the transport layer. If you are using Windows 2000, you can take advantage of Internet Protocol Security (IPSec) to secure the data transmission while being transparent to the application.
If you are using ASP.NET together with COM or DCOM components and you are using DCOM as your remoting mechanism, consider using the DCOM Packet Privacy authentication level to encrypt your DCOM communication.

For more information, see:

"Secure Web Communications" in the Microsoft® Windows® 2000 Server Resource Kit available from Microsoft Press®
Remoting specifications in the .NET Framework Developer Specifications
Setting Up DCOM and NT Security topics in MSDN

Additional Information

For additional information about the security topics discussed in this document, see the following references.

"Understanding Digital Certificates" in the Microsoft® Windows® 2000 Server Resource Kit available from Microsoft Press
.NET Framework SDK
Microsoft Knowledge Base Article Q158229, INFO: Security Ramifications for IIS Applications
A Blueprint for Building Web Sites Using the Microsoft Windows Platform

For more information on securing Web services, see the following references.

Secure Web Services Using the SOAP Toolkit
Designing Secure Web-Based Applications for Microsoft® Windows® 2000 available from Microsoft Press
Secure Internet Information Services 5 Checklist
Microsoft Knowledge Base Article Q187506, List of NTFS Permissions Required for IIS Site to Work

For general information on security, see:

Microsoft Security

APPENDIX A

Figure 3. Flow chart for determining most appropriate authentication method (Click on image to see larger picture.)

Collaborators

Many thanks to the following contributors and reviewers:

Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro (Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward Jezierski, Alex Mackman, Mike Jenne, David Mowers, Amitabh Srivastava, Steve Busby, Kenny Jones.

To learn more about .NET best practices, you can work side-by-side with technology experts at the Microsoft Technology Center in your area. For more information please visit the Microsoft Technology Centers Web page.

Authentication in ASP.NET: .NET Security Guidance

Related Links

Contents

Introduction

Security Considerations

Relationship Between IIS and ASP.NET

ASP.NET Authentication Providers and IIS Security

Authentication using Windows accounts

Authentication using non-Windows accounts

Impersonation and delegation

Application identities

Authentication Methods

Determining an Authentication Method

Explanation of flowchart decision points

Anonymous Authentication

Typical usage scenarios

Other considerations

Implementation

Basic Authentication

Typical usage scenarios

Other considerations

Implementation

Digest Authentication

Typical usage scenarios

Other considerations

Implementation

Integrated Windows Authentication

Typical usage scenarios

Other considerations

Implementation

Certificate Authentication

Typical usage scenarios

Other considerations

Implementation

Passport Authentication

Typical usage scenarios

Other considerations

Implementation

Forms Authentication

Typical usage scenarios

Other considerations

Implementation

Cookies

Other considerations

Security for Web Services

Web Service Authentication

Using Windows accounts and IIS authentication

Using certificates and Certificate Mapping

Custom authentication

Internet Protocol Security

Using Passport with Web services

Authorization

Using Windows ACLs

Using URL authorization

Windows Principal object

Roles and method level security

Delegation

Client Access

Code Access Security

Code access permissions

Locking configuration settings

Channel Security

Additional Information

APPENDIX A

Collaborators