KPI Partners Blog

by Shiva Molabanti

What is SAML?

SAML is the XML-based Security Assertion Markup Language being standardized at OASIS Security Services. SAML enables single sign-on and other security scenarios, and provides details about the authentication, attribute, and authorization information between security domains. SAML has the specific XML-based protocol by which security information can be transported securely across domains from SAML Authorities i.e. Identity Provider and the SAML Consumers i.e. Service Providers.

The SAML 2.0 is the latest ratified OASIS standard.

Terminology

The SAML architecture is surrounded with the following actors:

Identity Provider (IdP): An Identity Provider (IdP), also known as Identity Assertion Provider, is responsible for issuing identification information for all providers looking to interact / service with the system in any possible way. This is achieved via authentication module which verifies a security token as an alternative to explicitly authenticate a user within a security realm.

An example of this could be an external website allowing users to log in with Facebook credentials. Facebook is acting as an identity provider. Facebook verifies that the user is an authorized user and returns information to the external site such as username and email address (specific details might vary). Similarly, if a site allows login with Google or Twitter, Google and Twitter are acting as the identity provider.

Service Provider (SP): A Service Provider (SP), also known as consumer of SAML assertions, is  your application/resource who wants to be SSO with SAML federated services.

An example of this could be OBIEE, Salesforce.com, Tableau and NetSuite etc…

How does it Work?

At its core, SAML is a series of XML-based messages that detail whether a person has authenticated. SAML is primarily used for SSO between organizations and websites that are “external” to the organization. However, it can be used just as well for internal SSO applications.

The three main components of the SAML specification are:

The two most commonly used SAML assertions:

1. Authentication assertions:  Are those in which the user has proven his identity.

2. Attribute assertions:  Contains specific information about the user, such as an email and phone number.

• Protocol – This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP.

• Binding – This details exactly how SAML message exchanges are mapped into SOAP exchanges.

The assertions are exchanged among sites and services using the protocol and binding, and those assertions are the ones that authenticate users among sites.

Why is SAML Used? And how it is related to Cloud?

The Users authenticate to the enterprise, but resources are increasingly moving to the cloud. How do we allow users to securely access resources spread across multiple providers without spreading user credentials too?

The simple answer is: SSO. There are many ways to achieve single sign-on, and as organizations use an increasing number of cloud applications, support for various methods of single sign-on became too expensive and time consuming.  SAML 2.0, the newest version currently in use, borrows protocols and intellectual property from a number of the most secure frameworks to standardize SSO across all enterprise cloud applications. It enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user. Which means we can configure all applications in an organization including Cloud and On-Premise apps with SAML to allow users to login seamlessly without punching login credentials multiple times. 

A schematic diagram of SAML SSO for Cloud and Enterprise Applications:

 

What are the benefits of SAML?

SAML provides the following benefits with supporting multiple protocols can provide an enterprise-wide, architecturally sound Internet SSO solution.

1. Platform neutrality: SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.

2. Secured: Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class IdM first, which can include strong authentication mechanism, also the user password never crosses the firewall, since user authentication occurs inside of the firewall thus multiple web application passwords are no longer required.

3. Built-in Gateway: “SP-initiated” SAML SSO provides access to web apps for users outside the firewall. If an outside user requests for access to a web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall.

4. Loose coupling of directories: SAML does not require user information to be maintained and synchronized between directories.

5. 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.

6. 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. Centralized federation provides a single point of web application access, control and auditing, which has security, risk and compliance benefits.

7. 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 than that of a service provider

SAML Use Case:

SAML developed three “use cases” to drive its requirements:

1. Single sign-on (SSO)

2. Authorization service

3. Back office transaction

The following process explains how a user logs into a hosted Service Provider application/resource through a partner-operated, SAML-based SSO service:

1. A user first accesses a resource hosted by a web server (the Service Provider) that has SAML content protection enabled.

2. The SP resource/application 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 SP 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. The SP application 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 (IdP) SSO service.

4. The Partner (IdP) decodes the SAML request and extracts the URL for both SP Application’s ACS (Assertion Consumer Service) and the user's destination URL (RelayState parameter). The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.

5. The partner 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 partner's public and private DSA/RSA keys.

6. The partner encodes the SAML response and the RelayState parameter and returns that information to the user's browser. The partner provides a mechanism so that the browser can forward that information to SP Application’s ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to SP resource.

7. The SP Application’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 SP Applications/resources.

Conclusion

SAML is the oldest federation protocol which has the widest adoption. It has proven the viability of organizational federated identity. SAML is the paradigm of good SSO breeding. It has emerged as the go-to SSO protocol for business-to-business (B2B) applications and is an important tool in the enterprise security stack.

Shiva Molabanti is a Director of Technology at KPI Partners.  He is a business intelligence enthusiast who likes blogging about acquisitions in the BI space, technical workings of BI tools, and Oracle Business Intelligence. Visit Shiva at his personal blog or check out Shiva's blog at KPIPartners.com.