Partager via

Data Flow in ASP.NET

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1

There are a number of different ways to design security into ASP.NET applications. This section describes the data flow for two common scenarios: impersonation and forms authentication using cookies.

Scenario 1: Impersonation

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

The illustration shows the following sequence of events:

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

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

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

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

    Notice that if impersonation is not enabled, the application runs with the IIS process identity. For Microsoft Windows® 2000 Server and Windows XP, the default identity is a User account named ASPNET that is created automatically when ASP.NET is installed. For products in the Microsoft Windows Server 2003 family, the default identity is the Network Service account. If you want to restrict access, you must use some other means of authorization, such as URL authorization.

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

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

Scenario 2 - Forms Authentication

In this scenario an application uses ASP.NET forms authentication, a process that enables the application to collect credentials such as name and password directly from the client requestor and make its own determination about their authenticity. IIS authentication is not used by the application, but IIS authentication settings are important to the ASP.NET forms authentication process. Unless you decide to reject all requests that do not meet the criteria for the enabled method of IIS authentication, you must enable the IIS Anonymous Access setting.

Note

If you do not enable anonymous access in IIS, requests not meeting the criteria for IIS authentication will be rejected and never reach the ASP.NET application.

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

Art Image

This illustration shows the following sequence of events:

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

  2. IIS receives the request, and if the requestor is authenticated by IIS, or if IIS anonymous access is enabled, the request gets passed on to the ASP.NET application. Because the authentication mode in the ASP.NET application is set to forms in this case, IIS authentication is not used.

  3. If there is no cookie attached to the request, ASP.NET redirects the request to a logon page, the path of which resides in the application's configuration file. On the logon page, the client user enters the required credentials (usually a name and password).

  4. The application code checks the credentials to confirm their authenticity, usually in an event handler. If the credentials are authenticated, the application code attaches a ticket (as a cookie) containing the user name, but not the password. If authentication fails, the request is usually returned with an Access Denied message or the logon form is presented again.

  5. After a ticket is issued by the application, ASP.NET just checks the ticket for validity using a message authentication check. Applications do not need the credentials in the *.config files. In fact, ASP.NET does not check them after the cookie is issued, even if they are present.

  6. If the user is authenticated, ASP.NET checks authorization and can either allow access to the originally requested, protected resource or redirect the request to some other page, depending on the design of the application. It can also direct the request to a custom authorization module where the credentials are tested for authorization to access the protected resource. If authorization fails, ASP.NET always redirects to the logon page.

  7. 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.