Single Sign On for a Web App

Question

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

Electrotonus

I am curious as to why someone downvoted this question yesterday. Care to comment? – Electrotonus

Note that it was TWO YEARS after it was posted that someone downvoted it. Coincidentally (perhaps?), the person who downvoted it may have been the one thousandth viewer. – Electrotonus

I am looking for something very similar. Did you get a solution to your problem? Please share any insights on how to go about achieving this. – Grain

@Grain Sorry, not really. I ended up leaving the company where I was supposed to do this task, so it wasn't really a priority for me anymore. – Electrotonus

This question is quite similar to #4664678 and #8935253 – Quarta

Answer 1

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.

Ossified

Answer 2

One basic problem with your approach is that you're considering your web app in isolation. Employees at your client's company won't just require SSO to your web app but also some/few/many others, and extending your approach would require a bespoke implementation for each of those to enable access.

Hence the widespread adoption of OpenAthens and Shibboleth in the academic library community to leverage the use of locally-issued credentials. A typical medium/large university can subscribe to various products/services from more than fifty different publishers, and by deploying OpenAthens/Shibboleth they can take advantage of the SAML open standard (SAML is the protocol that Shibboleth uses) that is seeing increased take-up not only in the academic sector, but also in the commercial sector.

John's answer above points to another issue: there are a number of open standards that have recently emerged, SAML and OpenID among them. So content providers are having to decide whether they want to implement some or all of these natively, but they use separate technology stacks and so the implementation and support costs can be duplicated.

Quite a few major publishers have implemented OpenAthens as this supports Athens, SAML/Shibboleth and OpenID in a single platform, with options to plug in other technologies too, or writing a custom module to allow an internal app to connect, e.g. an invoicing or entitlements system recording which clients' users are logging in.

This sector of access management is definitely moving towards open standards, so building your own method would be depriving access to your app for a large number of users

Raffia