The list of SAML specifications includes:

  • Assertions
  • Bindings
  • Profiles
  • Metadata
  • Authentication Context

Assertions

Assertions are XML documents sent from an identity provider (IdP) to a service provider (SP). Each assertion contains identifying information about a user who has initiated a single sign-on (SSO) request.

Bindings

A SAML binding describes the way transport protocols exchange messages. PingFederate supports the following bindings:

HTTP POST
Describes how to transport SAML messages in HTML form-control content, which uses a base-64 format.
HTTP Artifact
Describes how to use an artifact to represent a SAML message. An HTML form control or a query string in the URL transports the artifact.
HTTP Redirect (SAML 2.0)
Describes how to transport SAML messages using HTTP 302 status-code response messages.
SOAP (SAML 2.0)
Describes how to transfer SAML messages across the back channel.

Profiles

Profiles describe processes and message flows combining assertions, request/response message specifications, and bindings to achieve a specific desired functionality or use case. Profiles define the application of the specifications and play a large part in PingFederate.

Metadata

SAML 2.0 defines an XML schema to standardize metadata to facilitate the exchange of configuration information among federation partners, such as profile and binding support, connection endpoints, and certificate information.

Whether you publish or consume metadata, PingFederate supports the use of XML digital signatures to ensure the integrity of the data.

Authentication context

Before allowing access to a protected resource, an SP might want information about the assertion and the user's original authentication by the IdP. The SP uses this information for an access control decision or to provide an audit trail for regulatory or security-policy compliance.

The SAML 2.0 specification provides an XML schema whereby partners create authentication-context declarations. Partners might choose to reference a URI to implement a set of classes provided by the specification to help categorize and simplify context interpretation (see the OASIS document: Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0). However, it is up to partners to decide if they require additional authentication context and if these classes supply an adequate description. For SAML 1.x, if using the authentication context, called AuthenticationMethod, the context must appear as a URI (see oasis-sstc-saml-core-1.1.pdf).

An administrator can configure PingFederate, acting as an IdP, to include a specific authentication context in assertions for browser SSO or WS-Trust.

Several PingFederate integration kits provide methods for the developer to insert authentication context from external IdP applications into the assertion. The SP developer has the option to:
  • Call methods for extracting authentication context from an assertion.
  • Work with the application to create access control or other processing based on the context.