Posts Tagged ‘xenc’

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.

Advertisements