7. An overview of SAML v2.0

SAML v2.0 was approved as an OASIS standard in March 2005. In broad terms, this standard defines the SAML Assertions, Protocols, Bindings (to bind the messages to the communication protocols), and SAML Profiles reflecting a defined use case, together with the applicable XML Signature and Encryption standards from W3C.

A high level description is provided below. Additional background is provided in Appendix A. Detailed prescriptions of these for New Zealand government implementations are provided in NZ SAMS.

SAML Assertions

There are three types of assertion statements that can be made by a SAML authority. All statements are associated with a subject or person. The three statements are:

• Authentication: This user was authenticated by a particular means at a particular time, e.g. The user jb1234 successfully logged in with a password at 10:45am on the 14th of March 2006. This confirmation of identity is used in the all-of-government authentication service.
• Attribute: This user is associated with the specified attributes, e.g. The user jb1234 has the role of Chief Financial Officer. These identity-related attributes are important for the verification of identity used in the proposed all-of-government Identity Verification Service.
• Authorisation Decision: A request to allow the user to access a specified resource is granted or denied. For any particular transaction, a user can be successfully authenticated, but they may not be given access to a resource as they may not have the appropriate authorisation level.

The SAML v2.0 specification set defines how SAML assertions are formatted so that any compliant product or system can successfully use them.

NZ SAMS, the New Zealand government prescription for SAML v2.0 deployment, is working through the SAML v2.0 specification in the order listed above, starting with Authentication.

SAML Protocols

SAML Protocols define how SAML assertions are transported between participants. SAML assertions can be generated and exchanged between identity and service providers using a variety of request-response protocols. These protocols are XML-based and are in the form of request-response pairs, which detail what information or action is requested and how this is responded to. These request-response protocols are then mapped to transport protocols. This is called binding. An example of this would be mapping a ‘request for an assertion’ (request-response protocol) embedded in SOAP over HTTP (transport protocol).

The protocols defined within the SAML specification achieve the following actions:

• Returning one or more requested assertions. This is either in response to a direct request for specific assertions, or a query for assertions that meet particular criteria.
• Performing authentication upon request and returning the corresponding security assertion.
• Registering a name identifier or terminating a name registration upon request.
• Retrieving a message that has been requested by means of an artifact.
• Performing a single logout of related sessions.
• Providing a mechanism to link name identifiers on federated sites.

SAML Bindings (Message Transports)

There are a variety of bindings defined for the transport of SAML messages between participating parties. The SAML v2.0 bindings are:

• SAML SOAP Binding. SAML messages may be exchanged using the well-defined SOAP protocol. A discussion of the SOAP protocol is included in Appendix A. SOAP messages may be transported over a variety of underlying network transport technologies, however, the SAML specification mandates the implementation of SOAP over HTTP.
• Reverse SOAP Binding. SAML messages may also be exchanged via Reverse SOAP, where an HTTP requestor can advertise the ability to act as a SOAP responder to a SAML requester.
• HTTP Redirect Binding. The SAML HTTP Redirect binding provides the SAML standard with a mechanism for transmitting a SAML message within the URL of a HTTP request. This is typically required when there is no direct path available between an Identity Provider and a Service Provider, in which case the SAML message has to be transported indirectly, typically via the end user’s web browser.
• HTTP Post Binding. SAML messages may be transmitted within the content of a HTML form posted to a service provider.
• HTTP Artifact Binding. A SAML HTTP Artifact is a mechanism that allows a browser to provide a reference to a SAML message rather than providing it directly. This situation arises when the browser’s limitations preclude or discourage the transmission of an entire SAML message.
• URI Binding. A SAML URI reference identifying a specific SAML assertion can be passed in an HTTP URI.

SAML Profiles

A SAML Profile is a way to define how SAML assertions, protocols and bindings are combined to specify a particular use case. The aim of a profile is to remove some of the ambiguity in applying SAML that arises from SAML’s flexibility. A profile can be used to define constraints and/or extensions of SAML to enhance its suitability for a particular usage or application. For example, the Web Browser SSO Profile specifies how identity federation can be enabled for a user’s web browser session by specifying the manner in which SAML authentication assertions are communicated between an Identity Provider and Service Provider.

Profiles can also be attribute-based, providing rules for the interpretation of attributes within an assertion. An example of this would be to describe how X.500 attributes are carried with identity attribute assertions.

XML Signatures and Encryption

SAML assertions and SAML protocol request and response messages may be digitally signed and/or encrypted.

A digitally signed SAML message means the receiving party can be confident that the message has not been altered in transit and was provided by the party that it appears to have originated from.

Parts of SAML messages may be encrypted for confidentiality purposes. This can be done to protect the privacy of individuals or to protect organisational secrets. Encryption may also be used to ensure the effectiveness of some other security mechanism, e.g. the exchange of a password.