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