Authentication in ASP.NET

Authentication in ASP.NET
Ronen Ashkenazi Solutions Development Architect Microsoft Israel This presentation is based on the Authentication in ASP.NET: .NET Security Guidance Architecture Guide available from msdn.microsoft.com/practices. Version 1.0. 23 January 2003

Agenda Security Considerations Relationship Between IIS and ASP.NET
Authentication Methods Security for Web Services Code Access Security This is the content we will be covering in this presentation.

Security Considerations
Consider the following when designing an application: Security goals Security risks Authentication Authorization Securing data transmission Impersonation Delegation Operating system security Securing physical access Code access security 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. 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 other aspects of the code's identity. You should be aware of how to create your own access permissions.

Security Relationship Between IIS and ASP.NET
Web clients IP address and domain permitted? IIS Access denied No Yes User authenticated? No Yes Launch ASP.NET application ASP.NET ASP.NET impersonation enabled? ASP.NET application runs with local machine identity 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). No Yes Access check OK? (e.g. NTFS) ASP.NET application assumes client identity No Access granted Yes

ASP.NET Authentication Providers and IIS Security
ASP.NET supports three authentication providers: Forms Authentication – Relies on a logon form and cookies Passport Authentication – Centralized authentication service provided by Microsoft Windows Authentication – IIS handles authentication Provider is specified in the Web.config file  <authentication mode = "[Windows|Forms|Passport|None]"> </authentication> 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>

ASP.NET and IIS Security Settings Matrix
ASP.NET Authentication Providers IIS Authentication Method Forms Basic Integrated Windows Digest Passport In addition to authentication, ASP.NET provides an impersonation mechanism to establish the application thread's security token. Obtaining the correct token relies on you configuring IIS authentication, ASP.NET authentication providers, and ASP.NET impersonation settings appropriately. The figure shows the most likely combinations between IIS authentication and ASP.NET providers. Certificate Mapping None (Custom) Anonymous

Authentication Using Windows Accounts
Authenticate users with Windows user accounts by combining IIS authentication and the Windows authentication provider for ASP.NET No authentication-specific code needs to be written with this approach ASP.NET constructs and attaches a WindowsPrincipal object to the application context 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. 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 could 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
Configure IIS for Anonymous authentication and use one of the following .NET authentication modules: None – custom or no authentication Forms – provide a logon page Passport – use the Passport service 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 when you are 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
Impersonation allows ASP.NET applications to execute with a client's identity Delegation enhances impersonation by allowing remote resources to be accessed while acting as the client Impersonation is configured in the Web.config file  <identity impersonate="[true|false]" name="domain\user" password="pwd"> </identity> 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, because 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.

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 IIS UNC token Enabled IUSR_SERVER Authenticated user Enabled with a specified user "Jeff" "Jeff" The table 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.

Application Identities
ASP.NET application worker process (aspnet_wp.exe) executes under ASPNET account ASPNET account has minimal privileges Configure account name in <processModel> element of machine.config file "SYSTEM" (System account) "MACHINE" (ASPNET) Custom user account <system.web> <processModel enable="true" username="domain\user" password="pwd"> </processModel> </system.web> 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. First, if security is breached, the intruder does not have administrative access. Second, 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 \Windows\Microsoft.NET\Framework\Version\Config folder, as shown in code sample. 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", because specific credentials are not required. The "SYSTEM" setting (which is the default) runs the worker process using the System account, while "MACHINE" 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. Subdirectories 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.

Authentication Methods
Factors in Choosing an Authentication Method Determining an Authentication Method 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.

Factors in Choosing an Authentication Method
Server and client operating systems Client browser type Number of users, location and type of user name and password database Deployment considerations (Internet vs. intranet and firewalls) Application type (interactive Web site or non-interactive Web service) Sensitivity of data being protected Performance and scalability factors Application authorization requirements (all users, or restricted areas) 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
Users in Windows accounts? Users log on? Yes (Continued next slide) Yes No No Personalization required? Users in Passport? Yes No Passport Anonymous No Interactive user logon? Yes Anonymous and cookies Anonymous and passport Explanation of flowchart decision points Do users have to log on? 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. No Certificates Yes Secure logon? Yes Forms over SSL Certificates Forms No

Determining an Authentication Method
Yes, users are in Windows accounts App runs on Internet? Delegation required? Yes No Custom Credential Mapping Basic Kerberos No Yes Servers and clients Win2K? Yes Secure logon? Basic Forms Digest No Basic Digest NTLM Kerberos Certificates Explanation of flowchart decision points cont. 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 95, Windows 98, and Windows NT 4.0? No Yes Basic NTLM Certificates Basic/SSL Digest/SSL Forms/SSL Certificates

Authentication Methods
Anonymous Authentication Basic Authentication Digest Authentication Integrated Windows Authentication Certificate Authentication Passport 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 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 logon.

