Authenticating Users in a Web Farm

Single Sign-on (SSO) in a Web farm scenario is supported using AuthFilter in either Custom Authentication or Windows Authentication mode.

  • Custom Authentication mode. When a user logs in to your site, Commerce Server authenticates the user by verifying the login and password, supplied by the user on the login page, against the login and password stored in the Profiles data store. After Commerce Server verifies the user information, it issues a MSCSAuth ticket, and passes the credentials to AuthFilter to store in its cache for the application. The cookie specifies that the user is authenticated and is allowed to access secured pages on your site.
  • Windows Authentication mode. No verification is necessary in the Login.asp page. Instead, the login page issues an MSCSAuth ticket and sends the user credentials to AuthFilter. AuthFilter then uses these credentials to populate the authentication header, to allow IIS to authenticate the request against Active Directory.

In a Web server farm scenario, if a user is authenticated on one Web server, and then is redirected or load-balanced to another Web server, the second Web server does not prompt the user to log in again. To support this functionality, you can enable AuthFilter, which Commerce Server installs at the IIS Web site level. When the user is redirected to the second Web server, the ISAPI filter reads the user cookie and identifies that the cookie contains the user ID and that it is valid. If you are using Custom Authentication mode, no other steps are performed. If you are using Windows Authentication mode, Commerce Server performs the following steps:

  1. Because AuthFilter does not have the credentials for the user in its cache (this is the first time the user is requesting access to a page from this server), Authfilter redirects the request to Login.asp.

  2. On Login.asp, because the request has a valid MSCSAuth ticket, using the user ID in the ticket, a query is made to the Profiles data store for the user profile. This returns the user login ID and password in clear text.


    • 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.
    • The site developer must provide this functionality. For more information, see Clear Text Passwords.
  3. Code in the Login.asp page appends the login ID and password to the URL, and then redirects the request to the URL requested originally.

  4. AuthFilter intercepts the request for the secured page, and removes the user ID and password from the URL and stores the login ID and password in its cache.

  5. AuthFilter then displays the secured page to the user. The user ID and password are not transmitted to the user.

Copyright © 2005 Microsoft Corporation.
All rights reserved.