Previous Topic: SAML Session Ticket Authentication

Next Topic: How Signing Assertions Affects SAML Session Ticket Authentication

How SAML Session Ticket Authentication Works

SAML Session Ticket authentication provides a mechanism for single sign-on across web services protected by the same policy store.

To generate an assertion, a web service consumer must first be authorized by the Policy Server. The authorizing policy must have a response configured with it that issues SAML Session Ticket response data. This data is used by the SOA Agent to generate the assertion. This assertion is then passed back to web service consumers who then use it to gain access to web services protected by the SAML Session Ticket authentication scheme.

When setting up the SAML Session Ticket response, you can configure whether the SOA Agent puts the assertion in a SOAP document, in an HTTP header separate from the XML document, or in a cookie as shown in the following illustration.

Assertions found within assertion cookies take precedence over assertions in the SOAP envelope or HTTP header. The SOA 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.