Anonymous Authentication
Typical usage scenarios Consider Anonymous authentication when: Caller name and/or password 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 password 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 logon 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 logon name and password.

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 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 separate from the authentication. 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 better 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 of 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 Configure IIS for Anonymous authentication Configure the appropriate anonymous user account in IIS Configure the ASP.NET Web.config file  <system.web> <authentication mode="None" /> </system.web> 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>

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 passwords are sent using Base64 encoding, which is NOT secure Most browsers support 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 on your user interface design requirements. Most Internet browsers support Basic authentication.

Basic Authentication Typical usage scenarios
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 password in your application code Delegation Do not use Basic authentication when you require: Secure logon while not using a secure channel, such as Secure Sockets Layer (SSL) Storage of information in a custom database A customized form presented to the user as a logon page 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 logon 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 logon page.

Basic Authentication Other considerations
Delegation is possible using Basic authentication Combine Basic authentication with SSL to prevent passwords from being deciphered 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.

Basic Authentication 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  <system.web> <authentication mode="Windows" /> </system.web> 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>

Overview of Digest Authentication
New to Windows 2000 and IIS 5.0 Encrypts the user's password using MD5 Dependent on browser and server capabilities Cannot perform delegation 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 Although it is a viable authentication option for Internet scenarios, the client and server requirements limit its widespread use. Unlike Basic authentication, and in fashion similar to NTLM and Kerberos, IIS does not log on the user locally to the Web server, so you cannot perform delegation.

Digest Authentication
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 Password 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 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.0 or later. 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 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 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 Configure IIS for Digest authentication Configure the ASP.NET Web.config file  <system.web> <authentication mode="Windows" /> </system.web> 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

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 password is sent across the network Best suited to an intranet environment Works with Internet Explorer 3.01 or later 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.

Integrated Windows Authentication
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 password 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 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 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 that 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 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  <system.web> <authentication mode="Windows" /> </system.web> 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>

Overview of Certificate Authentication
A certificate is a digital "key" installed on a computer Certificates can be mapped to user accounts Request: Welcome.aspx Response: Certificate request Request: Login.aspx + Certificate Response: Welcome.aspx Web Server Client Certificate Validation 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 address (or a similarly unique field) contained within the certificate. From the client's perspective, security is seamless because the client is not required to log on using a logon page. This makes certificates an attractive option for automated business processes. Domain Controller

Certificate Authentication
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 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 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) 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 its partner company, Company B, to view a portion of its 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 Configure IIS for Certificate authentication Configure the ASP.NET Web.config file  <system.web> <authentication mode="Windows" /> </system.web> You must configure IIS for Certificate authentication. For information about mapping public key certificates to Windows 2000 user accounts, see “Step-by-Step Guide to Mapping Certificates to User Accounts” on TechNet.

Overview of Passport Authentication
A centralized authentication service provided by Microsoft Client Request: Welcome.aspx Response: Passport Sign In Request: Login.aspx + Cookie Response: Welcome.aspx Web Server Passport authentication Creates authentication cookies 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 redirected 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. Microsoft Passport

Passport Authentication
Typical usage scenarios Consider Passport authentication when: Your site will interact with other Passport-enabled sites Single sign-on capability is required External maintenance of user names and passwords is useful Do not use Passport authentication when: You want to use user names and passwords already stored in your own database or Active Directory Clients are other applications that access the site programmatically 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 user names and passwords already stored in your own database or Active Directory. (Note: 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 Requires registration with the Passport service and installation of the Passport SDK on the server Delegation is not possible on Windows 2000 Passport User ID (PUID) is an identity only Implement code to map PUID to users in Active Directory or custom database Passport uses encrypted cookies making system secure Combine Passport with SSL to prevent replay attacks for highest level of security 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 Install Passport SDK on server Register with Passport service Configure IIS for Anonymous authentication Configure the ASP.NET Web.config file  <system.web> <authentication mode="Passport" /> </system.web> 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>

Overview of Forms Authentication
A custom user interface accepts user credentials Authentication is performed against a database using custom code Client Web Server Request: Welcome.aspx Response: Login.aspx Authenticate user Web.config or User database Request: Login.aspx + data Response: Welcome.aspx + Cookie 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 affects 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 nonvisible frame. In either case, you need to make sure that a hacker cannot simulate being authenticated to your application programmatically. Cookies are widely used by Web sites that implement Forms authentication. The initial release of .NET will support only Forms authentication using cookies.

Forms Authentication Typical usage scenarios
Consider Forms authentication when: User names and passwords 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 password 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.

Forms Authentication Other considerations
Use SSL to secure passwords 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 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 that 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 redirect 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.

Forms 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  <system.web> <authentication mode="Forms" <forms loginUrl="login.aspx"/> /> </system.web> 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.

Additional Resources Patterns & practices are Microsoft’s recommendations for architects, software developers, and IT professionals responsible for delivering and managing enterprise systems on the Microsoft Platform To explore the available patterns & practices, visit:

Authentication in ASP.NET

Similar presentations

Presentation on theme: "Authentication in ASP.NET"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Authentication in ASP.NET

Similar presentations

Presentation on theme: "Authentication in ASP.NET"— Presentation transcript:

Similar presentations

About project

Feedback