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 Web Browser Artifact Profile requires less processing overhead because there is no assertion signing as there is in the Web Browser POST Profile.
The Web Browser POST Profile does not require SOAP. This profile is more firewall-friendly and involves fewer steps and less server-side processing.
The profile methods can be initiated through a web browser or the SAML API. For more information about the API method, see SAML API.
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.
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
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.
Assuming the TARGET location was found
in the list of Trusted Partners,
SAMLAwareServlet looks for and validates the session token from the inbound
Without a valid session token, Access Manager will not create an assertion.
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.
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.
the user’s browser to the
URL with a query string that contains the artifact and the original TARGET location.
In Access Manager, the
Artifact Receiver URL and
the same. Other SAML implementations might not integrate the two functions.
Artifact Receiver URL, the artifact is extracted from the query string to locate
SOAP Receiver URL at the trusted
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.
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.
SOAP Receiver URL accepts
the returned artifact query from the trusted partner site and responds by
sending the correct assertion in a SOAP response.
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.
A sample has been provided to test the Web Browser Artifact Profile function. See SAML Samples for more information.
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.
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.
The first interaction of the Web Browser POST Profile is as follows:
An authenticated user attempts to access a trusted partner site using a web browser (usually by clicking a link), and the user is redirected to a transfer service at the authority site.
In Access Manager, the transfer
The base of the transfer service URL is http(s)://access-manager-host.domain:port/deploy-uri/SAMLPOSTProfileServlet. This URL is appended with the location
to which the user is requesting access (?TARGET=URL-of-destination).
functions for both Web Browser POST Profile interactions.
Access Manager obtains the TARGET location from the request and matches it against the trusted partners configured in the Trusted Partners attribute of the SAML module.
For more information, see Trusted Partners.
Access Manager generates an assertion using the AssertionManager class of the SAML API.
For information about the AssertionManager class, see com.sun.identity.saml Package.
Access Manager forms, signs, and Base64 encodes a SAMLResponse that contains the assertion.
Access Manager generates an HTML form that contains both the SAMLResponse and the TARGET as parameters and posts the form as an HTTP response back to the user’s browser.
The user’s browser is then directed to the location based on this information.
The second interaction of the Web Browser POST Profile is as follows:
The trusted partner site obtains the TARGET and SAMLResponse from the redirected request.
The trusted partner site decodes the SAMLResponse, verifies the signature on the SAMLResponse, and obtains and verifies the SAML response.
The trusted partner site also verifies the assertion inside the SAMLResponse and enforces single sign-on policy.
Assuming a positive authentication, the trusted partner site obtains or creates an SSOToken and redirects the authenticated user to the TARGET location.
A sample has been provided to test the Web Browser POST Profile function. See SAML Samples.
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.