SAML

General Description

SAML is an authentication protocol that allows exchanging security assertions between parties to enable SSO service [OAS08]. These parties are security domains with trust relationships established between them, thus SAML enables enterprise authentication. The main principle of the protocol’s operation is similar to OpenID discussed in Section 3.2.1. However, unlike in OpenID, collaboration between a relying party and an identification provider using SAML is performed only if the parties have a trust relationship and potentially additional information utilisation contracts.

SAML involves three parties: SP, UA and IdP. A SP provides a service valuable to the user. A UA is used by a human user, i.e. the subject, to obtain access to a service provided by a SP. Typically, UA is a desktop or mobile web-browser. An IdP provides SP with identity information related to the subject. In a typical scenario, when a user requests access to a service using his/her UA, UA is redirected to the IdP where the user has to prove his/her identity. Upon successful authentication, IdP sends identity information, including authorisation and authentication-related attributes, as assertions back to SP.

3.2. USER-ORIENTED IDM SYSTEMS 19

version 1.1 with Shibbolleth and Identity Federation Framework (ID-FF), developed by Liberty Alliance [Ora10]. Earlier protocol versions 1.0 and 1.1 are now deprecated, thus further discussion addresses protocol version 2.0.

SAML protocol is comprised of the three following components [OAS05a]:

1. Messages that encapsulate data, e.g. security assertions;

2. Bindings that specify the means for transporting SAML messages;

3. Profiles that specify complete combinations of bindings that can be used to perform authentication and authorisation.

SAML protocol messages are based on Extensible Markup Language (XML) format. The fundamental SAML message type is security assertions, which contain statements about a subject’s attributes and rights. A single assertion message contains one or more statements of the following types:

1. Authentication Statement that provides information about the authentica- tion process, e.g. time and method and result of subject authentication. 2. Authorisation Decision Statement that indicates whether access to a

requested resource has been granted.

3. Attribute Statement that provides additional information about the authen- ticated subject.

Assertions also contain information about the issuer of the message, general information about the subject and potentially indicate conditions of token’s validity. For example, a token may be valid at a specific period of time.

SAML also includes Authentication Request and Artifact Resolution message types. Authentication Request specifies messages used for initiation of subject authentication in the IdP, which are sent from the SP. Artifact Resolution messages enable SP and IdP exchange message references, which are afterwards resolved in order to obtain the content of the messages.

Besides message formats, SAML protocol specifies bindings and profiles. Bindings [OAS05b] define how the messages are sent, and profiles [OAS05c] describe a com- bination of bindings used for communication among specific parties. For example, Hypertext Transfer Protocol (HTTP) Redirect Binding enables adding the SAML message into URL query string of a HTTP message. However, due to URLs length limit, this option is suitable only for short messages, such as Authentication Requests.

Alternatively, POST Binding enables putting a transferred message into a HTTP form that is forwarded to another party (SP or IdP) through a UA. Furthermore, HTTP Artifact Binding profile enables using UA to transfer message references as Artifact Messages, which are used by the receiver to directly contact the sender and obtain the actual message content.

Operation of SAML 2.0

SAML communication sequence begins when a subject uses his/her UA to access a resource in a SP [OAS05c]. This invokes a security check for a given resource at the SP. If the particular SP already contains a user-related security context, it simply checks the context for subject’s rights to access the resource and afterwards returns the resource. Otherwise, SP tries to obtain information about the user from an IdP it already knows about or discovered using the Identity Provider Discovery protocol.

After obtaining information about the IdP, a SP creates a request for IdP that includes authentication request message and RelayState parameter describing the location of SP. This request is forwarded to IdP by the UA. After receiving the request, IdP checks if it has a security context created for the requested user identity and, if not, requests the user to prove his/her identity. The SAML protocol standard does not specify authentication mechanisms for the IdP, thus passwords, allowing utilisation of certificates or any stronger type of authentication. After successful authentication, IdP creates a security context related to the user identity, meaning that the user is logged in the IdP and future assertion requests are handled without the need for the user to re-authenticate, thus enabling SSO service.

After authentication, IdP validates the request of SP and sends a response back through the UA. The response contains security assertions and RelayState parameter value initially issued by the SP. When forwarding the response to SP through UA, the user might be asked for consent to transfer his/her information to the SP.

Assertion Consumer (AC) validates the response, creates a security context for the user at the SP for this and future uses and redirects the UA to the requested resource.