Single Sign-On (SSO) and SAML (Security Assertion Markup Language)

What is SSO?
Single Sign-On (SSO) requires a user to authenticate himself to a service one time and does not require reauthentication for other services of the system linked by the SSO framework.

SSO addresses a common issue – that of requiring users to manage and remember authentication credentials (usually a username/password pair) for every service or application they have been subscribed to.

SSO requires that users need remember only one set of authentication credentials. This set of authentication credentials is “passed-on” to other SSO-enabled services (or applications) so that the user can use them transparently without having to reauthenticate.

How is SSO typically implemented
You can implement SSO using your own bespoke SSO logic implementation or you can use a standards-based technique. Either option has it’s own advantages and disadvantages.
Advantages of bespoke programming means that you have a lot of versatility and you are in the driver’s seat when deciding the level of SSO you are looking at. There are disadvantages too, however. Chief among them are reliance on in-house expertise (which is often not available or insufficient) and lack of scalability, extensibility and performance.
On the other hand if you adopt standards-based techniques you are assured of an industry-accepted solution which augurs well for the reliability, scalability, extensibility and performance of the application. Disadvantages, typically, are associated with implementation teams having to learn “another new” standard and code to the specification, although one may counter-argue that implementations may already exist in the market.

Techniques used for SSO
Proxy-based SSO and SAML-based SSO are two most common techniques used for SSL implementation. This article does not go into the details of proxy-based SSO.

Enter SAML
SAML is yet another acronym for you to remember. It stands for Security Assertion Markup Language. The ‘ML’ in the name gives away that SAML is XML based.
Here’s the single important reason why applications need SAML – SAML allows seamless inter-domain sharing of security information. This was not easy before SAML was created.

Thumb-rule for determining if my application requires SAML
This answer is answered by asking this simple question:
Does your application, either currently or in the near future, have a business need for offering a seamless user experience of service usage across business partners and other 3rd party service providers?
If the answer to the above question is ‘Yes’, your application needs SAML

Some advantages afforded by SAML?
1. Platform neutrality
SAML abstracts the security framework away from platform architectures and particular vendor implementations. This makes security more independent of application logic which is an important tenet of Service-Oriented Architecture.

2. Loose coupling of directories/databases
SAML does not require user information to be maintained and synchronized between directories/databases.

3. Improved online experience for end users
SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows for a better-customized user experience at each service while promoting privacy.

4. Reduced administrative costs for service providers
Using SAML to "reuse" a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is transferred to the identity provider.

5. Risk transference
SAML can act to push responsibility for proper management of identities to the identity provider, which is more often compatible with its business model.