By Pat Patterson, Principal Developer Evangelist, Salesforce.com
Digital identity is becoming increasingly important as enterprises strive to protect and control access to online resources. A series of maturing standards is helping make identity management and single sign-on a reality for organizations deploying systems.
As 2013 came to a close SecureIDNews.co
It’s a familiar scene: sitting in front of a web page with two input fields, user name and password, racking your brain to dredge up the magic combination that will grant access to the web site for your bank, a social network, or your company’s health care provider.
Sometimes, though, you see an out – a button that says “Login with Facebook, Google or Twitter” – or you click a link on an intranet page at your company and are taken straight to your health care benefits page, without having to authenticate. You breathe a sigh of relief, but have you ever wondered what’s happening under the covers, and how you might apply the same magic yourself? Welcome to the world of single sign-on.
There are several protocols that enable web sites like Google, Facebook, and even your own employer, to assert their users’ identities to sites like Quora, Workday or Concur. The big Internet service providers are gathering around a specification called OpenID Connect, but in the enterprise world, the Security Assertion Markup Language version 2.0, or SAML (pronounced SAM-ul) for short, rules the roost.
SAML 2.0, ratified as an OASIS Standard in March 2005, comprises a number of specification documents that comprehensively define how to represent identity information and pass it between interested parties.
First, a bit of necessary jargon: a subject logs in to an identity provider, which asserts the user’s identity to one or more service providers. In the enterprise case, the identity provider might be a software product deployed on-premise, such as ForgeRock OpenAM, or an online service, such as Salesforce Identity.
The service provider, meanwhile, could be an online service such as Workday or Concur, or even an intranet site, such as the enterprise’s payroll department.
So, how does the identity provider “assert” the subject’s identity? The SAML 2.0 Web Browser SSO Profile defines a number of related mechanisms for passing the information between the providers. Here’s one of the most common: using Salesforce Identity as the identity provider and Workday as the service provider.
You (the subject) try to access Workday, via a URL specific to your company. Workday receives your request, sees that you’re not currently logged in (since your browser didn’t present a session cookie with the request), looks up the URL for the identity provider at Acme, creates a SAML Request, and sends it to the URL via an HTML form post.
The SAML Request is an XML document that essentially says, “Send me a SAML Assertion concerning this subject.” It typically contains an identifier for the service provider, so the identity provider knows who sent the request, but may also contain additional instructions – for example, the ForceAuthn attribute requires that the identity provider prompts the user to authenticate, even if the user already has an existing session.
Upon receipt of the SAML Request, the identity provider authenticates the user, if necessary. This authentication step is outside the SAML specification – it can be username/password, a hardware token, biometric – just as long as the identity provider establishes the user’s identity via an appropriate mechanism.
After successful authentication, the identity provider creates a SAML Assertion. This is the centerpiece of the SAML spec, a signed XML document identifying the user and asserting that the identity provider has authenticated that user. At minimum, the Assertion contains an identifier for the user (email address, for example), a timestamp, and a reference to the authentication mechanism, perhaps “password over SSL/TLS.” The identity provider wraps the Assertion in a SAML Response and sends it back to the service provider, again via an HTML form post.
Now the service provider can validate the SAML Assertion, checking that a trusted identity provider signed it and issued the user a session cookie. The user has access, just as if they’d authenticated at the service provider directly, simply by hitting the Workday/Acme URL. Job done!
So, the SAML 2.0 Web Browser SSO Profile is the basis for enterprise single sign-on, but SAML as a whole can do much more. Since the actual authentication step is outside the scope of SAML, you can embed any protocol there – biometric authentication, or Integrated Windows Authentication perhaps. SAML itself can be embedded in other protocols, such as OAuth, and the SAML Assertion is widely used as a token format for communicating identity, authentication and authorization data across the web and within enterprises.
At the ripe old age of eight, SAML is the “Granddaddy of Internet identity protocols.” Internet providers and enterprise products almost ubiquitously support it, but to a certain extent it represents the “old guard” of protocols – an XML-based, voluminous specification that tries to address every possible use case.
The past and present belong to SAML, but most identity pundits point to OpenID Connect as the future, a lighter-weight JSON-based protocol that implements the most common single sign-on use cases.