Single Sign On (SAML 2.0)


As more and more technologies move into Cloud based services Users are faced with more and more login credentials to memorise. Single Sign On (SSO) is an optional service offered to our Customers to replace the standard TalentLink authentication mechanism with their own, enabling them to integrate their corporate systems more closely to the TalentLink application.

Security Assertion Markup Language 2.0 (SAML 2.0) is one of several existing standards for implementing SSO. SAML is an Open Standard created by OASIS, a non-profit consortium that drives the development, convergence and adoption of open standards for the global information society.

How does SAML 2.0 work?

SAML 2.0 defines a communication protocol that establishes a trusted environment, known as a Federation, among two or more systems - usually separated geographically.

Users can access and make use of resources in all of the systems that make part of a federation without needing to log into each of them. Users can enter the federation by providing their credentials just once, and also can leave the federation in one single step, terminating their interaction with all federation members simultaneously.

A system belonging to a SAML 2.0 federation can act in one of two roles:

  • Identity Provider (IdP) or
  • Service Provider (SP).

An Identity Provider takes care of authenticating the users, establishing who a user is and what are their privileges in the federation. The IdP communicates this information to all the other members of the federation by sending to them cryptographically signed security assertions containing all the relevant details concerning the identity of the user.

SAML 2.0 assertions are simple, human-readable XML documents. What makes them “trusted” are the signatures that are attached to them, which are created using SSL certificates and Public Key Infrastructure. These allow a system receiving such an assertion to verify its integrity and authenticity. Additionally, assertions are often exchanged through encrypted transport protocols (e.g. HTTPS) to ensure their confidentiality.

A Service Provider consumes security assertions and grants users access to its services.

A typical example

In a traditional SAML 2.0 integration, the IdP is the Customer's corporate intranet and the SP are Lumesse SaaS applications (i.e. TalentLink).

The effect, as seen by the end user, is usually a direct and unencumbered access to Lumesse applications from the Customer's intranet for any user already logged in or, for users not yet logged in, the replacement of the standard login forms with the Customer's intranet login page.

SAML 2.0 Bindings – The keys to successful authentication

SAML 2.0 bindings refer to the way messages (containing the security assertions and other data) are passed between the Identity Provider and the Service Provider.

Our recommendation and standard is HTTP POST.One of the core benefits using this kind of binding is ability to “bypass” firewall restrictions. HTTP POST, which circumvents the problems with excessive length of URL addresses by using hidden forms submitted between IdP and SP. Anyway, in both cases the user's browser is used as the conduit that transport data between all parties in the federation.

Activation of SAML 2.0 SSO

Lumesse and the Customer must exchange a metadata file from their IdP (identity provider) system, e.g. their Active Directory system. It might be delivered as an XML file or just a URL that points to a metadata page. This metadata is required to complete the Federation between the two systems and work cannot continue without it.

Once this metadata has been exchanged it is required to be finalized within the configuration in TalentAccess and in customer’s IdP.

What is a SAML 2.0 metadata file?

The SAML 2.0 metadata file is an XML file containing:

  • a list of the capabilities offered by a member of the federation, as well as its specific role (whether it's a IdP or a SP).
  • It also includes several certificates containing the public keys that can be used to encrypt messages sent to certain services provided by that system, or to verify the signatures of the messages it sends.

The order in which it's performed is irrelevant but a full exchange must be completed.

Auto-Federation (Email Address)

As already stated “Federation” relates to a trusted technical environment between two or more systems. It is a typical requirement that this Federation is an automated process rather than a manual one. Customers do not want to spend any more time than is necessary authenticating users in a Single Sign On service.

The sequence of a Federation process would be:

  1. The User logs-in (authenticates) to the Identity Provider (IdP), e.g. their organisations Active Directory. This is commonly done for organisations when their employees login to their computers each day.
  2. User access TLK URL contains parameter “tlk_idp”.
  3. TLK TalentAccess asks IdP directly or via user browser (depends on configuration) to authenticate user.
  4. The Identity Provider securely confirms a SAML assertion “we know who you are” to the User Browser in the form of an XML file with specific signatures attached typically sent over HTTPS (and are called SAML Bindings).
  5. The User Browser immediately and automatically submits this to the TLK TalentAccess.
  6. First time user is automatically federated based on the e-mail address attribute. For “returning”’ user federation data stored in TLK are used.
  7. TLK TalentAccess redirects user to TalentLink and logs the user into the system directly.

This means that the Federation between the three items is automatically created using the email address of the user as the matching item.

This means that users must be created within TalentLink with attached email addresses before this option will operate successfully.