Sun Java System Access Manager 7.1 Federation and SAML Administration Guide

Elements of SAML

SAML defines message formats in XML for queries and responses. SAML queries are sent to a SAML authority and responses, in the form of SAML assertions, are returned via SOAP over HTTP, the request-response protocol used to carry SAML messages. The following sections describe these and other elements of SAML.

Queries and Responses

An entity can interact with a SAML authority using requests containing queries and responses containing assertions. AuthenticationQuery, AttributeQuery, and AuthorizationDecisionQuery XML tags containing requests for security information are wrapped within a <samlp:Request> XML tag and sent to a SAML authority. AuthenticationStatement, AttributeStatement, and AuthorizationDecisionStatement XML tags containing assertions of security information are wrapped within a <samlp:Response> XML tag and returned to the assertion consumer. See the following sections for more information.

Queries

A requesting party uses AuthenticationQuery, AttributeQuery, and AuthorizationDecisionQuery tags within a <samlp:Request> to ask for assertions about a particular entity from a SAML authority. Following is an example request containing an attribute query.

<samlp:Request
xmlns:samlp="urn:oasis:names:tc:SAML:1.1:protocol"
RequestID="s9c4a43c0265e904ca86f43c3e30034dd56582a79"
MajorVersion="1" MinorVersion="1"
IssueInstant="2006-01-09T11:33:48Z">
  <samlp:AttributeQuery>
   <saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:1.1:assertion">
   <saml:NameIdentifier NameQualifier="dc=example,dc=com">uid=amadmin,dc=example,dc=com</saml:NameIdentifier>
   <saml:SubjectConfirmation>
   <saml:ConfirmationMethod>urn:com:sun:identity</saml:ConfirmationMethod>
   <saml:SubjectConfirmationData>
   </saml:SubjectConfirmationData>
   </saml:SubjectConfirmation>
   </saml:Subject>
  </samlp:AttributeQuery>
</samlp:Request>

Responses

A SAML authority uses AuthenticationStatement, AttributeStatement, and AuthorizationDecisionStatement tags within a <samlp:Response> to return information about an entity to the requesting party. Following is an example response containing an assertion. See Assertions for more information.

<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:1.1:protoco"
ResponseID="s757013615ab8ab95ffe272f9e377aa6ed823d030"
InResponseTo="s9c4a43c0265e904ca86f43c3e30034dd56582a79"
MajorVersion="1" MinorVersion="1"
IssueInstant="2006-01-09T11:33:48Z"
Recipient="10.17.246.43">
  <samlp:Status>
  <samlp:StatusCode Value="samlp:Success"> 
  </samlp:StatusCode>
  </samlp:Status>
    <saml:Assertion
     xmlns:saml="urn:oasis:names:tc:SAML:1.1:assertion"
     MajorVersion="1" MinorVersion="1"
     AssertionID="s1f3764242b274a835475d5433b8c62020a0e39a80"
     Issuer="dde280-3.france.sun.com:80"
     IssueInstant="2006-01-09T09:44:48Z" >
    <saml:Conditions NotBefore="2006-01-09T09:41:48Z" NotOnOrAfter="2006-01-09T09:51:48Z">
    </saml:Conditions>
<!-- statements go here -->
</saml:Assertion>
</samlp:Response>

Assertions

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 PartnerSiteAttributeMapper Interface.

Note –

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 within an AuthenticationStatement XML tag. In Access Manager, the Authentication Service is the authentication authority. The following code example illustrates a SAML assertion with an AuthenticationStatement.

<?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 within an AttributeStatement XML tag. The identity data store that is networked with Access Manager is the attribute authority. The following code example illustrates a SAML assertion with an AttributeStatement.

<?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:AttributeStatement>
   <saml:Subject> 
     <saml:NameIdentifier NameQualifier="dc=example,dc=com">
      uid=amadmin,dc=example,dc=com</saml:NameIdentifier>
   </saml:Subject>
   <saml:Attribute AttributeName="sn" AttributeNamespace="urn:sun:fm:samples:saml:query">
   <saml:AttributeValue xmlns:saml="urn:oasis:names:tc:SAML:1.1:assertion">amadmin</saml:AttributeValue>
   </saml:Attribute>
   <saml:Attribute AttributeName="cn" AttributeNamespace="urn:sun:fm:samples:saml:query">
   <saml:AttributeValue xmlns:saml="urn:oasis:names:tc:SAML:1.1:assertion">amadmin</saml:AttributeValue>
   </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

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 within an AuthorizationDecisionStatement XML tag. In Access Manager, the Policy Service is the authorization authority.

