Sun Java System Access Manager 7 2005Q4 Federation and SAML Administration Guide

Profile Types

A profile is a set of rules that defines how to embed and extract SAML assertions. The profile describes how the assertions are combined with other objects by an authority, transported from the authority, and subsequently processed at the trusted partner site. Access Manager supports two profiles: the Web Browser Artifact Profile and the Web Browser POST Profile. Both profiles use HTTP. Either can be used in single sign-on between two SAML-enabled entities, allowing an authenticated user to access resources from a trusted partner site. Each profile has its benefits:

The profile methods can be initiated through a web browser or the SAML API. For more information about the API method, see SAML API.

Web Browser Artifact Profile

The Web Browser Artifact Profile defines interaction between three parties: a user equipped with a web browser, an authority site, and a trusted partner site. The SOAP communication should be either Basic Authentication or Client Certificate Authentication over SSL. Note that XML signing is a stronger alternative.

  1. When an authenticated user attempts to access a trusted partner (generally by clicking a link), the user is directed to a transfer service at the authority site.

    In Access Manager, the transfer service is SAMLAwareServlet. The base of the transfer service URL is http(s)://access-manager-host.domain:port/deploy-uri/SAMLAwareServlet. The URL is appended with the location to which the user is requesting access (?TARGET=URL-of-destination).

  2. SAMLAwareServlet receives the information and compares the SAML module’s list of Trusted Partners against the user’s TARGET location.

    Only targets that are configured in the Trusted Partners attribute of the SAML module are accessible. For more information about this attribute, see Trusted Partners.

  3. Assuming the TARGET location was found in the list of Trusted Partners, SAMLAwareServlet looks for and validates the session token from the inbound request.

    Without a valid session token, Access Manager will not create an assertion.

  4. Assuming a valid session token, SAMLAwareServlet creates an artifact and a corresponding assertion.

    An artifact is carried as part of the URL and points to an assertion and its source. An artifact is not (and does not contain) security information. The assertion contains the security information. For more information, see SiteAttributeMapper and PartnerSiteAttributeMapper Interfaces.

    Note –

    The need to send an artifact rather than the assertion itself is dictated by the restrictions on URL size that are imposed by many web browsers.

  5. SAMLAwareServlet redirects the user’s browser to the Artifact Receiver URL with a query string that contains the artifact and the original TARGET location.

    Note –

    In Access Manager, the Artifact Receiver URL and SAMLAwareServlet are the same. Other SAML implementations might not integrate the two functions.

  6. At the Artifact Receiver URL, the artifact is extracted from the query string to locate the SOAP Receiver URL at the trusted partner site.

    The SAML API extracts the source ID from the artifact and uses it to locate the SOAP Receiver URL at the trusted partner site. For more information about the use of SOAP, see SAML SOAP Receiver.

  7. A SOAP query that contains the artifact is sent to the SOAP Receiver URL at the trusted partner site that is requesting the assertion to which the artifact points.

  8. The SOAP Receiver URL accepts the returned artifact query from the trusted partner site and responds by sending the correct assertion in a SOAP response.

  9. The assertion is processed, mapping the user account information from the trusted partner site to the target site’s user account.

    The user is either granted or denied access to the trusted partner site. If access is granted, a SSOToken is generated, a cookie is set to the browser, and the user is redirected to the TARGET location.

Figure 9–2 Web Browser Artifact Profile Interactions

Depicts the interactions in the Web Browser Artifact

A sample has been provided to test the Web Browser Artifact Profile function. See SAML Samples for more information.

Web Browser POST Profile

The Web Browser POST Profile allows security information to be supplied to a trusted partner site using the HTTP POST method (without the use of an artifact). This interaction consists of two parts. The first part is between a user with a web browser and Access Manager. The second part is between the same user and the trusted partner site. The content of the POST should be signed to ensure message integrity, and the method of transport should be SSL.

Note –

The POST profile function is provided by either of two means: an HTTP request using SAMLPOSTProfileServlet, or an SAMLClient API call [doWebPost()] to a Java application.

Figure 9–3 Web Browser POST Profile Interactions

Depicts the interactions of the Web Browser POST Profile

A sample has been provided to test the Web Browser POST Profile function. See SAML Samples.

Single-Use Policy With POST Profile

According to the SAML specifications, the trusted partner site must ensure a single-use policy for SSO assertions that are communicated using the Web Browser POST Profile. SAMLPOSTProfileServlet maintains a store of SSO assertion identifiers and the time that they expire. When an assertion is received, the servlet first checks for an entry in the map. If an entry exists, the servlet returns an error. If an entry does not exist, the assertion identifier and expiration time are saved to the map. POSTCleanUpThread removes expired assertion identifiers periodically.