Regular Windows authentication with IIS works by passing data back and forth in the headers of the requests and responses between the browser and the server.  For Basic authentication, the server sends a www-authenticate header saying “Basic” and a realm.  When the browser receives this, it pops up the dialog prompting for credentials.  The dialog is a built in feature of the browser.  It then sends an authorization header with “Basic” and the base64 encoded username and password.  The server receives this and logs the user on to the machine (I believe this is handled by the sspiauth ISAPI filter, but I’m not positive; it is definitely handled by IIS directly though).  In this case, the browser did very little work as it just took the username and password and send them directly (with a little bit of encoding).

 

NTLM and Kerberos are similar, but there are more round trips and more data is passed (although the plain text password is never transmitted).  The client does more work here since the SSPI APIs are used to compute the data required by the server to negotiate the protocol and exchange the required data.  This is one of the reasons why almost all browsers support Basic authentication, but most don’t support Integrated authentication as it requires using these Windows-specific APIs on the client.  The server-side story is similar to basic authentication, but with some technical differences.

 

With forms authentication, the data is just sent as part of a form post by the client like any other data in a form post.  There is no processing that is authentication-specific in the browser.  Since the application must process the submitted forms data, the application calls its own DLL to do the authentication, although it is probably very similar in function to what IIS implements to handle authentication (using SSPI and other security APIs).

 

Hopefully this helps clarify things.

 

Joe K.

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lara Adianto
Sent: Thursday, August 26, 2004 8:23 PM
To: [EMAIL PROTECTED]
Subject: Re: [ActiveDir] owa logon

 

Internet Explorer is responsible for the pop-up box.  Is the DLL(s) different when using forms based auth?  Yes it is, since forms based auth uses the server-side information vs. the client processes.

 

Does that help or answer your question? 


I'm a bit confused here. You mean that there's no dll that IE used to pop-up the dialog box ? Form-based authentication uses logon.asp to get user credential, and relies on owaauth.dll in the exchweb/bin/auth directory for the authentication. I wonder whether the non-form based auth also relies on owaauth.dll...

 

-lara-

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

Reply via email to