Gigya is now SAP Customer Data Cloud. Learn more
Forrester logo Download the report

The Basics of SAML

What Is SAML?

Security Assertion Markup Language (SAML) originated in 2001. It is a standard that represents an XML-based framework for user authentication and authorization between two entities; particularly, service providers (SPs) that host Web applications and services and identity providers (IdPs) that provide and maintain digital user identities, such as Facebook, Google+ and LinkedIn. In 2005, SAML 2.0 was announced as an OASIS standard, and, to this day, remains the most popular method of user authentication and authorization for cloud-based transactions.

Why Organizations Use SAML

As organizations of all kinds move their infrastructure, services and data to the cloud, SAML provides a secure method of authenticating and authorizing users across an expanding universe of platforms, digital touchpoints and devices. SAML enables more robustly-connected systems by enabling easier access to Web applications for consumers and other users not provisioned internally by IT.

SAML eliminates the need for multiple Web application passwords by enabling a token-based authentication exchange that takes place inside the IdP firewall between the IdP (who holds the user credentials) and the SP. During an “SP-initiated” SAML transaction, when a user requests access to an application, the SP automatically redirects them to the IdP, where the user is authenticated without ever passing personal information to the SP’s system.

SAML solves a key challenge by enabling single sign-on (SSO) functionality: allowing users to register or log in and be authorized across multiple properties with a single set of credentials for a set period of time. SAML also enables single logout functionality, ensuring that when users sign out of one site, they are automatically logged out of all other service providers owned by that company.

Single Sign On (SSO) basics transaction flow between service and identity providerHow It Works

Here’s a visualization of a typical SAML transaction between a service provider and an identity provider, in eight steps:

  1. The user attempts to reach a Google-hosted service or application.
  2. The service (application) partner generates a SAML authentication request, which is encoded and embedded into the URL for the partner’s SSO service. A parameter, set up as an identifier, is passed back without any modification or inspection.
  3. The application sends a redirect to the user’s browser, which includes the encoded SAML authentication request to be submitted to the partner’s SSO service.
  4. The identity partner decodes the SAML request and authenticates the user.
  5. The identity partner generates a SAML assertion that contains the authenticated user’s identity and attributes.
  6. The encoded SAML response is passed back to the browser, and then the browser sends the response to the Access Control Server (ACS) URL.
  7. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner’s public and private DSA/RSA keys.
  8. The user is logged into the Google-hosted application.

Federated Data

SAML uses XML “assertions” to authenticate and authorize users, and also to communicate predefined attributes about users between IdPs and SPs. SAML SSO also “federates” all user data, providing a single view of user profiles across the entire organization for Web application access, control and auditing. This process ultimately allows structure to be added to disparate data types, leading to richer, more actionable user profiles.

Here’s a look at the kind of attributes that are collected when a hypothetical subscription-based television site uses SAML to authenticate users versus another standard. SAML Federated Data Example

For large organizations with multiple sites, SAML also enables more robust user access options, since subscription and membership information—or any other specified attributes for that matter—can be communicated within the transaction itself. So how does SAML achieve this?

Know Your “APB”s

The three components of SAML are assertions, protocol and binding. Assertions carry authentication, user attribute and authorization data, as in the following subscription television example: SAML: Authentication, user attribute and authorization data for Assertions

Protocol refers to how data is transmitted between SAML partners. Standard Web communication protocols are supported (HTTP, SMTP, FTP) as well as some Web services protocols (SOAP, BizTalk, and Electronic Business XML (ebXML).

Binding determines how SAML requests specifically map to these protocols. For example, an IdP-supported binding for an AuthnRequest call might be HTTP Redirect.

Getting SAML SSO Right

SAML implementation has many moving parts and requires careful planning. To achieve a working system, IT professionals must predefine their endpoint configuration as well as the configuration of the sender and receiver. Your system needs to be compatible with the SSO standard, and you’ll need an interface that accommodates your end users.

A solid SAML SSO implementation should fulfill these key elements:

  • Enable seamless and secure login and logout functionality for internal and external users across your entire stack
  • Allow external users to access any permitted Web application or service, from any permitted device
  • Federate all identity data to help build unified user profiles and provide business leaders with a single customer view across every channel

By David Kerin

Gigya has updated its Privacy Policy as Gigya, Inc. has been acquired by SAP America, Inc. and Gigya has updated the information regarding how we collect and use your Personal Data. You can see the updated Privacy Policy here.