Federation Guides › Partnership Federation Guide › Authentication Context Processing › 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.

Configure an Authentication Context Template

Configuring how authentication context information is processed involves the following tasks:

• Set up authentication context templates.
• Obtain AuthnContext information at the IdP.
• Enable the authentication context request at the SP.

An authentication context template defines the specific SAML 2.0 AuthnContext URIs that a partnership supports. Each URI identifies the context class that provides additional information in an assertion.

The template maps the URIs to the protection levels associated with a user session. The protection levels indicate the strength of the authentication, from 1 through 1000, with 1000 being the strongest. An administrator assigns protection levels as part of the authentication scheme that authenticates a user and establishes a user session.

You can select a template on a per-partnership basis; multiple partnerships can use a single template.

Set Up an Authentication Template

Set up an authentication context template to associate URIs and protection levels. This procedure is the same regardless of whether CA SiteMinder® is acting as an Identity Provider or Service Provider.

Follow these steps:

1. Log in to the Administrative UI.
2. Navigate to Federation, Partnership Federation, Authentication Context Template.
3. Select Create Template.

   The template wizard opens at the first step.

4. Enter a name for the template.
5. Complete one of the following actions:
   • Manually enter a URI and click Add URI.
   • Click Load Default URIs to select URIs from a predefined list. Move URIs from the Available URIs to the Selected URIs list.
6. Click Next.
7. Map the protection levels from an authentication scheme to URIs. CA SiteMinder® protection levels indicate the strength of an authentication, ranging between 1 through 1000, with 1000 being the strongest.

   Note the following information:

   • Assign the protection levels in descending order. List the strongest context at the top and the weakest context at the bottom.
   • You can modify the maximum protection level and the Administrative UI calculates the minimum. The Administrative UI verifies that there is no gap in the range of levels so that each protection level has an associated URI.

   Read more about protection level assignments.

8. (Optional) Group URIs that require the same protection level. Use the Change Grouping arrow to move a URI into or out of a group.

   Group URIs by indenting one URI under the previous URI. Individual URIs can have unique protection levels; however, grouping URIs means that they share the level of strength.

9. Click Next to move to the last step of the wizard.
10. Select Finish to confirm the configuration.

The template is complete.

Protection Level Assignments for a Context Template

In the authentication context template, assign a maximum protection level to each URI. The minimum protection level is automatically calculated based on the maximum level for the subsequent URI in the list.

Protection Level Example

Each protection level is mapped to a URI strength level. The original list of URIs can be organized like the following example:

If you group several of the URIs from the previous table, the grouping enables URIs with different protection levels to have the same URI strength. The modified table that follows shows the groupings.

The range of strength levels reflects the total number of groups in the list. For example, if there are three groups, the strength level ranges from 1 to the total number groups, which is 3.

Enable Authentication Context Processing at the Local IdP Partnership

The Policy Server acting as the IdP can obtain the authentication context for an assertion in these two ways:

• Use a predefined authentication class

  Specify a URI for the authentication class and ignore the context request from the SP. A hard-coded entry can act as the default authentication context for IdP-initiated single sign-on.

• Detect the authentication class automatically.

  The Policy Server automatically detects the user session authentication context using the authentication context template.

  The IdP uses the template even if the authentication request from the SP does not include the <RequestedAuthnContext> element. The presence of the element triggers extra evaluation by the IdP and constrains the choices of what it can put in the assertion.

  You can find more information about the flow of authentication context processing.

Follow these steps:

1. Navigate to the SSO and SLO step in the IdP->SP partnership wizard.
2. In the Authentication section, specify how to obtain the authentication context. Use a predefined authentication class or an automatically detected class with an authentication context template.
3. Follow the steps for the method chosen in the previous step:
   • To include a predefined class in the assertion, select a URI from the Authentication Class pull-down menu.
   • To include a class from the session context and a template, select a template from the authentication Context Template field or click Create Template.
4. (Optional). Depending on how you obtain the authentication context you can also select the Ignore RequestedAuthnContext check box.

The following table shows how the Configure AuthnContext and the Ignore RequestedAuthnContext settings work together:

Specify How the IdP Obtains the Authentication Context

Create an authentication context template to obtain the authentication class automatically.

Follow these steps:

1. Navigate to the SSO and SLO step in the IdP->SP partnership wizard.
2. In the Authentication section, specify how to obtain the authentication context. Use a predefined authentication class or an automatically detected class with an authentication context template.
3. Follow the steps for the method chosen in the previous step:
   • To include a predefined class in the assertion, select a URI from the Authentication Class pull-down menu.
   • To include a class that is based on the session context and the template, select a template from the authentication Context Template field, or click Create Template.
4. (Optional). Depending on how you obtain the authentication context you can also select the Ignore RequestedAuthnContext check box.

The following table shows how the Configure AuthnContext and the Ignore RequestedAuthnContext settings work together:

Configure Authentication Context Requests at the SP

The authentication context is part of an assertion authentication statement and it indicates how a user authenticated at an IdP. An SP can require information about the authentication process to establish a level of confidence in the assertion before granting access to resources.

Authentication Context URIs are the value of the <AuthnContextClassRef> element inside of a <AuthnContext> element. Each URI identifies the context class that the SP wants the IdP to return in the assertion.

The authentication context template at the SP defines the following information:

• Which URIs the SP wants to receive from the IdP. For outgoing requests, the URIs in the template indicate which authentication contexts are acceptable to the SP before it allows access to the requested resource.
• How the URIs in the request are compared to the URIs defined at the IdP.
• How the SP uses the URIs. The SP can include URIs in the outgoing authentication request. The SP can also validate URIs in the incoming assertion response. You can configure the URI usage for both functions.

You can select a template on a per-partnership basis and multiple partnerships can use a single template.

Create an authentication context template before you enable authentication context requests or while you are configuring the SP partnership.

Enable Authentication Context Requests at the SP

An SP can request that an IdP return the authentication context in an assertion. Enable that request at the SP->IdP partnership.

Before you begin, we recommend that you create an authentication context template.

Follow these steps:

1. Log in to the Administrative UI.
2. Select Federation, Partnership Federation, Partnerships.
3. Select the SP->IdP partnership you want to edit.
4. Navigate to the Configure AuthnContext step in the partnership wizard.

   The configuration dialog opens.

5. Select the Enable Authentication Context Processing check box.
6. Complete the fields in the dialog.

   Note: Click Help for a description of fields, controls, and their respective requirements.

   Note the following information:

   • If no authentication context template exists, select Create template.
   • The Comparison field describes how the URIs in the SP authentication request are compared with the URIs configured at the Identity Provider.

     The Help details each comparison operator.

   • If you are selecting URIs from the Available URIs list, the available URIs reflect the URIs configured for the chosen template. If there are no predefined templates, click Create Template to configure one.

The authentication context request is included in the authentication requests sent to the Identity Provider.