The following sections describe the elements of the SAML component:
SAML assertions are a declaration of facts about a principal. For example, an assertion can be made that a particular client was granted update privileges to a specific database resource at a certain time. Assertions are constructed in XML based on the SAML assertion schema. Assertions are built from the user’s session information and optional attribute information using the siteAttributeMapper class. For more information, see SiteAttributeMapper and PartnerSiteAttributeMapper Interfaces.
One assertion can contain many different statements made by the authority.
The SAML specification provides for different types of assertions:
An authentication assertion declares that the specified subject has been authenticated by a particular means at a particular time. This information is declared in an AuthenticationStatement element. In Access Manager, the Authentication Service is the authentication authority. The following code example illustrates a sample authentication assertion.
<?xml version="1.0" encoding="UTF-8" ?> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="0" AssertionID="random-182726" Issuer="sunserver.example.com" IssueInstant="2001-11-05T17:23:00GMT-02:00"> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2001-11-05T17:22:00GMT-02:00"> <saml:Subject> <saml:NameIdentifier NameQualifier="example.com">John Doe </saml:NameIdentifier> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> |
An attribute assertion declares that the specified subject is associated with the specified attribute. This information is declared in an AttributeStatement element. The identity data store that is networked with Access Manager is the attribute authority.
An authorization decision assertion declares that the specified subject’s request for access to a specified resource has been granted or denied. This information is declared in an AuthorizationDecisionStatement element. In Access Manager, the Policy Service is the authorization authority.
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 Artifact Profile works without browsers enabled with JavaScript technology. It is considered more secure than 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
access (?TARGET=URL-of-destination).
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.
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.
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.
SAMLAwareServlet
redirects
the user’s browser to the Artifact Receiver
URL
with a query string that contains the artifact and the original TARGET location.
In Access Manager, the Artifact Receiver URL
and SAMLAwareServlet
are
the same. Other SAML implementations might not integrate the two functions.
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.
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.
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.
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
service is SAMLPostProfileServlet
.
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).
SAMLPostProfileServlet
provides
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.
Assertions are exchanged between Access Manager and inquiring parties using the <Request> and <Response> XML constructs defined in the SAML specification. These SAML constructs are then integrated into SOAP messages for transport.
A SAML <Request> can contain queries for authentication status, authorization decisions, attribute information, and one or more assertion identifier references or artifacts.
Access Manager uses SOAP, a message communications specification that integrates
XML and HTTPS, to transport the SAML constructs. The request is received by SAML SOAP Receiver
, a servlet that receives
a SOAP message, extracts the SAML request, and responds with another SOAP
message that contains the requested assertion. SAML SOAP Receiver
responds to queries for authentication, attributes,
or authorization decisions (including those that have an artifact) by returning
assertions. The access URL for SAML SOAP Receiver
is http(s)://access-manager-host.domain:port/deploy-uri/SAMLSOAPReceiver.
SAML SOAP Receiver
only
supports the POST method.
SOAP messages consist of three parts: an envelope, header data, and a message body. The SAML <Request> and <Response> elements are enclosed in the message body. A client transmits a SAML <Request> element within the body of a SOAP message to an entity.
The SAML API and the Java API for XML Messaging (JAXM) are used
to construct SOAP messages and send them to SAML SOAP Receiver
.
The following two samples illustrate a SOAP exchange for the Web Browser Artifact Profile. The first is a request for an authentication assertion.
POST /authn HTTP/1.1 Host: idp.example.com Content-type: text/xml Content-length: nnnn <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Header/> <soap-env:Body> <samlp:Request xmlns="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:lib="http://projectliberty.org/schemas/core/2002/12" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" IssueInstant="2002-12-12T10:08:56Z" MajorVersion="1" MinorVersion="0" RequestID="e4d71c43-c89a-426b-853e-a2b0c14a5ed8" id="ericssonb6dc3636-f2ad-42d1-9427-220f2cf70ec1" xsi:type="lib:SignedSAMLRequestType"> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </ds:SignatureMethod> <ds:Reference URI="#ericssonb6dc3636-f2ad-42d1-9427-220f2cf70ec1"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"> </ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </ds:DigestMethod> <ds:DigestValue>+k6TnolGkIPKZlpUQVyok8dwkuE=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> wXJMVoPO1V1jFnWJPyOWqP5Gqm8A1+/2b5gNzF4L4LMu4yEcRtttLdPPT3bvhwkwHXjL9 NuOFumQ5YEyiVzlNcjAxX0LfgwutvEdJb748IU4L+8obXPXfqTZLiBK1RbHCRmRvjlPIu 22oGCV6EwuiWRvOD6Ox9svtSgFJ+iXkZQ </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIDMTCCApqgAwIBAgIBHDANBgkqhkiG9w0BAQQFADCBlTELMAkGA1UEBhMCVVMxCzAJB gNVBAcTAlNGMRkwFwYDVQQKExBMaWJlcnR5IEFsbGlhbmNlMRQwEgYDVQQLEwtJT1AgVG VzdGVyczEiMCAGA1UEAxMZTGliZXJ0eSBUZXN0ZXJzIENlcnRpZmllcjEkMCIGCSqGSIb 3DQEJARYVcnJvZHJpZ3VlekBuZW9zb2wubmV0MB4XDTAyMTIwNDE1NTg0NFoXDTEyMTIw MTE1NTg0NFowgasxCzAJBgNVBAYTAlVTMQswCQYDVQQHEwJTRjEkMCIGA1UEChMbTGliZ XJ0eSBBbGxpYW5jZSBlcmljc3Nvbi1hMSYwJAYDVQQLEx1JT1AgVGVzdGVycyBlcmljc3 Nvbi1hIHNpZ25lcjEXMBUGA1UEAxMOZXJpY3Nzb24tYS5pb3AxKDAmBgkqhkiG9w0BCQE WGXJyb2RyaWd1ZXpAZXJpY3Nzb24tYS5pb3AwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBAPUoGYvJxQc5jzDnJ14TV6TaTbB3fH95ju24Z0y6HQxm6gXdJSAoWh7/AIes4UcV0 9DC2kKS6Vow2YoXt2LIyH9HWH2tEUt1jS/PUeBHEWcW3tFezM6jh5GG5rCuVPZaW9eoGU bFPSzOPFKUAwdHUXSDWufY1KZ93IxhOBeZgg6VAgMBAAGjeTB3MEoGCWCGSAGG+EIBDQQ 9FjtUaGlzIHNpZ25pbmcgY2VydCB3YXMgY3JlYXRlZCBmb3IgdGVzdGluZy4gRG8gbm90 IHRydXN0 IGl0LjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIEMDALBgNVHQ8EBAMC BsAwDQYJKoZIhvcNAQEEBQADgYEAR/HSgBpAprQwQVyWDE9pCaiduKv4/W/+hrdpXlVKS r6TIlg4ouDCQJNos7tNuG9ZAbfWtHvCss51N2cfAzfns/DKqxRqcsxzL5ZUBksPpmsDob oopUv6Xm8RFsi7yB9AGaVuqObeY/+m70nOu03O+FlMN3U1k2E3rOKXlU1noC0 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <samlp:AssertionArtifact> AAM1uXw6+f+jyA/4XuFHqPl7QDvc/LIQL9+t7YQtG1Gwk9bph0Adl+o+ </samlp:AssertionArtifact> </samlp:Request> </soap-env:Body> </soap-env:Envelope> |
In response to the request, SAML SOAP
Receiver
must return either a <Response> element
within the body of another SOAP message or a SOAP fault code (error message)
for every request received. The following sample is a response that contains
an authentication assertion.
HTTP/1.1 200 OK Content-Type: text/xml Content-Length: nnnn <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Header/> <soap-env:Body> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="RPCUk2ll+GVz+t1lLURp51oFvJXk" IssueInstant="2002-10-31T21:42:13Z" MajorVersion="1" MinorVersion="0" Recipient="http://localhost:8080/sp" ResponseID="LANWfL2xLybnc+BCwgY+p1/vIVAj"> <samlp:Status> <samlp:StatusCode xmlns:qns="urn:oasis:names:tc:SAML:1.0:protocol" Value="qns:Success"> </samlp:StatusCode> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:lib="http://projectliberty.org/schemas/core/2002/12" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" AssertionID="SqMC8Hs2vJ7Z+t4UiLSmhKOSUO0U" InResponseTo="RPCUk2ll+GVz+t1lLURp51oFvJXk" IssueInstant="2002-10-31T21:42:13Z" Issuer="http://host:8080/idp" MajorVersion="1" MinorVersion="0" xsi:type="lib:AssertionType"> <saml:Conditions NotBefore="2002-10-31T21:42:12Z" NotOnOrAfter="2002-10-31T21:42:43Z"> <saml:AudienceRestrictionCondition> <saml:Audience>http://localhost:8080/sp</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AuthenticationStatement AuthenticationInstant="2002-10-31T21:42:13Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" xsi:type="lib:AuthenticationStatementType"> <saml:Subject xsi:type="lib:SubjectType"> <saml:NameIdentifier> C9FfGouQdBJ7bpkismYgd8ygeVb3PlWK </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01 </saml:ConfirmationMethod> </saml:SubjectConfirmation> <lib:IDPProvidedNameIdentifier> C9FfGouQdBJ7bpkismYgd8ygeVb3PlWK </lib:IDPProvidedNameIdentifier> </saml:Subject> </saml:AuthenticationStatement> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> </ds:SignatureMethod> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"> </ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> </ds:DigestMethod> <ds:DigestValue>ZbscbqHTX9H8bBftRIWlG4Epv1A=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> H+q3nC3jUalj1uKUVkcC4iTFClxeZQIFF0nvHqPS5oZhtkBaDb9qI TA7gIkotaB584wXqTXwsfsuIrwT5uL3r85Rj7IF6NeCeiy3K0+z3u ewxyeZPz8wna449VNm0qNHYkgNak9ViNCp0/ks5MAttoPo2iLOfaK u3wWG6d1G+DM= </ds:SignatureValue> </ds:Signature> </saml:Assertion> </samlp:Response> </soap-env:Body> </soap-env:Envelope> |
The entities requesting and responding with SAML must not include more than one SAML request or response per SOAP message. They must also not include any additional XML elements in the SOAP body.
SAML SOAP
Receiver
The Access Manager administrator has the option of protecting the SAML SOAP Receiver
. The available methods are:
NOAUTH
BASICAUTH
SSL
SSLWITHBASICAUTH
This value is configured as a subattribute of the Trusted Partners attribute in the SAML module. The default authentication type is NOAUTH. If SSL authentication is to be specified, it is configured in the SOAPUrl field with the https protocol. For more information, see Trusted Partners.
Basic authentication allows a provider originating a request to authenticate itself by transmitting a username and password. The credentials are presented in response to a challenge from the provider to which the request is being sent. You need to configure Access Manager to support basic authentication using the following procedure.
In the Access Manager Console, click the Federation tab.
Under Federation, click the SAML tab.
Select New under the Trusted Partners attribute.
Select the Web Browser Artifact Profile (Artifact) under Source and click Next.
Type a value for the Source ID attribute.
This is a 20–byte sequence (encoded using the Base64 format) that comes from the partner site. It is generally the same value as that used for the Site ID attribute when configuring Site Identifiers.
Enter the SOAP Receiver URL for the site you are configuring as a value for the SOAP URL attribute.
General information on SOAP endpoints is in SAML SOAP Receiver.
Select BASICAUTH or SSLWITHBASICAUTH (if the endpoint is configured with Secure Sockets Layer) as the authentication type.
Enter a user identifier for the user on the partner side being used to protect their SOAP Receiver.
Enter and reenter the password associated with the user on the partner side being used to protect their SOAP Receiver.
Click Finish to complete the configuration.
Click Save to save the configuration.