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 (15)
  1. Frank Surely says:

    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?

  2. Frank Surely says:

    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?

  3. What about the following idea:

    I have a central single-sign on system (ASP.Net) that uses mixed authentication. That is: If a user comes to the site as an anonymous user, the system redirects the browser to a forms-based authentication form, wich can both authenticate him at the Active Directory or a database.

    But if the user comes as an authenticated AD user, the system looks at the user configuration to decide if he is allowed to do integrated authentication or if he will have to type username and password (in that case, forms authentication).

    Then I can control things like: IP ranges (witch ones allows integrated authentication and what IP’s will restrict that to a forms authentication mechanism)

    So, what about ASP.Net 2 membership providers?

    I think that the logical step is that SharePoint could be "plugged" to membership providers, as any other application. And if microsoft office runs in that scenario, the logical action would be opening a small window (IE hosted) to give the user the possibility to authenticate in any point as needed.

    Once that action comes from a browser, the system (based on the idea above described) would allow integrated single sign on without problems, even if my central security system allows mixed authentication scenarios.

    SharePoint REALLY should trust in a membership provider mechanism that could be totally customized, to allow users from many sources and not only the AD ones.

  4. Prasad says:

    we are using CustomAuth filter in IIS 6.0 Resource Kit Tools (;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.

  5. Hands up if you’ve seen this one with SharePoint 2003: you log on to your (SharePoint) site fine, then…

  6. Mike@NSE,Inc says:

    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?

  7. Trevor Miles says:

    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.

  8. For those who aggregate my feed and do not often visit the blog iteself… I’ve updated my SharePoint…

  9. Thanks to everyone who turned out for the security webcast today on SharePoint. We had about 60-70 people

  10. via bsimser Thanks to everyone who turned out for the security webcast today on SharePoint….

  11. Free SharePoint Web Parts (3rd Party) Konrad Brunner – UGS's Web Parts (broken link 8/25) Document

Comments are closed.

Skip to main content