Single Sign-On (SSO) for Cloud-based SaaS Applications

Single Sign-On (SSO) is a key capability for Software as a Service (SaaS) applications particularly when there is a need to integrate with existing enterprise applications. In the enterprise world dominated by SOAP-based web services, security has been traditionally achieved with standards like WS-Security, WS-SecurityPolicy, WS-SecureConversation, WS-Trust, XML Encryption, XML Signatures, the WS-Security SAML Token Profile, and XACML.

During the last few years, the popularity of Web APIs, mobile technology, and Cloud-based software services has led to the emergence of light-weight security standards in support of the new REST/JSON paradigm with specifications like OAuth2 and OpenID Connect.

In this post, I discuss the state of the art in standards for SSO.

SAML2 Web SSO Profile

SAML2 Web SSO Profile (not to be confused with the WS-Security SAML Token Profile mentioned earlier) is not a new standard. It was approved as an OASIS standard in 2005. SAML2 Web SSO Profile is still today a force to reckon with when it comes to enabling SSO within the enterprise. In a post titled SAML vs OAuth: Which One Should I Use?, Anil Saldhana, former Lead Identity Management Architect at Red Hat offered the following suggestions:

• If your usecase involves SSO (when at least one actor or participant is an enterprise), then use SAML.
• If your usecase involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc), then use OAuth.
• If you need to provide access to a partner or customer application to your portal, then use SAML.
• If your usecase requires a centralized identity source, then use SAML  (Identity provider).
• If your usecase involves mobile devices, then OAuth2 with some form of Bearer Tokens is appropriate.

Salesforce.com who is arguably the leader in cloud-based SaaS services supports SAML2 Web SSO Profile as one of its main SSO mechanisms (see the Salesforce Single Sign-On Implementation Guide). The Google Apps platform supports SAML2 Web SSO Profile as well.

Federal Identity, Credential, and Access Management (FICAM), a US Federal Government initiative has selected SAML2 Web SSO Profile for the purpose of Level of Assurance (LOA) 1 to 4 as defined by the NIST Special Publication 800-62-2 (see ICAM SAML 2.0 Web Browser SSO Profile). This is significant given the challenges associated with identity federation at the scale of a large organization like the US federal government.

SAML bindings specify underlying transport protocols including:

• HTTP Redirect Binding
• HTTP POST Binding
• HTTP Artifact Binding
• SAML SOAP Binding.

SAML profiles define how the SAML assertions, protocols, and bindings are combined to support particular usage scenarios. The Web Browser SSO Profile and the Single Logout Profile are the most commonly used profiles.

Identity Provider (idP) initiated SSO with POST binding is one the most popular implementations (see diagram below from the OASIS SAML Technical Overview for a typical authentication flow).

The SAML2 Web SSO ecosystem is very mature, cross-platform, and scalable. There are a number of open source implementations available as well. However, things are constantly changing in technology and identity federation is no exception. At the Cloud Identity Summit in 2012, Craig Burton, a well known analyst in the identity space declared:

 SAML is the Windows XP of Identity. No funding. No innovation. People still use it. But it has no future. There is no future for SAML. No one is putting money into SAML development. No one is writing new SAML code. SAML is dead.

 Craig Burton further clarified his remarks by saying:

SAML is dead does not mean SAML is bad. SAML is dead does not mean SAML isn’t useful. SAML is dead means SAML is not the future.

At the time, this provoked a storm in the Twitterverse because of the significant investments that have been made by enterprise customers to implement SAML2 for SSO. 

WS-Federation

There is an alternative to SAML2 Web SSO Profile called WS-Federation which is supported in Microsoft products like Active Directory Federation Services (ADFS), Windows Identity Foundation (WIF), and Azure Active Directory. Microsoft has been a strong promoter of WS-Federation and has implemented WS-Federation in several products. There is also a popular open source identity server on the .NET platform called Thinktecture IdentityServer v2 which also supports WS-Federation.

For enterprise SSO scenarios between business partners exclusively using Microsoft products and development environment, WS-Federation could be a serious contender. However, SAML2 is more widely supported and implemented outside of the Microsoft world. For example, Salesforce.com and Google Apps do not support WS-Federation for SSO. Note that Microsoft ADFS implements the SAML2 Web SSO Profile in addition to WS-Federation.

OpenID Connect

OpenID Connect is a simple identity layer on top of OAuth2. It has been ratified by the OpenID Foundation in February 2014 but has been in development for several years. Nat Sakimura's Dummy’s guide for the Difference between OAuth Authentication and OpenID is a good resource for understanding the difference between OpenID, OAuth2, and OpenID Connect. In particular, it explains why OAuth2 alone is not strictly an authentication standard. The following diagram from the OpenID Connect specification represents the components of the OpenID Connect stack (click to enlarge).

Also note that OAuth2 tokens can be JSON Web Token (JWT) or SAML assertions.

The following is the basic flow as defined in the OpenID Connect specification:

1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

There are two subsets of the Core functionality with corresponding implementer’s guides:

• Basic Client Implementer’s Guide –for a web-based Relying Party (RP) using the OAuth code flow
• Implicit Client Implementer’s Guide – for a web-based Relying Party using the OAuth implicit flow