Note –
The OASIS Security Services (SAML) Technical Committee has recently frozen this query in favor of using the eXtensible Access Control Markup Language (XACML). Future versions of Access Manager will reflect this.

Profiles

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 the Web Browser Artifact Profile and the Web Browser POST Profile. Both profiles use HTTP. The profile methods can be initiated through a web browser or the SAML API. (For more information about the API method, see SAML API.) Either profile 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.

More information can be found in the following sections:

Web Browser Artifact Profile

The Web Browser Artifact Profile is used when there is a back channel available to process an artifact. (An artifact is carried as part of the URL and points to an assertion which contains the security information regarding the requestor.) 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 artifact is sent via a browser and processed using SOAP. The SOAP communication should be either Basic Authentication or Client Certificate Authentication over SSL although XML signing is a stronger alternative. The Web Browser Artifact Profile is considered more secure than the Web Browser POST Profile (as discussed in Web Browser POST Profile).

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 Service’s list of Trusted Partners against the user’s TARGET location.

Only targets that are configured in the Trusted Partners attribute of the SAML Service 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 PartnerSiteAttributeMapper Interface.

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.
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.
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.

Figure 10–2 Web Browser Artifact Profile Interactions

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 is a front-channel profile that sends responses via the browser. It 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 Web Browser POST Profile is simpler than the Web Browser Artifact Profile (as discussed in Web Browser Artifact Profile).

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.

The first interaction of the Web Browser POST Profile is as follows:
1. 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).
  
  Note –
  SAMLPostProfileServlet provides functions for both Web Browser POST Profile interactions.
2. 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.
3. 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.
4. Access Manager forms, signs, and Base64 encodes a SAMLResponse that contains the assertion.
5. 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.
6. 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:
1. The trusted partner site obtains the TARGET and SAMLResponse from the redirected request.
2. 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.
3. Assuming a positive authentication, the trusted partner site obtains or creates an SSOToken and redirects the authenticated user to the TARGET location.

Figure 10–3 Web Browser POST Profile Interactions

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.

SAML SOAP Receiver

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.

Note –

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.

Note –

SAML SOAP Receiver only supports the POST method.

SOAP Messages

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.

Note –

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.

Example 10–1 SOAP Request for Authentication Assertion Using Web Browser Artifact Profile

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.

Example 10–2 SOAP Response to SOAP Request for Web Browser Artifact Profile

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>

Note –

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.

Protecting `SAML SOAP Receiver`

The Access Manager administrator has the option of protecting the SAML SOAP Receiver. The available methods are:

NOAUTH

Specify NOAUTH if the URL to the SAML SOAP receiver is accessed using HTTP, and the SAML SOAP receiver is not protected by HTTP basic authentication.
BASICAUTH

Specify BASICAUTH if the URL to the SAML SOAP receiver is accessed using HTTP, and the SAML SOAP receiver is protected by HTTP basic authentication.
SSL

Specify SSL if the URL to the SAML SOAP receiver is accessed using HTTPS, and the SAML SOAP receiver is not protected by HTTP basic authentication.
SSLWITHBASICAUTH

Specify SSLWITHBASICAUTH if the URL to the SAML SOAP receiver is accessed using HTTPS, and the SAML SOAP receiver is protected by HTTP basic authentication.

Note –

If you are protecting the SAML SOAP receiver URL with HTTP basic authentication, you do so in the web container configuration and not in the Access Manager configuration. You do, however, supply the HTTP basic authentication user ID and password in the Access Manager configuration.

This value is configured as a sub-attribute 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.

To Configure Access Manager for Basic Authentication

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.

Elements of SAML

Queries and Responses

Queries

Responses

Assertions

Profiles

Web Browser Artifact Profile

Figure 10–2 Web Browser Artifact Profile Interactions

Web Browser POST Profile

Figure 10–3 Web Browser POST Profile Interactions

Single-Use Policy With POST Profile

SAML SOAP Receiver

SOAP Messages

Example 10–1 SOAP Request for Authentication Assertion Using Web Browser Artifact Profile

Example 10–2 SOAP Response to SOAP Request for Web Browser Artifact Profile

Protecting SAML SOAP Receiver

To Configure Access Manager for Basic Authentication

Protecting `SAML SOAP Receiver`