5

I am investigating options for single sign-on between two disparate systems: one .NET, one Java EE. They are each managed independently and have separate user management, with some overlapping users.

I would like to be able to link from one to the other without re-prompting for password.

There seem like there are many options for SSO products and protocols out there. I'm fairly confident I could code up a one-off to generate and validate my own secure tokens but would prefer not to re-invent the wheel.

What would you recommend, in terms of approach and/or product (preferably open source)?

First, would you go with something that supports SAML, OpenID, OAuth, or none of the above?

Second, of the free/open-source products out there, I'm aware of OpenAM, Shibboleth, JOSSO and CAS. Any experiences to share with any of them, good, bad or ugly?

CDspace
  • 2,639
  • 18
  • 30
  • 36
wrschneider
  • 17,913
  • 16
  • 96
  • 176

1 Answers1

9

Firstly lets look at the protocols:

  1. SAML 2.0 is a centralized/decentralized SSO protocol. It is the most advanced protocol and offers federation i.e you could allow users to sign in using any one of X systems, or channel all users through a single system (known as an IDP). SAML 2.0 is widely used in the financial and government sectors along with some major hosted applications (Google apps and Saleforce for example). It is also the most complex protocol

  2. OpenID is a decentralized protocol and is most suited to internet, not intranet/extranet applications. Users can choose to sign in from any OpenId provider. Stackoverflow is a good example of OpenId - we can choose to sign in using our Google or Facebook account. You can implement OpenId in a centralized manner by forcing a default association between the consuming application (known as a Relying Party) and the SSO system (known as a Service Provider).

  3. OAuth is not really a SSO protocol. It allows a user to grant Application A access to his information in Application B without providing the credentials for Application B to Application A. Some people have used OAuth as a form of pseudo authentication i.e. if the system is able to access photos belonging to User X then the user must be X. It's a hack and not recommended.

It is definitely a good idea to go with a standardized protocol to avoid lock in. Microsoft has recently introduced support for SAML 2.0 and there are many open source and commercial products available for Java. There are OpenId implementations available for java but I don't know enough about the .NET world to comment.

As you mentioned there are a range of open source SAML products available (OpenAM, Shibboleth, JOSSO and CAS). One note of caution - SAML is a complex protocol so if you do go down the open source route you will need to be prepared for some hard work. When we built our Cloudseal SSO platform (SAML 2.0 based) we spent a lot of time trying to simplify things to abstract the complexity. Other commercial vendors have done the same but the open source products you mentioned are more focused on functionality rather than simplicity - IMHO! :)