OpenID Connect is particularly well-suited for modern applications which offer RESTful Web APIs,  support JSON payloads, run on mobile devices, and are deployed to the Cloud. Despite being a relatively new standard, OpenID Connect also boasts an impressive list of implementations across platforms. It is already supported by big players like Google, Microsoft, PayPal, and Salesforce.  In particular, Google is consolidating all federated sign-in support onto the OpenID Connect standard. Open Source OpenID Connect Identity Providers include the Java-based OpenAM and the .Net-based Thinktecture Identity Server v3.

From WS* to JW* and JOSE

As can be seen from the diagram above, a complete identity federation ecosystem based on OpenID Connect will also require standards for representing security assertions, digital signatures, encryption, and cryptographic keys. These standards include:

• JSON Web Token (JWT)
• JSON Web Signature (JWS)
• JSON Web Encryption (JWE)
• JSON Web Key (JWK)
• JSON Web Algorithms (JWA).

There is a new acronym for these emerging JSON-based identity and security protocols: JOSE which stands for Javascript Object Signing and Encryption. It is also the name of the IETF Working Group developing JWS, JWE, and JWK. A Java-based open source implementation called jose4j is available.

Access Control with the User Managed Access (UMA)

According to the UMA Core specification,

User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.

In the UMA protocol, OpenID Connect provides federated SSO and is also used to convey user claims to the authorization server. In a previous post titled Patient Privacy at Web Scale, I discussed the application of UMA to the challenges of patient privacy.

Patient Privacy At Web Scale

A study entitled Patients want granular privacy control over health information in electronic medical records by Kelly Caine and Rima Hanania in the current issue of the Journal of the American Medical Informatics Association (JAMIA) clearly indicates that patients want a granular level of control over the sharing of their medical information. Patients also want to control with whom their health information is shared and for what purpose. The study looks at how the presence of sensitive health information in a medical record affects patient privacy preferences. In this post, I discuss how current and emerging standards can be used to enforce patient privacy preferences at web scale.

First, I think the key to achieving patient privacy at web scale is to adopt proven light-weight protocols and standards such as REST, JSON, OAuth2, and OpenID Connect. The RESTful Health Exchange (RHEx) project funded by the Federal Health Archicture (FHA) was a step in the right direction. These protocols have also been embraced by large internet identity providers like Google, Facebook, and Microsoft. To increase the strength of authentication when using these existing online identities in patient-facing healthcare applications, techniques like multi-factor authentication (e.g., two-factor authentication using the user's phone) and adaptive risk authentication can be used. These light-weight standards and protocols contrast with enterprise-centric alternatives like SOAP and SAML which are the foundation for Integrating the Health Enterprise (IHE) standards including XDS.b, XDR, and XUA.

An emerging approach that could really help put patients in control of the privacy of their electronic medical record is the User-Managed Access (UMA) Protocol of the Kantara Initiative. According to the UMA Core specification:

User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy.

That sounds a lot like a healthcare environment where a typical patient has her health information residing in the Electronic Health Record (EHR) systems of multiple healthcare providers. A frequent use case is when the patient's health information is shared among providers during primary care physicians' referrals to specialist outpatient clinics. The following are the benefits for the patient privacy of a centralized authorization server as defined in UMA:

• The ability to manage her consent directives (scope of access in UMA parlance) from a central location (ideally in the cloud) as opposed to the current paper-based environment where the patient signs a consent form for each provider and has no visibility into how the consent is being used and enforced.
• It facilitates the update and revocation of the consent directives by the patient. 
• It would give the patient a full audit trail of requests and access events related to her health information.
• The patient user experience of managing their privacy preferences online can be significantly enhanced by data visualization. A study titled Exploring Visualization Techniques to Enhance Privacy Control UX for User-Managed Access introduced the notion of a "UMA Connection" for helping users visualize the context of a data sharing policy (e.g., contacts, allowed actions, access restrictions, and trusted claims).

In UMA, trusted claims (e.g., information about a requesting healthcare provider such as email, name, role, organization, and NPI) can be conveyed using OpenID Connect. The Google OpenID Connect Demo provides a step by step guide to OpenID Connect and Nat Sakimara's Dummy’s guide for the Difference between OAuth Authentication and OpenID is a good explanation of how OpenID Connect complements OAuth2. A separate specification entitled Binding Obligations on User-Managed Access (UMA) Participants proposes a legal framework that defines the obligations of parties that operate and use UMA-conforming software programs and services.

A recent post by Domenico Catalono entitled UMA Approach to Protect and Control Online Reputation describes a UMA-based approach for supporting privacy based on reputation and trust.  An example in the post is a "global reputation ranking" in the context of an online e-commerce site. In the context of healthcare privacy, when deciding to share their sensitive medical information with a specific healthcare provider, the same concept could be used to display the number and severity of security breaches experienced by the healthcare provider in the past. Section 13402(e)(4) of the HITECH Act actually requires posting a list of breaches of unsecured protected health information affecting 500 or more individuals. The list is available here.

The recently approved XACML 3.0 standard is a powerful mechanism for expressing and evaluating privacy policies. It provides capabilities such as obligation and advice expressions as well as delegation of authorization. In this presentation, Eve Maler discusses possible integration points between UMA and XACML.  The REST Profile of XACML 3.0 and the Request/Response Interface based on JSON and HTTP for XACML 3.0 proposals introduce the notion of "RESTful Authorization-as-a-Service (AZaaS)" which can facilitate the use of XACML in a UMA-based access control environment.