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.)
Comments
Anonymous
April 25, 2005
So what you are saying is that the combination of Sharepoint, IE and Office 2003 (Word) can't do single sign on in an extranet scenario when using Microsoft supported features?
In the extranet your authentication method is most likely basic auth. So you connect to sharepoint and get prompted for basic auth, then you ask for a word doc which gets requested using Frontpage RPC. Of course Frontpage RPC doesn't know anything about the the basic auth that already happened. So the user gets prompted for basic auth again and gets rather confused because they already authenticated.
Or am I missing something?Anonymous
April 26, 2005
So what would be the recommended method for using sharepoint and Office documents in an extranet scenario and have the client prompted only once for authentication?
Is the answer persistent cookies? Are they supported by Sharepoint or ISA authentication methods?Anonymous
December 05, 2005
The comment has been removedAnonymous
January 13, 2006
we are using CustomAuth filter in IIS 6.0 Resource Kit Tools (http://support.microsoft.com/default.aspx?scid=kb;en-us;840671) to authenticate user. Authorization is done in SharePoint portal.
The filter works fine if we don’t reset IIS. We can see login page, and can log into SharePoint portal. After resetting IIS, we still can see login page, but get SharePoint access denied page.
This observation is repeatable and somebody also reported same problem on Internet. If we repeat the configuration, it will work once again until next IIS reset.
We’re using Window 2003 server, the AD is in window 2000 mode. SharePonint Portal 2003.
Appreciate any help. Thanks.Anonymous
February 14, 2006
Hands up if you've seen this one with SharePoint 2003: you log on to your (SharePoint) site fine, then...Anonymous
March 14, 2006
I've read this article as well as the one that you've pointed to. I've setup CustomAuth on a site as an ISAPI filter. There is one MAJOR disconnect for me, however, that perhaps you can shed some light on. Their example assumes that SiteMinder has been installed. I will not be using this 3rd party product. Rather, I'm hoping to be able to build my own login page that will set up the auth ticket appropriately to be handled by CustomAuth. Is this the right way to think about it? How does one accomplish this?Anonymous
May 25, 2006
Perhaps I am a much more basic level. I just want to know how to pass the authenticated ID to a WebPart in which I need the user name to retrieve data from a SQL DB that is specific to the user.
What I REALLY would like is to use the Page Viewer Web Part so that I do not have to wrap existing web pages in web parts.Anonymous
June 01, 2006
For those who aggregate my feed and do not often visit the blog iteself... I've updated my SharePoint...Anonymous
December 13, 2006
Thanks to everyone who turned out for the security webcast today on SharePoint. We had about 60-70 peopleAnonymous
December 13, 2006
via bsimser Thanks to everyone who turned out for the security webcast today on SharePoint....Anonymous
June 27, 2007
Free SharePoint Web Parts (3rd Party) Konrad Brunner - UGS's Web Parts (broken link 8/25) DocumentAnonymous
November 03, 2008
PingBack from http://prashantlink.wordpress.com/2008/11/04/free-sharepoint-web-parts/Anonymous
January 21, 2009
PingBack from http://www.keyongtech.com/1993153-is-possible-to-implement-aAnonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=fitzblog-custom-forms-based-authentication-solutions-for-wss-spsAnonymous
June 19, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=3314