What is Single Sign-On ?
Single sign-on (SSO) is a session and user authentication service that permits users to use one set of login credentials (e.g., name and password) to access multiple applications.  SSO can be used by enterprises, smaller organizations, and individuals to mitigate the management of various usernames and passwords.  It is often accomplished by using the Lightweight Directory Access Protocol (LDAP) and storing LDAP databases on (directory) servers. SSO shares centralized authentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.

Example: A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain.

Conversely, single sign-off is the property whereby a single action of signing out terminates access to multiple software systems.

Benefits of Single Sign-on:

1. Mitigate risk for access to 3rd-party sites (user passwords not stored or managed externally)
2. Reduce password fatigue from different username and password combinations
3. Reduce time spent re-entering passwords for the same identity

Types of Single Sign-on:

1. Kerberos Based
2. Smart Card Based
3. Integrated Windows Authentication
4. Security Assertion Markup Language[SAML]:  XML-based method for exchanging user security information between an SAML identity provider and a SAML service provider.
   

SAML:

Security Assertion Markup Language (SAML) is an XML-based framework used to authorize, authenticate and communicate attributes and privileges of a user. The Security Assertion Markup Language (SAML), is an open standard. The framework takes care of both Authentication and Authorization. SAML 2.0 was introduced in 2005 and remains the current version of the standard. SAML is one way to implement single sign-on (SSO),

Reasons for wide adoption of SAML is mainly for the following factors

1. Standardized:
2. Security:
3. User Experience

Components of SAML:

SAML Service Provider: Systems that provide or consume SAML services are generically called service providers.
Example: Akamai Control Center is a service provider to users to configure and view CDN.

SAML Identity Provider: SAML identity provider is the entity within the system that makes sure the user really is who they claim to be — it provides authentication.It may also determine what services, if any, that user is authorized to access across various entities in the system
Example: Salesforce, LDAP, RADIUS or Active Directory.

SAML Assertion: A SAML assertion is the XML document by which all the information we’ve been discussing is transmitted from one computer to another. After the SAML Identity provider has identified the user by it’s own methods, SAML Identity provider sends an SAML assertion to SAML service provider. The assertions consists of authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the IdP’s public and private DSA/RSA keys.

A SAML assertion may be encrypted for increased security. 

Steps of SAML Authentication:

1. The user attempts to reach a hosted application on Service Provider’s end.
2. Service Provider (SP) generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s SSO service. The RelayState parameter containing the encoded URL of the application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection.
3. SP sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner’s SSO service – Identity Provider.
4. The Identity Provider (IdP) decodes the SAML request and extracts the URL for both SP’s ACS (Assertion Consumer Service) and the user’s destination URL (RelayState parameter). The IdP then authenticates the user. IdP could authenticate users by either asking for valid login credentials or by checking for valid session cookies.
5. The IdP generates a SAML response that contains the authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the IdP’s public and private DSA/RSA keys.
6. The IdP digitally signs the SAML response and the RelayState parameter and returns that information to the user’s browser. The IdP provides a mechanism so that the browser can forward that information to SP’s ACS
7. SP’s ACS verifies the SAML response using the partner’s public key. If the response is successfully verified, ACS redirects the user to the destination URL.
8. The user has been redirected to the destination URL and is logged in to the application.