Single Sign On for a Web App

Jeremy Goodell picture Jeremy Goodell · Apr 2, 2010 · Viewed 14.5k times · Source

I have been trying to understand how this problem is solved for over a month now. I really need to come up with a general approach that work. I have a theory, but I'm just not sure it's the easiest (or correct) approach and I haven't been able to find any information to support my ideas.

Here's the scenario:

1) You have a complex web application that offers secure content on a subscription basis.

2) Users are required to log in to your application with user name and password.

3) You sell to large corporations, which already have a corporate authentication technology (for example, Active Directory).

4) You would like to integrate with the corporate authentication mechanism to allow their users to log onto your Web App without having to enter their user name and password.

Now, any solution you come up with will have to provide a mechanism for:

  • adding new users
  • removing users
  • changing user information
  • allowing users to log in

Ideally, all these would happen "automagically" when the corporate customer made the corresponding changes to their own authentication.

Now, I have a theory that the way to do this (at least for Active Directory) would be for me to write a client-side app that integrates with the customer's Active Directory to track the targeted changes, and then communicate those changes to my Web App. I think that if this communication were done via Web Services offered by my web app, then it would maintain an unhackable level of security, which would obviously be a requirement for these corporate customers.

I've found some information about a Microsoft product called Active Directory Federation Service (ADFS) which may or may not be the right approach for me. It seems to be a bit bulky and have some requirements that might not work for all customers.

For other existing ID scenarios (like Athens and Shibboleth), I don't think a client application is necessary. It's probably just a matter of tying into the existing ID services.

I would appreciate any advice anyone has on anything I've mentioned here. In particular, if you can tell me if my theory is correct about providing a client-side app that communicates with server-side Web Services, or if I'm totally going in the wrong direction. Also, if you could point me at any web sites or articles that explain how to do this, I'd really appreciate it. My research has not turned up much so far.

Finally, if you could let me know of any Web applications that currently offer this service (particularly as tied to a corporate Active Directory), I would be very grateful. I am wondering if other B2B Web app's like salesforce.com, or hoovers.com offer a similar service for their corporate customers.

I hate being in the dark and would greatly appreciate any light you can shed ...

Jeremy

Answer

John picture John · Apr 3, 2010

Shibboleth is designed to support exactly this scenario. However it will rely on your customers' companies implementing the identity provider mechanisms. At the moment, that's only really common in universities. Further, if you want user information (any more than just a pseudonymous identifier), you'd need the company to agree to release those attributes to you.

I find it hard to believe that many companies would open their corporate authentication system to you, just to provide SSO.

You might find it better to rely on OpenID or similar, and using a "remember me" cookie to reduce the need for people to enter passwords.