AuthFilter Processing in a Web Farm

AuthFilter only collects credentials when the request is redirected from the Login.asp page. AuthFilter gets these credentials on the outgoing path so the credentials are never exposed outside the Web server. Thus, you need to put the credentials on the querystring when you do a redirect from the login page. When you get the credentials from the user in Login page form, you must put the credentials on the querystring regardless of whether you are doing a get or post.

In a Web farm, AuthFilter allows an authenticated user on one server access to a site on another server without the user having to resubmit login information. However, if the request is sent with the Post method using non-sticky sessions, any information contained in the header body is lost during the required redirection. Only use the Post method with sticky sessions. If you use non-sticky sessions, always use the Get method and HTTPS. When the authenticated user arrives at a new server for the first time, the following steps are performed:

  1. AuthFilter checks for the correct URL (and auto-corrects for case sensitivity).

  2. AuthFilter checks for session-cookie support.

  3. AuthFilter checks for the MSCSAuth ticket.

  4. AuthFilter checks that the MSCSAuth ticket is valid (by comparing the current time to the last login time plus the time window specified on the ticket).

  5. Since the password cache is not shared between hosts, and this is the first time the user visited this site, there is no entry in the cache corresponding to the user ID in the ticket. Detecting this, AuthFilter resets the MSCSFirstRequestedURL cookie property to the current requested URL.

  6. Processing is passed to the login page.

  7. On the login page, it is verified that this is not a Submit action, and the user has a valid MSCSAuth ticket. The user ID is retrieved from the ticket and used to retrieve the profile of the user.

  8. The password of the user is retrieved from the profile and appended to the requested URL query string along with the user ID. The password must be available in clear text.

    Ee796713.note(en-US,CS.20).gifNote

    • This step requires that you have stored clear-text passwords in either Active Directory or a custom cache. Storing clear-text passwords is a security risk because they are inherently less secure than encrypted passwords. For more information about using a clear-text password, see Clear Text Passwords.
  9. The user is redirected to the requested URL and, when notified of the event by IIS, AuthFilter removes the user ID and password from the query string and places them into the cache.

  10. When the browser resubmits the request, AuthFilter checks the cache, finds the corresponding entry, and checks if the current time is within the time window.

  11. If the current time is within the time window, AuthFilter sets the user ID and password for the request and allows it continue.

  12. If the user has access rights to the requested URL, it is processed and returned by IIS.

Ee796713.note(en-US,CS.20).gifNote

  • For Custom Authentication, the password cache is not used, therefore when a request is redirected to a new server, Authfilter on that server only verifies that the MSCSAuth ticket contained in the request is valid, and if valid, allows the request to proceed, otherwise it redirects the request to the Login.asp page.

Copyright © 2005 Microsoft Corporation.
All rights reserved.