Web Services Security Guides › CA SiteMinder® Web Services Security Policy Configuration Guide › Configure Authentication Schemes to Verify User Identities Obtained from Web Service Requests › How to Configure SAML Session Ticket Authentication to Verify User Identities Obtained from SAML Session Ticket Assertions

How to Configure SAML Session Ticket Authentication to Verify User Identities Obtained from SAML Session Ticket Assertions

The SAML Session Ticket authentication scheme provides a mechanism for single sign-on across web services that are protected by the same policy store. The scheme authenticates XML messages using credentials that are obtained from SAML Session Ticket assertions in an HTTP header, a SOAP envelope, or a cookie. SAML Session Tickets are strongly secure assertions that a SiteMinder WSS Agent in the same Policy Server domain generates after initial authorization of the request.

A SAML Session Ticket assertion is a data structure that contains a SiteMinder session ticket and a public key (both encrypted). The SAML Session Ticket authentication scheme uses the assertions to do the following operations:

• Verify that a valid SiteMinder session exists.
• Ensure the integrity of the signed XML document.

By including the session ticket and the public key in the assertion, a web service consumer can access web services protected by SOA Agents in the same Policy Server domain without being rechallenged for credentials.

To configure CA SiteMinder® Web Services Security to validate user identities using SAML Session Ticket authentication, complete the following process:

1. Review information about how multiple SAML Session Ticket assertions are processed
2. Configure a SAML Session Ticket authentication scheme

Review Information About How Multiple SAML Session Ticket Assertions are Processed

SAML Session Ticket assertions can be placed the in a SOAP document, in an HTTP header separate from the XML document, or in a cookie as shown in the following illustration:

If a request message contains more then one associated assertion, assertions found within assertion cookies take precedence over assertions in the SOAP envelope or HTTP header. The SiteMinder WSS Agent first collects all SAML Session Ticket assertions from the cookie and the header or envelope as specified in the authentication scheme. The agent then tests each assertion until it finds the first one with a valid session ticket (that is, it can be decrypted with the agent key) and valid signatures, if they are required. Authentication is then performed using this assertion.

Note: If the authentication fails later in the authentication process because the first valid session ticket is found to be expired or revoked, authentication will fail—potential session tickets included in other assertions are not subsequently evaluated.

Configure a SAML Session Ticket Authentication Scheme

To obtain security information from SAML Session Ticket assertions in an HTTP header, a SOAP envelope, or a cookie that is associated with an incoming message, configure the SAML Session Ticket authentication scheme.

Follow these steps:

1. Click Infrastructure, Authentication.
2. Click Web Services Authentication Schemes, Create Authentication Scheme.

   The Create Authentication Scheme pane opens.

   Authentication scheme settings open.

   Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

3. Enter a name and a description for the scheme in the General group box.
4. Select SAML Session Ticket from the Authentication Scheme Type list.
5. Enter a protection level.
6. In the Scheme Setup group box, set the following options, as required:
   • Specify where the SAML assertion is located by selecting one of the following options:
     • Envelope Header
     • HTTP Header
   • (Optional) To require that incoming messages are signed, set the Require signature on XML message option. If this option is set, the following statements must be true for authentication to occur:
     • The document must be signed and the signature must be valid.
     • If the assertion is signed, it must also be valid.
   • (Optional) To require that incoming messages are sent over an SSL connection, set the Require Secure Transport Layer option.
7. Click Submit.

   The authentication scheme is saved. You can now assign it in application object components or realms.