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

Authentication Context Template Configuration

‑The following figure shows the configuration process for each partner. CA SiteMinder® Federation does not have to be installed at each site.

Complete the following steps to configure authentication context processing:

1. Determine authentication context and strength levels with your partner.
2. Set up an authentication context template.
3. Complete the task for your site:
   • Enable authentication context processing at the local IdP partnership.
   • Enable authentication context requests at the local SP partnership.

Determine Authentication Context and Strength Levels with your Partner

The SP can require specific authentication contexts and strength levels before it permits access to a requested resource. Based on the sensitivity of the resources at the SP, the SP has to have confidence in the assertion it receives from the IdP.

The administrators at the IdP and SP have to establish guidelines for supported authentication contexts and the relative strength of each authentication context URI. The order of the URIs at the IdP together with the associated strength levels affects how the IdP responds to the SP.

For example, an SP requests an authentication context for an X.509 certificate and a comparison value of exact. The IdP has to authenticate the requesting user at a suitable strength level and satisfy the comparison value during the evaluation of the authentication context.

Set up an Authentication Context Template

Set up an authentication context template to implement authentication context processing. This procedure is the same for an Identity Provider or Service Provider.

Follow these steps:

1. Log in to the Administrative UI.
2. Select Federation, Partnership Federation, Authentication Context Templates.

   The View Authentication Context Templates window opens.

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. Arrange the selected URIs by strength level. The strength level is in descending order, with the strongest URI at the top and the least strong at the bottom.
7. Click Next.
8. (Optional) Group URIs that require the same level of strength indenting one URI under the previous URI. Use the Change Grouping arrow to move a URI into or out of a group.
9. Click Enable Protection Levels.

   Map the protection levels from an authentication scheme to the URIs. The protection levels indicate the strength of an authentication scheme, ranging between 1 through 1000, with 1000 being the strongest. Individual URIs can have unique protection levels; however, grouping URIs means that they have the same level of strength.

   Consider the following information when assigning protection levels:

   • 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.

10. Select Finish to confirm the configuration.

The template is complete.

Protection Level Assignments for a Context Template

The protection levels indicate the strength of the authentication. Assign protection levels to each selected authentication context URI. Specify the maximum level for each URI in the list. The minimum protection level is automatically determined based on the maximum level for the subsequent URI in the list. This range reflects the protection level.

The protection level assignments must reflect the protection levels of the configured Policy Server authentication schemes. For example, the Policy Server can have an X.509 authentication scheme at a protection level of 20. The protection level range that the template specifies must include 20. Finally, the Policy Server generates a URI strength level that is based on the protection level.

Example

For each URI, the Policy Server automatically maps the protection level to a URI strength level. The ranges cover the protection level of the authentication scheme. For example:

• X509 scheme covers protection levels 16-1000
• MobileTwoFactorContract covers protection levels 11-15
• Internet Protocol covers 6-10
• Password covers 1-5

If you group several of the URIs, the grouping enables URIs with different protection levels to have the same URI strength. This strength means that the URIs are considered equivalent.

The following modified table shows the grouping of the X.509 URI and the MobileTwoFactorContract URI.

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 are 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: