SAML Profiles


Generally, a profile of SAML defines constraints and/or extensions in support of the usage of SAML for a particular application – the goal being to enhance interoperability by removing some of the flexibility inevitable in a general-use standard. For instance, the Web Browser SSO Profile specifies how SAML authentication assertions are communicated between an identity provider and service provider to enable single sign-on for a browser user.

SAML 2.0 Profile Initial URLs#

The SAML 2.0 specification defines the endpoints that are to be used for partner-to-partner communications but it does not define the way in which users can initiate a single sign-on action using those endpoints.

In a typical SAML 2 environment, specially formed URLs that incorporate the single sign-on action to take, the binding to be used for the action, and the location where the action should take place can be used for user-initiated single sign-on actions. These URLs are referred to as profile initial URLs and should be provided within the SAML Metadata.

Architects and application developers, who will design and implement their users' interaction with the single sign-on process, will need to understand profile initial URLs and incorporate them into their Web applications.

The following sections describe the format of the SAML 2.0 profile initial URLs that are supported in a Tivoli Federated Identity Manager Business Gateway environment.

Assertion Consumer Service SP#

In a SAML 2.0 federation, the assertion consumer service URL can be initiated at the identity provider server site or the service provider site. This topic describes the syntax for initiating single sign-on at the service provider.

Single Sign On Profile IDP#

In a SAML 2.0 federation, the Single Sign On Service URL can be initiated at the IDP server site or the SP site.

Single Logout Profile#

In a SAML 2.0 federation, the single logout service URL is used by a partner to contact the Single logout profile. The URL to initiate the service has the following syntax:

Name Identifier Management Protocol#

In a SAML 2.0 federation, the Name Identifier Management Protocol URL is used by a partner to contact the Name Identifier Management service. The URL to initiate the service has the following syntax:

The Web SSO Profile details how to use the SAML Authentication Request/Response protocol in conjunction with different combinations of the HTTP Redirect, HTTP POST, HTTP Artifact, and SOAP bindings.

Another type of SAML profile is an attribute profile. SAML defines a series of attribute profiles to provide specific rules for interpretation of attributes in SAML attribute assertions. An example is the X.500/LDAP profile, describing how to carry X.500/LDAP attributes within SAML attribute assertions.

Bindings and profiles connect SAML with the wire

A "profile" is a pattern for how to make assertions about other information.

For example, currently there Two browser profiles for SSO

  • artifact
  • POST SOAP profile for securing SOAP payloads

Profiles are sort of like choreography templates. SAML is intentionally desgined to be very flexible and profiles give you a way to standardize on particular flows of SAML-related data in order to secure some other traffic.

The SAML committee is standardizing some of these, but the intention of seeing more created by others. We hope that these will be standardized by some body, or at least openly specified.

SAML profiles[1]#

A SAML profile describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case. The most important SAML profile is the Web Browser SSO Profile.

SAML 1.1 profiles#

SAML 1.1 specifies two profiles, the Browser/Artifact Profile and the Browser/POST Profile. The latter passes assertions by value whereas Browser/Artifact passes assertions by reference. As a consequence, Browser/Artifact requires a SAML exchange using SOAP back-channel Communication.

In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth, e.g.).

SAML 2.0 profiles#

The Web Browser SSO Profile has been completely refactored for SAML 2.0. Conceptually, SAML 1.1 Browser/Artifact and Browser/POST are special cases of SAML 2.0 Web Browser SSO. The latter is considerably more flexible than its SAML 1.1 counterpart due to the new "plug-and-play" binding design of V2.0.

Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today.

In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:

A number of these profiles are discussed in more detail in the SAML 2.0 topic.

SAML Web Browser Profiles

SAML Bindings

[#1] Wikipedia http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language