Authentication Context Template Configuration

Contents
sm1252sp1
Contents
2
An authentication context template defines the specific SAML 2.0 AuthnContext URIs that a partner supports. Each URI identifies a particular context class. You can select a template on a per-partnership basis; multiple partnerships can use a single template.
In addition to the common function, a template has the following distinct functions at each partner:
At the IdP
An authentication context template is required at the IdP when the IdP is configured to automatically detect the authentication context from the SP request.
The template maps URIs to the protection levels associated with a user session. The protection levels indicate the strength of the authentication scheme at the policy server, from 1 through 1000, with 1000 being the strongest. An administrator assigns protection levels when configuring an authentication scheme that authenticates a user and establishes a user session.
At the SP
An authentication context template at the SP is required to generate an authentication context that is sent in the authentication request. After the SP generates the request, it sends it to the IdP. The template is also required for the SP to validate that the received assertion satisfies the authentication context requested.
Before you configure an authentication context feature, verify that you meet the following minimum knowledge requirements:
  • Familiarity with SAML 2.0 standards related to authentication context processing.
  • An understanding of federation configuration objects.
  • Knowledge of how to access and use the Administrative UI.
The following figure shows the configuration process for each partner.
CA Single Sign-On
 does not have to be installed at each site. 
authncontext_config_process
authncontext_config_process
Determine Authentication Context and Strength Levels
The SP can require specific authentication context classes 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 feel confident 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 class. The order of the classes at the IdP together with the associated strength levels affects how it can respond to the SP.
For example, an SP requests an authentication context class of X.509 certificates with a strength level of 3. The IdP has to authenticate the requesting user at a suitable strength level. The comparison value in the request from the SP defines the evaluation of the authentication context. The authentication context that the IdP provides has to satisfy the requirement that is indicated by the comparison. The strength level is an exact match, a minimum or maximum level, or a better strength level.
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.
    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 system 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 TemplateThe protection level is an assurance of the strength of the authentication. Assign protection levels to each selected authentication URI. Specify the maximum level for each URI in the list. The minimum protection level is automatically calculated 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, if the policy server has an X.509 authentication scheme at a protection level of 20, ensure that the range specified for the template includes 20. Finally, the Policy Server generates a URI strength level based on the protection level.
Protection Level Example
Authentication Schemes set at the Policy Server
Protection Level
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
20
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
15
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
10
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
5
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
Each protection level is mapped to a URI strength level, as the table shows:
URI
Protection Level Max
URI Strength
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
1000
4
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
15
3
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
10
2
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
5
1
 
If you group several of the URIs, the grouping enables URIs with different protection levels to have the same URI strength. The following modified table shows the groupings.
URI
Protection Level Max
URI Strength
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
1000
3
urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract
800
3
urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocol
700
2
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
200
1
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.