Posts Tagged ‘SSO’

Introduction to OAuth 2.0, OpenID Connect, and SCIM

2015/04/16

The development of SAML dates from January 2001. As discussed in an earlier post, SAML 2.0 provides a Single Sign On (SSO) authentication and authorization protocol that many view as applicable primarily for federations of enterprises. Mobile applications and dominant Internet applications such as Salesforce, Facebook, Google Apps, Linked In, etc. were providing more or less independent and light-weight “micro-services” fronted by APIs. SAML was deemed too heavy-weight to be supported by such APIs.

By 2014, authentication, authorization, and delegation (of authorized rights) for APIs, are embodied in the standards OAuth, OpenID Connect, and SCIM. These standards call for authentication and access tokens encoded in JavaScript-like Object Notation JSON rather than SAML’s (somewhat more verbose) XML. These JSON tokens are then passed in HTTP headers.

OAuth 2.0 has evolved to be a base technology for authorization, but it’s hard to do authorization without knowing to whom or to what you’re giving rights, and thus authentication sneaks in to the standard. To better address this, OpenID Connect has evolved from earlier versions of OpenID and other security work done by vendors to become a layer on top of OAuth 2.0 for authentication. It would seem that these two standards should merge.

While the proponents of OAuth and OpenID Connect predict that they will eventually supersede SAML, this doesn’t seem likely in the near future as SAML seems to do quite well for enterprises with existing relationships such as supply chains and portals. In addition, there are some use cases where the co-existence of SAML, OAuth, and OpenID Connect seems natural in spite of some duplication of functionality.

Finally SCIM, the System for Cross-domain Identity Management, addresses cross-domain identity management and specifically provides REST APIs for provisioning, change, and de-provisioning, all of which lie outside the realm of OAuth and SAML. SCIM adds considerable complexity to identity management systems, and I’m a little nervous that the initial implementations will have security problems. On the other hand, neglecting these functions is probably worse for security.

My next few IAM posts will discuss the latest versions for each of OAuth, OpenID Connect, and SCIM. I’ll also work an example of co-existence with SAML. The OAuth 2.0 post is next. It is here.

Advertisements

SAML 2.0 – Secure Assertion Markup Language

2015/04/01

SAML 2.0 is one of several protocols used today to support Internet Single Sign On (SSO). It is a rich, some would say “heavy duty”, protocol with hundreds of pages of documentation [1, 2, …]. This post is an overview/introduction.

SAML 2.0 defines three parties: a principal (user) U, a service provider SP, and an identity provider IdP who exchange authentication and authorization data encoded in XML statements, which are sent from one party to another using a binding [2] such as HTTP or SOAP.

SAML statements consist of assertions and queries. An assertion is an XML statement of the form

<saml:Assertion ..> … </saml:Assertion>.

As usual in XML, the double dot consists of modifiers and the triple dot consists of child elements that further define the assertion. This XML statement is interpreted as: an assertion A issued at time T by issuer I regarding subject S provided conditions C are valid. The XML modifiers and child elements define, in particular, A, T, I, S, and C.

There are three types of SAML assertion:

  1. Authentication assertions that assert to SP that S authenticated with IdP at time T using method M.
  2. Attribute assertions about S having (attribute_name, attribute_value) properties.
  3. Authorization decision assertions that assert S is permitted to perform action A on resource R given evidence E.

For example, some of the relevant assertion child elements defined are <saml:AuthnStatement>, <saml:AttributeStatement>, <saml:Subject>, <saml:Issuer>, and <saml:Conditions>.

Correspondingly there are three types of SAML queries:

  1. Authentication query
  2. Attribute query
  3. Authorization decision query

Now you might think (as I initially did) that SAML 2.0 would have an XML query statement that corresponds to the XML assertion statement. Sorry, it doesn’t exist! Instead, SAML 2.0 defines the following protocols for how SAML elements are packaged within queries and responses and how they are produced and consumed:

  1. Assertion Query and Request Protocol – to request new and existing assertions. The Request form asks for an existing assertion by referring to its assertion ID. The Query form asks for new or existing assertions by subject and statement type.
  2. Authentication Request Protocol – for a user to retrieve authentication assertions. Used when redirecting a user from an SP to an IdP when a security context for the user is needed at the SP.
  3. Artifact Resolution Protocol – to go from reference (artifact number) to value. Allows assertions to be passed around efficiently by reference.
  4. Name Identifier Management Protocol – provides mechanisms to change the value or format of a principal’s name identifier; informs SPs that names and name formats are changed
  5. Single Logout Protocol – kills all sessions provided by a session authority.
  6. Name Identifier Mapping Protocol – maps user identities across different SPs.

