Authentication Method in ASP.NET

Introduction

Authentication 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 Authentication requirements from a business perspective and the implications that a chosen security model can have on performance, scalability, and deployment.

Authentication Methods

ASP. NET provides different methods to authenticate a user:

• Anonymous Authentication
• Basic Authentication
• Digest Authentication
• Integrated Windows Authentication
• Certificate Authentication
• port Authentication
• Forms Authentication
• Using Cookies

Overview of Anonymous Authentication

• No authentication occurs in either IIS or ASP. NET.
• Good choice for publicly available Web site not requiring the identity of the caller.
• No browser restrictions

Typical Usage Scenarios

Consider Anonymous authentication when:

• Caller name and/or word is not required for logon or business logic components.
• The information you are protecting is considered "public".

Do not use Anonymous authentication when:

• You require a logon name and word

Other considerations

Good choice for sites containing personalized content only

• For example, a news site only interested in user's zip code

        -Impersonation cannot be used

• Appropriate permissions need configuring for anonymous user account

        -Gives highest performance, but lowest security

Implementation

• Configure IIS for Anonymous authentication.
• Configure the appropriate anonymous user account in IIS.
• Configure the ASP.NET Web.config file.

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

Overview of Basic Authentication

IIS instructs the browser to send the user's credentials over HTTP

• Browser prompts the user with a dialog box.

• User names and words are sent using Base64 encoding, which is NOT secure.

Most browsers support Basic authentication

Usage scenarios Typical

Consider Basic authentication when you require:

• Users to have Windows NT Domain or Active Directory accounts.

• Support for multiple browsers.

• Support for authentication over the Internet.

• Access to the clear text word in your application code.

• Delegation

Do not use Basic authentication when you require:

• Do not use Basic authentication when you require.

• Storage of information in a custom database.

• A customized form presented to the user as a logon page.

Other considerations

• Delegation is possible using Basic authentication.

• Combine Basic authentication with SSL to prevent words from being deciphered.

Implementation

• Configure IIS for Basic authentication.

• Configure user accounts to have "log on locally" enabled on Web server.

• Configure the ASP.NET Web.config file.

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

Overview of Digest Authentication

• New to Windows 2000 and IIS 5.0.

• Encrypts the user's word using MD5.

• Dependent on browser and server capabilities.

• Cannot perform delegation.

Typical usage scenarios

Consider Digest authentication when:

• The Web server is running Windows 2000 and users have Windows accounts stored in Active Directory.

• All clients use either the .NET platform or Internet Explorer 5.0 or later.

• word encryption above that of Basic authentication is required.

• Support of authentication over the Internet is required.

Do not use Digest authentication when:

• Some clients use platforms other than .NET or Internet Explorer 5.0 or later.

• Users do not have Windows accounts stored in Active Directory.

• Delegation is required.

Other considerations

Security

• Digest authentication is more secure than Basic authentication alone.
• Less secure than Basic authentication with SSL.
• Can also be combined with SSL.

Platform requirements for Digest authentication

• Clients - .NET or Internet Explorer 5.0 (or later).
• Server - running Active Directory with user accounts configured for Digest authentication.

Implementation

• Configure IIS for Digest authentication.
• Configure the ASP.NET Web.config file.

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

Overview of Integrated Windows Authentication

• Uses either NTLM challenge/response or Kerberos to authenticate users with a Windows NT Domain or Active Directory account.
• No word is sent across the network.
• Best suited to an intranet environment.
• Works with Internet Explorer 3.01 or later.

Typical usage scenarios

 

Consider Integrated Windows authentication when: 

• Users have Windows NT Domain or Active Directory accounts.
• Your application runs on an intranet (behind a firewall).
• All clients are running Internet Explorer 3.01 or later.
• Delegation is required (requires Kerberos).
• Seamless logon procedure for domain users is required (e.g. without pop-up logon dialog boxes).

Do not use Integrated Windows authentication when:

• User accounts are stored in an external database.
• Authentication over the Internet is required.
• Clients are using non-Microsoft browsers.
• You need the client's clear text word.

Other considerations

• NTLM and Kerberos are considered highly secure.
• NTLM does not support delegation; Kerberos does.
• Neither NTLM or Kerberos are commonly used over the Internet.
• Kerberos is faster than NTLM, but neither is as fast as Basic authentication.

Implementation

 

Clients and servers must be running Windows 2000 in a Windows 2000 domain 

• User and service accounts must be enabled for delegation.

Configure IIS for Integrated Windows authentication

Configure the ASP.NET Web.config file

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

Overview of Certificate Authentication

• A certificate is a digital "key" installed on a computer.
• Certificates can be mapped to user accounts.

 

Typical usage scenarios

 

Consider Certificate authentication when: 

• Data is considered very sensitive and you require a very secure solution.
• Mutual authentication is required.
• Third parties will manage the relationship between the server and the certificate holder.
• Client interaction must be seamless; for example, automated B2B exchanges.

Do not use Certificate authentication when:

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

Other considerations

 

Client certificates must be deployed to the client workstations

Map certificates to: 

• Individual user accounts (one-to-one mapping).
• Any user from a single company (many-to-one mapping).

Implementation

• Configure IIS for Certificate authentication.
• Configure the ASP.NET Web.config file.

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

Overview of port Authentication

• A centralized authentication service provided by Microsoft.

 

Typical usage scenarios

 

Consider port authentication when:

• Your site will interact with other port-enabled sites.
• Single sign-on capability is required.
• External maintenance of user names and words is useful.

Do not use port authentication when:

• You want to use user names and words already stored in your own database or Active Directory.
• Clients are other applications that access the site programmatically.

Other considerations 

• Requires registration with the port service and installation of the port SDK on the server
• Delegation is not possible on Windows 2000.
• port User ID (PUID) is an identity only.
  
  • Implement code to map PUID to users in Active Directory or custom database.
• port uses encrypted cookies making system secure.
  
  • Combine port with SSL to prevent replay attacks for highest level of security.

Implementation

• Install port SDK on server.
• Register with port service.
• Configure IIS for Anonymous authentication.
• Configure the ASP.NET Web.config file.

<!-- web.config file -->
<system.web>
     <authentication mode="port" />
</system.web>

Overview of Forms Authentication

• A custom user interface accepts user credentials.
• Authentication is performed against a database using custom code.

 

 

Typical usage scenarios

 

Consider Forms authentication when: 

• User names and words are stored somewhere other than Windows accounts.
• Your application runs over the Internet.
• Support for all browsers and client operating systems is required.
• A custom logon page is needed.

Do not use Forms authentication when:

• Applications are deployed on a corporate intranet and can take advantage of Integrated Windows authentication.
• You cannot programmatically verify the user name and word.

Other considerations

• Use SSL to secure words submitted via the logon page.
• Set cookie expiration to avoid cookie theft and misuse.
• SSL degrades performance, so consider separating logon and content servers.
• Checking for the cookie is automatic in ASP.NET applications.
• Use Forms authentication with Windows accounts as an alternative to Basic or Digest authentication.

Implementation

• Create a logon page.
• Create your custom account information lookup code.
• Configure IIS for Anonymous authentication.
• Configure the ASP.NET Web.config file, including the redirect URL for unauthenticated clients.

<!-- web.config file -->
<system.web>
      <authentication mode="Forms"
              <forms loginUrl="login.aspx"/>
      />
</system.web>

Summary

This article discusses the importance of authentication method when designing a server application. Both Microsoft Internet Information Services (IIS) and ASP.NET provide authentication method that will allow you to authenticate your users appropriately and obtain the correct security context within your application.