Dynamic Authentication Context Template Configuration
The following figure shows the configuration process for each partner. You do not have to have
CA Single Sign-Onat each site.
To configure authentication context processing, complete the following steps:
- Determine authentication context and strength levels with your partner.
- Set up an authentication context template.
- Complete the task for your site:
- Enable authentication context processing at the IdP-to-SP partnership.
- Enable authentication context requests at the SP-to-IdP 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
An authentication context template defines the specific SAML 2.0 AuthnContext URIs that a partner supports. In the template, you assign each URI a protection level range, which is then mapped to a strength level.
A template has the following distinct functions at each partner:
At the IdP
An authentication context template is required at the IdP when dynamic authentication is enabled in the partnership. The template maps URIs to the protection levels associated with a user session. Each URI is also mapped to an authentication URL.
The protection levels for the session range from 1 through 1000, with 1000 being the strongest. An administrator assigns a protection level to an authentication scheme to indicate the strength of the scheme under which the user session is established.
The IdP first uses the template to determine the strength of the user session. The IdP then uses the template to determine the strength of the URI in the SP authentication request. These strength levels are then compared.
At the SP
The SP uses an authentication context template to generate the authentication context that is sent in the authentication request to the IdP. The SP can also use the template to validate that the authentication context in the assertion satisfies the context the SP requested.
The procedure for setting up an authentication context template is the same for an Identity Provider or Service Provider. However, to use dynamic authentication, you only have to enable it for the template at the IdP. You do not have to enable this feature at the SP. You can select a template on a per-partnership basis; multiple partnerships can use a single template.
The templates at a
CA Single Sign-OnIdP and SP must match so that protection levels assigned to each URI are the same.
Follow these steps:
- Log in to the Administrative UI.
- Select Federation, Partnership Federation, Authentication Context Templates.The Authentication Context Templates List displays.
- Select Create Template.The template wizard opens at the first step.
- Enter a name for the template.
- Click Load Default URIs and select URIs from a predefined list.
- Move URIs from the Available URIs to the Selected URIs list.
- Arrange the selected URIs by strength level. The strength level is in descending order, with the strongest authentication context at the top, and the least strong at the bottom
- (Optional) You can specify a custom URI in the Class URI field. Enter the URI and click Add URI. Move the custom URI from the Available URIs to the Selected URIs list.
- Click Next to proceed.
- Assign protection levels to the URIs. The protection levels indicate the strength of the associated authentication scheme, ranging between 1 through 1000, with 1000 being the strongest. Individual URIs can have unique protection levels; however, grouping URIs gives them 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 minimum protection level is calculated automatically. The Administrative UI verifies that there is no gap in the range of levels so that each protection level has an associated URI.
- (Optional) Group URIs that require the same level of strength. The strength can be the same, but the protection level range must be different. To group URIs, indent one URI under the previous URI. To move a URI into or out of a group, use the Change Strength Grouping arrow.
- Click Next to proceed.
- (Optional) At the IdP, click Enable Dynamic Authentication and map each URI to an authentication URL. If you do not want to enable this feature, skip to the next step. The SP does not need this configuration.To complete the Dynamic Authentication Details table:
- Specify a unique Authentication URL for each URI context in the table. Each URL must be unique. Verify that the URL conforms to proper URL syntax.
- Select one entry as the default authentication entry. If an authentication context is not sent in the SP request, the default entry is used. The default is the minimum authentication level necessary to generate an assertion.
- Protect each authentication URL in the table with a policy (see page 16). Protecting the authentication URL results in an authentication challenge to the user. The user must then log in and a session is established. Configure each policy with the authentication scheme you want for the session.
- In the Confirm step, review the table. Click Finish to save the changes.
Assign Protection Levels for an Authentication 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.
Authentication Schemes Set at the Policy Server
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.
Protect Each Authentication URL in the Template
An access protection policy must protect all authentication URLs in the template to trigger an authentication challenge. After the user is authenticated, a session is established at the authentication level determined by the authentication scheme in the policy.
Follow these steps:
- Log in to the Administrative UI.
- Select Infrastructure, Agents, Create Agent.To bind to the realm defined for the asserting party web server, create a web agent. Assign unique agent names for the web server.
- Select Policies, Domain, Domains, Create Domain.Create a policy domain for the authentication URL. Add the user directory that contains the users who get challenged.
- Select the users that must have access to the resources that are part of the policy domain.
- Select the Realms tab and define a realm for the policy domain with the following values:AgentAgent for the asserting party web server. You created this agent in step 2.Resource FilterSpecify the location of the application that implements the authentication challenge. Verify that the application is deployed in a servlet container. For example, the default location for theCA Single Sign-Onweb agent and federation gateway is /affwebservices/redirectjsp. You can use the redirectjsp application multiple times by placing it in a unique folder location for each authentication URL.Default Resource ProtectionProtectedAuthentication SchemeSelect the authentication scheme that you want for the user sessionPersistent SessionSelect the Persistent check box in the Session section of the realm dialog for the HTTP-Artifact profile and to store session information. Session information is required for features such as single logout and for an attribute authority.
- In the Rules section of the realm dialog, click Create Rule. Complete the fields with the following values:Resource/*The asterisk means that the rule applies to all resources in the realm.Allow/Deny and Enable/DisableAllow AccessEnabled check box is selectedActionWeb Agent actionsGet, Post, Put
- Select the Policies tab and create a policy that includes the following components:
- The set of users you selected from your user directory.
- The realm that contains the application, such as the redirectjsp application, and the associated rule.
A policy now protects each authentication URL. An authentication challenge is triggered when the user is redirected to this URL. Finally, a session is created.