The saml: XML prefix in SAML 2.0 marks the assertion name space. Similarly, the samlp: XML prefix marks the protocol namespace. There are five other prefixes: ds:, xenc:, xs:, and xsi: respectively for digital signatures, XML encryption, the default namespace, and schema related markup.

Queries use the samlp: prefix and look like

<samlp:AuthnRequest> requests <saml:AuthnStatement> assertions

<samlp:AttributeQuery> requests <saml:AttributeStatement> assertions.

<samlp:ArtifactResolve> requests a <samlp:ArtifactResponse>

Example:

<samlp:AttributeQuery ..>

<saml:Issuer>

http:sample.sp.com

</saml:Issuer>

<saml:Subject>

<saml:NameID ..>

u@ex.com

</saml:NameID>

<saml:Attribute .. FriendlyName= “givenName”>

</saml:Attribute>

</AttributeQuery>

Here Issuer sample.sp.com is requesting the attribute whose FriendlyName is givenName for the subject whose email address is u@ex.com. The double dots represent additional modifiers. This query is sent to an IdP via a binding, and the IdP must return to the Issuer a saml:AttributeStatement assertion inside a <samlp:Response>.

Example:

<saml:AttributeStatement>

<saml:Attribute .. FriendlyName= “givenName”>

<saml:AttributeValue ..>

Mary

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

Filling in the double dots, the Response overhead to match query numbers with the response numbers, the binding overhead, the Statement IDs, the Status codes, etc. isn’t difficult, but they all make the SAML 2.0 specification long and tedious. Fundamentally, SAML 2.0 needs to be flexible enough to deal with multiple name stores (X500, Active Directory, LDAP, etc.) as Issuers, multiple applications as Service Providers (SPs) that have different needs, multiple IdPs, the metadata that identifies SPs and IdPs, multiple data formats, multiple Conditions, multiple encryption, hash, signature, and certificate methods, etc. In addition, SAML 2.0 defines profiles, which describe in detail how assertions, protocols, and bindings combine to implement use cases. For me, it seems like the different profiles add possibly unneeded complexity, but good people worked on SAML 2.0 for a long time and undoubtedly determined that this complexity was necessary.

SP initiated authentication

The Service Provider, SP, initiates the authentication process using a <samlp:AuthnRequest> … </samlp:AuthnRequest> statement to the identity provider IdP. The flow goes like this:

  1. Via a browser, the user requests access to a resource on Service Provider SP.
  2. Assuming the user has no security context, SP sends the user an HXTML form that contains a <samlp:AuthnRequest>.
  3. The user issues a HTML POST request to the SSO service at the identity provider IdP with the AuthnRequest.
  4. The SSO service at IdP validates the request and responds with an XHTML form that contains a <samlp:Response ..>…</samlp:Response> which contains Issuer, Status, Signature, Subject, etc. info needed by the service provider SP.
  5. The user issues a HTML POST request to the assertion consumer service at SP containing the AuthnResponse.
  6. The assertion consumer service at SP processes this response and creates a security context, and redirects the user to the target resource.
  7. With this security context in place, the user again requests the resource from SP,
  8. The request is granted.

When a security context is in place, steps 2 through 7 can be skipped.

IdP initiated authentication

When the client wants to explore certain areas of the web, it can request authentication by an IdP associated with such an area. After authentication and the establishment of an acceptable trust relationship, the IdP can give the client a list of trusted portal web sites through which the client can pass for further exploration. Examples might be certain military or political areas, areas for certain types of private information such as photographs or private financial transactions, and even restricted research areas.

Registration and Trust Models

Sometimes registration is called provisioning. Prior to any authentication or authorization tokens being created, the IdP needs both users and service providers to register in such a way that there is a trust relationship established that is satisfactory to all of the parties. Usually this involves each party accepting the other’s certificate which comes from a chain of trust whose ultimate root is trusted.

Each IdP thus obtains a list (or database) of SPs for which there is mutual trust. Also, each SP thus obtains a list of IdPs that it trusts and that knows what it needs for authentication and authorization.

SAML 2.0 has many interesting use cases, about which there will be future posts. My next IAM post is here.