Microsoft KB Archive/303642

= Site Server authentication does not provide notification events =

Article ID: 303642

Article Last Modified on 12/6/2004

-

APPLIES TO


 * Microsoft Site Server 3.0 Commerce Edition

-



This article was previously published under Q303642



SYMPTOMS
You do not receive authentication notification events for a Microsoft Internet Information Services (IIS) site that is mapped to Site Server Personalization and Membership for authentication. Additionally, the ISAPI filters that are registered to receive SF_NOTIFY_AUTHENTICATE events do not receive the corresponding events.



CAUSE
Site Server authentication is registered as a type of Microsoft Windows authentication. The following events occur when you send a request to the Web server that is mapped to Site Server Personalization and Membership:
 * 1) A client requests a page. The Microsoft Commerce Server AuthFilter Internet Server API (ISAPI) filter receives a PREPROC_HEADERS notification. The HandlePreProcHeaders operation checks for the Authorization header and returns when the Authorization header is not found.
 * 2) IIS sees that the URL is protected by the MBS_BASIC provider, and then returns a 401 access denied error with WWW-authenticate set to MBS_BASIC.
 * 3) The Commerce Server Authfilter ISAPI filter receives the SEND_RESPONSE notification, and then replaces MBS_BASIC with BASIC.
 * 4) The client sends the username and password.
 * 5) The Commerce Server Authfilter ISAPI filter HandlePreProcHeaders operation replaces BASIC with MBS_BASIC.
 * 6) IIS sees MBS_BASIC, and then calls the registered security support providers in order.
 * 7) The Msnsspc.dll file processes the request. Because IIS does not have to perform the authentication or the impersonation, the authentication notification is not generated.



RESOLUTION
To make sure that authentication notification events are received, configure a central logon page. For example, you can use Default.asp as the central logon page. Specify forms authentication for the page, and then require certificates. If both authentication operations occur, an authentication notification event is provided by the certificate authentication process. You can also use the following events:
 * The SF_NOTIFY_AUTH_COMPLETE event can be used by an ISAPI filter to provide the certificate information. However, the SF_NOTIFY_AUTH_COMPLETE event is only available on Windows 2000-based computers.
 * The SF_NOTIFY_SEND_RESPONSE event can be used by an ISAPI filter to receive authentication notification events. In the SF_NOTIFY_SEND_RESPONSE event, the certificate information is available. In this case, set a flag that is checked in the SEND_RAW_DATA ISAPI filter operation. If you set this flag, set the corresponding event to initialize the buffer or to return a 401 error. Users will not be able to view the Web page. For the page where the 401error occurs, the SF_NOTIFY_END_OF_SESSION ISAPI filter operation that is received causes a custom error page that includes the HTTP error.

You can use the SF_NOTIFY_SEND_RESPONSE event to validate the user by using the client certificate that is available. If the user is valid, the request can be processed. If the user is not valid, follow these steps:
 * 1) To prevent an endless loop, set a flag in the SF_NOTIFY_SEND_RESPONSE ISAPI filter operation if the client has not been validated.
 * 2) If the flag is set to copy or to append the pvInData buffer to a private buffer that you have allocated in the SF_NOTIFY_SEND_RAW_DATA ISAPI filter operation, zero out this structure so that IIS reads it as empty. This event may occur many times.
 * 3) If this flag is set in the SF_NOTIFY_END_REQUEST ISAPI filter operation, call the WriteClient method, and then add any information that you want to include on the page.

The SF_NOTIFY_SEND_RAW_DATA event is entered again. However, because this flag is not set, you do not have to take any action. The SF_NOTIFY_END_REQUEST event is also entered again, and you do not have to take any action.

Note To determine the user's identity, an ISAPI filter can obtain the Preproc_headers notification, and then look for the BASIC Authorization header. The username and password information can be extracted by using UUDecode. Set a flag in the filter context so that the ISAPI filter can trap the SEND_RESPONSE notification. If the response is not a redirect or an access denied error message, you can conclude that the user was successfully authenticated.



MORE INFORMATION
Authentication notifications are available when IIS tries to authenticate clients. Native IIS Authentication operations, including anonymous authentication, basic authentication, and SSL certificate negotiation, cause authentication notification events. However, registered IIS Windows NT authentication providers, such as NTLM, Kerberos authentication, and Site Server authentication, do not cause these notifications.

This behavior does not occur in Commerce Server 2000 because of the underlying architecture. SiteAuth includes a notification event handler for SF_NOTIFY_AUTHENTICATION events. Forms authentication is configured for anonymous authentication.

