Security Assertion Markup Language

Why SSO?

With the proliferation of SaaS and other web-based applications, identity management is becoming a major concern for businesses. Just think about the number of usernames and password you regularly type each day. You probably log into your company's network, portal, webmail, benefits system, Google Apps, bespoke applications, Force.com applications. Now multiply this by the number of users in your company and think about the support and security implications. You need dedicated resources to manage your identity store, respond to password reset requests, provision new users for each system and deactivate users that no longer need access. Just think of the number of man hours you could save if you could eliminate 25-50% of your passwords and their associated costs!

Implementing a Single Sign-On (SSO) infrastructure enables users to sign in once and have access to all authorised resources.

Benefits of Implementing SSO

Implementing SSO provides not only time-saving benefits for end users but financial benefits for your company. Major benefits of SSO include:

• • Improved productivity - It takes an average of 20 seconds for a user to log into a resource. Not having to enter a password each time a user needs to access a resource saves time and makes users more productive.

  • Reduce frustration of multiple log-on events and forgotten passwords - Users only have one password to remember and update, and only one set of password rules to remember. Their initial login provides them with access to all resources, typically for the entire day.

  • Increased adoption - SSO reduces the barriers of use for resources. Since it is easier to access applications, users will start using them more.

  • Centralised user access control - A single registry of user identities with a centralized management interface allows quick and easy provisioning and deactivating of users.

  • Improved reporting and monitoring - A single repository for auditing and logging access to resources provides streamlined regulatory compliance.

  • Increased security - A secure, enterprise-wide infrastructure with common password and security policies that can be centrally managed and secured. Users are also less likely to write down their passwords when there is only one to remember.

  • Uniform security layer - SAML is platform agnostic allowing enterprise architects to implement a uniform security layer with existing assets.

  • Reduced helpdesk costs - Fewer helpdesk calls for password resets relates directly to bottom-line savings.

About SAML

Security Assertion Markup Language (SAML, pronounced sam-el^[1]) is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.

The single most important requirement that SAML addresses is cross domain Web browser single sign-on (SSO). Single sign-on is common at the intranet level (using cookies, for example) but extending it beyond the intranet has been problematic and has led to the proliferation of non-interoperable proprietary technologies. (Another more recent approach to addressing the browser SSO problem is the OpenID protocol.)^[2]

How SAML works

The SAML specification defines three roles: the principal (typically a user), the Identity provider (IdP), and the service provider (SP). In the use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an identity assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision – in other words it can decide whether to perform some service for the connected principal.

Before delivering the identity assertion to the SP, the IdP may request some information from the principal – such as a user name and password – in order to authenticate the principal. SAML specifies the assertions between the three parties: in particular, the messages that assert identity that are passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Similarly, one SP may rely on and trust assertions from many independent IdPs.

SAML does not specify the method of authentication at the identity provider; it may use a username and password, or other form of authentication, including multi-factor authentication. A directory service such as LDAP, RADIUS, or Active Directory that allows users to log in with a user name and password is a typical source of authentication tokens at an identity provider.^[3] The popular Internet social networking services also provide identity services that in theory could be used to support SAML exchanges.

SAML building blocks

SAML is built upon a number of existing standards:

Extensible Markup Language (XML)

Most SAML exchanges are expressed in a standardized dialect of XML, which is the root for the name SAML (Security Assertion Markup Language).

XML Schema (XSD)

SAML assertions and protocols are specified (in part) using XML Schema.

XML Signature

Both SAML 1.1 and SAML 2.0 use digital signatures (based on the XML Signature standard) for authentication and message integrity.

XML Encryption

Using XML Encryption, SAML 2.0 provides elements for encrypted name identifiers, encrypted attributes, and encrypted assertions (SAML 1.1 does not have encryption capabilities). XML Encryption is reported to have severe security concerns.^[8]

Hypertext Transfer Protocol (HTTP)

SAML relies heavily on HTTP as its communications protocol.

SOAP

SAML specifies the use of SOAP, specifically SOAP 1.1

SAML Use Cases

There are two important use cases for SAML -- Identity Provider Initiated Login, where a user starts directly at their identity provider, logs in, and is then redirected to a landing page at the service provider; and Service Provider Initiated Login, where a user starts by clicking a link to the the service provider (e.g. a bookmark, mailed link, etc) and temporarily redirected to the identity provider for authentication, then returned to the link they initially requested.

Case study

Let's say I have two websites that live on separate domains, and their service providers both talk to the same identity provider on a third domain. I log into the first website and authenticate, and now I decide to visit the second website. The second website comunicates with the identity provider so I don't need to log in again to access my account. How is this achieved using SAML? Is it possible to use cookies in this case?

Solution

In SAML terminology

Identity Provider (IdP) - Provides authentication as a service

Service Provider (SP) - Relies on IdP for authentication of its users

SSO using SAML : let us say there are two services SP1 and SP2 the user wishes to access.

• 1. User visits SP1 and tries to log in. SP1 sends an authentication request to IdP and the user's browser is redirected to IdP where he enters his credentials. After successful authentication the user is again redirected to SP1 and IdP sends an assertion to SP1 which contains authentication information. Now the user is authenticated and may use the services of SP1. In this case the response coming from IdP also contains a cookie to identify the user. This cookie is stored in the browser.

  2. Now the user opens another tab in the browser and tries to access SP2's website. Again as he tries to log in the browser is redirected to IdP and with this redirect the cookies set by the IdP are also sent. The IdP receives the cookie and sends an assertion redirecting the browser back to SP2. The user is logged in to SP2 without needing to enter his credentials again.

Reference

https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

https://tools.ietf.org/html/rfc6595

https://developer.salesforce.com/page/Single_Sign-On_with_SAML_on_Force.com