Federation Guides › Partnership Federation Guide › Authentication Context Processing (SAML 2.0)

Authentication Context Processing (SAML 2.0)

The authentication context indicates how a user authenticated at an Identity Provider. The Identity Provider includes the authentication context in a single sign-on assertion at the request of a Service Provider or based on configuration at the Identity Provider. A Service Provider can require information about the authentication process to establish a level of confidence in the assertion before granting access to resources.

Requesting the Authentication Context

To request the authentication context, the CA SiteMinder® Service Provider must include the <RequestedAuthnContext> element in the authentication request to the Identity Provider. The Service Provider, puts this element is in the request based on a configuration setting in the SP->IdP partnership.

Obtaining the Authentication Context

A CA SiteMinder® Identity Provider obtains the authentication context in one of two ways:

• You specify a static AuthnContext URI in the IdP->SP partnership configuration.

  If the federated partner is a CA SiteMinder® Service Provider that does not support AuthnContext requests, manually enter a URI in the Administrative UI.

• The AuthnContext URI is determined dynamically using a configured authentication context template.

  The Policy Server maps the authentication context URIs to Policy Server-defined authentication levels. The authentication levels indicate the strength of an authentication context for an established user session. The levels enable the authentication context to be derived from the user session at the Identity Provider.

  When the Identity Provider receives a request, it compares the value of the <RequestedAuthnContext> element to the authentication context. The comparison is based on a comparison value in the request from the Service Provider. If the comparison is successful, the Identity Provider includes the authentication contexts in the assertion that it returns to the Service Provider. If validation is configured at the Service Provider, the Service Provider validates the incoming authentication context with the value it requested.

Authentication Context Processing for IdP-initiated SSO

When single sign-on is initiated at the IdP, authentication context processing follows these steps:

1. A user request triggers single sign-on at the IdP.
2. The user is authenticated and a user session is generated. Associated with the session is a protection level that is configured with the authentication scheme.
3. Depending on the authentication context configuration at the IdP, one of the following conditions occur:
   • Automatic detection occurs

     Based on a configured authentication context template, the AuthnContext class is mapped to the protection level for the session.

   • Predefined authentication class is used.

     The hard-coded URI you specify is added to the assertion.

4. The IdP generates the assertion and adds the authentication context to it. The assertion is then sent to the SP.
5. At the SP, another comparison is made between the authentication context class from the assertion and the one configured at the SP. If this comparison is successful, the authentication transaction is complete.

Authentication Context Processing for SP-Initiated SSO

When single sign-on is initiated at the SP, authentication context processing follows these steps:

1. The SP sends an authentication request with the <RequestedAuthnContext> element and a comparison operator. The element is included based on a setting in the configuration of the SP-> IdP partnership.
2. When the IdP receives the request, the IdP authenticates the user and a user session is generated. Associated with the session is a protection level for the authentication scheme.
3. Depending on the authentication context configuration at the IdP, one of the following conditions occur:
   • Automatic detection occurs

     Based on a configured authentication context template, the AuthnContext class is mapped to the protection level for the session.

   • Predefined authentication class is used

     The hard-coded URI you specify is added to the assertion.

4. The IdP compares the AuthnContext against the authentication class for the user session. The comparison is based on the comparison operator that is sent with the request. See the table that follows this procedure for examples of how each comparison operator affects processing.

   If the SP includes multiple authentication context URIs in the request, the classes are compared one-by-one in sequential order against the context for the session. At the first successful comparison, the IdP adds the session authentication context to the assertion.

5. If the comparison is successful, then the authentication context is added to the assertion sent to the SP.

   If the comparison is not successful, the transaction is terminated with a "noauthncontext" status response.

6. At the SP, a second comparison takes place between the authentication context from the assertion and the one configured at the SP. If this comparison is successful, the authentication transaction is complete.

The following table shows examples of how an authentication context is processed depending on the comparison attribute sent in the authentication context request.