Form & Windows Authentiation 流程圖

今天在瞭解Form Authentiation時，便上網找了不錯的流程示意圖!

圖片出處：http://authors.aspalliance.com/aspxtreme/webapps/aspnetdataflow.aspx

內容如下：

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

Scenario 1: Impersonation

This scenario relies on IIS authentication and 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 in to IIS from a network client.
2. IIS authenticates the client using basic, digest, or Windows NT NTLM authentication.
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. All that needs to be done for the ASP.NET application is 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 identity. The default identity is the System account. Access at the Access Control List ( ACL ) level is normally allowed for ASP.NET applications running with the System identity. 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 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 Using Forms

In this scenario an application is using 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 the IIS Anonymous Access setting, 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.

 

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, IIS authentication is not used.
3. 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. 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 in the design of the application.
4. 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 ).
5. 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 forms ticket containing the username, but not the password. An application could include the password, but ASP.NET treats it like one opaque username string. If authentication fails, the request is usually returned with an Access Denied message or the logon form is presented again.
6. If the user is authenticated, ASP.NET checks authorization, as in step 3, 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 some custom form of authorization where the credentials are tested for authorization to the protected resource. If authorization fails, ASP.NET always redirects to the logon page.

很清楚的流程圖喔!!