ASP.NET Security Data Flow

You can design security into ASP.NET applications in a number of ways. This topic describes the security data flow for two common scenarios: impersonation and forms authentication using cookies.

Scenario 1: Impersonation

The impersonation scenario relies on Microsoft Internet Information Services (IIS) authentication and Microsoft Windows file access security to minimize security programming in the ASP.NET application itself. The data flow is shown in the following illustration.

Impersonation

The illustration shows the following sequence of events:

1. A request from a network client comes to IIS.

2. IIS authenticates the client using basic, digest, or Windows integrated security (NTLM or Kerberos).

3. If the client is authenticated, IIS passes the authenticated request to ASP.NET.

4. The ASP.NET application impersonates the requesting client using the access token passed from IIS, and it relies on NTFS file permissions for granting access to resources. The ASP.NET application needs only to verify that impersonation is set to true in the ASP.NET configuration file; no ASP.NET security code is required.

   If impersonation is not enabled, the application runs with the ASP.NET process identity. For Microsoft Windows 2000 Server and Windows XP Professional, the default identity is a local account named ASPNET that is created automatically when ASP.NET is installed. For Microsoft Windows Server 2003, the default identity is the identity of the application pool for the IIS application (by default, the NETWORK SERVICE account.)

   Note
   If impersonation is not enabled and you want to restrict access for a particular user or set of users, such as users authenticated using forms authentication, then you must use some other means of authorization, such as URL authorization. For more information on URL authorization, see ASP.NET Authorization.

   For more details about using impersonation in ASP.NET applications, see ASP.NET Impersonation and Using IIS Authentication with ASP.NET Impersonation.

5. If access is granted, the ASP.NET application returns the requested resource through IIS.

Scenario 2 - Forms Authentication

In the forms authentication scenario, an application collects credentials such as name and password directly from the user and makes its own determination about their authenticity. IIS authentication is not used by the application, but IIS authentication settings can affect forms authentication. As a rule, when you use forms authentication, you enable anonymous access in IIS. Otherwise, if users do not pass IIS authentication, they do not reach your application in order to provide a user name and password to forms authentication.

The data flow in this scenario is shown in the following illustration.

Forms authentication

This illustration shows the following sequence of events:

1. A user generates a request for a protected resource.

2. IIS receives the request, and because IIS anonymous access is enabled, IIS does not perform any user authentication and the request is passed to the ASP.NET application.

3. Because the ASP.NET authentication mode is set to forms, the ASP.NET application examines the request for a forms authentication ticket (a specific cookie). If there is no authentication ticket attached to the request, ASP.NET redirects the request to the logon page specified in the application's configuration file.

4. On the logon page, the user enters the required credentials, usually a name and password. The application code checks the credentials to confirm their authenticity. If the credentials are authenticated, the application code attaches an authentication ticket to the response that represents the user credentials. (The password is not included). If authentication fails, the response is returned with an access denied message or the logon form is presented again.

   The authentication ticket that is issued is included with subsequent requests to the ASP.NET application. ASP.NET checks the ticket for validity using a message authentication check (MAC).

5. If the user is authenticated, ASP.NET checks authorization and can either allow access to the originally requested resource, redirect the request to some other page, or redirect the request to a custom authorization module where the credentials are tested for authorization to access the protected resource. If authorization fails, ASP.NET redirects the user to the logon page.

   If the user is authorized, access is granted to the protected resource; or the application might require an additional test of the credentials before authorizing access to the protected resource, depending on the design of the application.

   Note
   Forms authentication and authorization checking apply only to resources protected by the authentication and authorization configuration elements. Access to Windows resources protected using Access Control Lists (ACLs) is checked against the current Windows identity of the ASP.NET application. For more information, see ASP.NET Impersonation.

See Also

Tasks

How to: Implement Simple Forms Authentication

Concepts

ASP.NET Impersonation
Using IIS Authentication with ASP.NET Impersonation

Other Resources

Managing Users by Using Membership
Managing Authorization Using Roles
ASP.NET Web Application Security
Forms Authentication Provider