If you are looking for documentation and information on implementing a SAML 2.0 based Single Sign On (SSO) system, and can’t seem to find much online references, you’ve arrived at the correct place. In the next few posts we’ll be discussing everything you need to know about implementing a SAML 2.0 based SSO systen.
Before we get started, we need to first understand what SSO and SAML are, and how they work
Single Sign On
Single Sign On (SSO) is an access control property for multiple independent software systems. Is is a user authentication process that permits a user to enter a single username and password and be given access to an array of multiple applications. The SSO system authenticates the particular user for all the applications and services that he has been given the right to access, which eliminates the need for further authentication when accessing these applications or services.
“Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but difficult to implement”
-The Open Group-
SSO is typically “difficult to implement” due to different applications and services, supporting different authentication mechanisms. Thus the SSO mechanism implanted, should have the ability to translate the credentials used for initial authentication, to be used to access the other applications and services.
Conversely, Single Single Sign Off or Single Log-out is the process where a single logging out, terminates the access to multiple applications and services.
Kerberos is an authentication mechanism which uses tickets to access different applications and services. The initial authentication at the Authentication Server (AS), grants the user an encrypted Ticket Granting Ticket (TGT). When the client needs to access a particular service, the clients sends the TGT to the Ticket Granting Service (TGS) which verifies the validity of the ticket and issues a session key to the client to access the requested service.
Smart cards are a hardware token. At initial authentication the user credentials are stored in the card which negates the need for the user to be authenticated every time the user access an application or a service. Provided that the user holds the smart card, the user is given access to these services.
Security Assertion Markup Language (SAML)
SAML is an XML standard. It is the most reliable and easy-to-implement SSO configuration, making it the most commonly used. It is mostly designed for business to business and business to consumer transactions. We’ll be talking more about SAML in the next post.
The most common benefit is that SSO reduces the need for a user to remember different username-password combinations, thus improving the user experience. This in-turn reduces the possibility of errors and thereby increases productivity.
The main drawback lies with the possibility of the username and password falling into the wrong hands. Unlike in a system that is not implemented with SSO, the damaged caused could be catastrophic. Thus the need for increased security and protection in an SSO implemented system is identified.
Security Assertion Markup Language (SAML)
SAML is an XML based protocol that is used in exchanging authentication and authorization data between domains with the use of tokens. SAML was produced by the OASIS Security Services Technical Committee in 2001. The latest version of SAML is SAML 2.0 which was accepted as an OASIS standard in 2005. SAML 2.0 is the key configuration used in SSO thus the focus of this discussion will be on SAML 2.0.
The working of SAML 2.0 SSO is given below.
Once the process is complete, the Service Provider grants the user access to the service, based on the permissions defined in the service providers user database.
Where there are multiple service providers, SSO enables the client to use the same SAML token granted from the IdP, to access all the services. Thus the user need only be authenticated once by the IdP and thereafter given access to all the service providers.