Custom Forms-Based Authentication Solutions for WSS/SPS, Hand-Rolled or Partner-Supported

There’s a nice article on TheServerSide.NET entitled Integrating 3rd Party Single Sign On in Sharepoint Portal Server that explains how to write a custom (unsupported by Microsoft) forms authentication layer that sits in front of SPS and WSS.  But it misses one very key detail:  you must use persistent cookies.  They can be very short-lived persistent cookies, but they must be persistent.

This gives me a chance to blog about SharePoint sites and how they interact with smart clients.

All interaction with WSS, from any client, takes place over HTTP.  If it’s DHTML over HTTP, then the client is a browser.  If it’s SOAP over HTTP, WebDAV over HTTP, or FrontPage RPCs over HTTP, the client is some form of rich client — ideally a smart client (there’s a distinction).

But unless you’re using a browser to get the DHTML interface, there’s no place to display a custom logon form, let alone figure out how to send a response to it.  How should Word, for example, react when it sees a custom form instead of the document it requested?  It can’t.  You can either react in a standard way to a HTTP 401 Unauthorized response and pop up a standard authentication dialog box, or you need a means to be preauthenticated at the time the request is made.

That’s why you need persistent cookies.  You hit the Web site with a browser first to fill out the form and get the cookie, after which you can launch all the smart clients you want, which will offer the cookies to the server even when it’s a SOAP, WebDAV, or FPRPC call.

I long for a “single sign-on” solution that doesn’t assume everything’s a browser (except for Kerberos, of course)… if you know of one, please post a comment.

(P.S., to properly represent Microsoft, I have to of course tell you that MS doesn’t support anything but standard HTTP authentication for the current releases of WSS and SPS. It was a matter of both resources and the difficulty with supporting someone else’s custom code. We’ve worked with some ISVs to create solutions based on this approach to let their products support WSS/SPS, but in those cases, the ISVs themselves are providing the necessary support for their solutions.)