Dynamic Authentication Context Processing (SAML 2.0)

An authentication context indicates how a user authenticated at an Identity Provider. The Identity Provider includes the authentication context in an assertion. The authentication context gives the Service Provider confidence in the assertion before granting access to resources.
sm1252sp1
An authentication context indicates how a user authenticated at an Identity Provider. The Identity Provider includes the authentication context in an assertion. The authentication context gives the Service Provider confidence in the assertion before granting access to resources.
A user's current session can have a lower protection level than the requested authentication context. In that case, the user must reauthenticate at the higher level. The dynamic authentication feature lets a 
CA Single Sign-On
 Identity Provider redirect the user to more than one authentication URL. The goal is to establish the necessary authentication level for an assertion. After the user reauthenticates, the IdP can generate an assertion. This flexibility enforces multiple security levels within a single federated partnership.
Dynamic authentication is accomplished using authentication context templates. A template contains mappings between authentication context URIs and Policy Server-defined authentication levels. The authentication levels indicate the strength of an authentication context for a user session. Each URI is also mapped to an authentication URL. To authenticate a user at the requested authentication context, the IdP sends the user to this URL to reauthenticate. Finally, the IdP sends the assertion back to the Service Provider with the requested context.
Important!
Dynamic Authentication works with only Policy Server 12.6.01 or later.
Dynamic Authentication for SP-Initiated SSO
As part of an SP-initiated SSO transaction, an SP can request that a user be authenticated with a particular authentication context. The Service Provider includes an <RequestedAuthnContext> element as part of the authentication request that it sends to the Identity Provider.
When the Identity Provider receives a request, it compares the value of the <RequestedAuthnContext> element to the current user authentication context. The authentication level determines the current authentication context. If the comparison is successful, the Identity Provider includes the authentication context in the assertion. The Identity Provider then returns the assertion to the Service Provider.
If validation is configured at the Service Provider, it validates the incoming context against the value it requested. If validation fails, the response is rejected. Validation is optional.
The
CA Single Sign-On
IdP does not support passive authentication. If the SP sends an authentication request with the query parameter IsPassive=true and the IdP must reauthenticate the user for any reason, the IdP returns a NoPassive response.
Authentication context processing follows these steps:
  1. The SP sends an authentication request with the <RequestedAuthnContext> element and a comparison operator.
  2. The IdP receives the request. One of the following actions occur.
    • If the user does not have a valid session, the IdP uses the supplied <RequestedAuthnContext> and the authentication context template in use by the partnership. In the template, each URI is mapped to an Authentication URL. The IdP determines the authentication URL based on the requested authentication context and redirects the user to that URL. The IdP authenticates the user with that URL and a session for that user is generated. 
    • If the SP does not include a <RequestedAuthnContext> in the request, the IdP uses the default authentication URL from the template. The default entry determines the authentication context. This context determines the minimum authentication level.
    • If the user has a valid session, the IdP compares the authentication level for the session with the AuthnContext requested by the SP. The comparison is based on the comparison operator that is sent in the request. If the authentication level is high enough, the IdP generates an assertion. If the authentication level is too low, the <RequestedAuthnContext> element and comparison operator determine the authentication context URI to use. Based on the URI mapping in the template, the IdP redirects the user to the corresponding authentication URL. The IdP authenticates the user and a user session is generated. If there is no match, the IdP returns a NoAuthnContext response to the SP. The response includes a message that the IdP does not support the requested authentication context. 
  3. If configured, the SP verifies whether the authentication context URI in the assertion is valid as compared to its configuration. If the validation is successful, the authentication transaction is complete. 
The only supported comparison operator is exact. If the SP sends any other comparison operator, an error response is sent back to the SP. The error indicates that the request is not supported. The authentication context URIs defined in the template must match one of the contexts that the SP has requested.
Authentication Context Results for SP-Initiated SSO
The first table shows a sample dynamic authentication context template. The subsequent tables list the requested authentication context and the outcome that is based on dynamic authentication context processing.
If the requested authentication context has a lower strength than the initial session context, the IdP returns the exact authentication context in the assertion. The result in each table reflects this outcome.
The tables assume SP-initiated single sign-on.
Authentication Context Template Configuration
Authentication
Context URI
Default
Strength
Authentication Level
Authentication URL
SmartCardPKI
No
3
31-1000
TimeSyncToken
No
2
21-30
Password
Yes
1
1-20
Initial Session Context: Password
SP-requested
Authentication Context
Comparison
Value
Result
Password
exact
Success/Password
TimeSyncToken
exact
Redirect to TimeSyncToken authentication URL
SmartCardPKI
exact
Redirect to SmartCard PKI authentication URL
Initial Session Context: TimeSyncToken
SP-requested
Authentication Context
Comparison
Value
Result
Password
exact
Success/Password
TimeSyncToken
exact
Success/TimeSyncToken
SmartCardPKI
exact
Redirect to SmartCard PKI authentication URL
Initial Session Context: SmartCardPKI
SP-requested
Authentication Context
Comparison
Value
Result
Password
exact
Success/Password
TimeSyncToken
exact
Success/TimeSyncToken
SmartCardPKI
exact
Success//SmartCard PKI
No Valid Session and Password as the Default URI
SP-requested
Authentication Context
Comparison
Value
Result
None
None
Redirect to Password authentication URI
Password
exact
Redirect to Password authentication URL
TimeSyncToken
exact
Redirect to TimeSyncToken authentication URL
SmartcardPKI
exact
Redirect to SmartCardPKI authentication URL
Dynamic Authentication Processing for IdP-initiated SSO
When single sign-on is initiated at the IdP, authentication context processing follows these steps:
  1. The IdP initiates a single sign-on transaction.
    • If the user does not have a valid session, the user is redirected to the default authentication URL configured in the authentication context template.
    • If the user has a valid session, the authentication level for the session is compared against the protection level for the default authentication context URI. If the level is not at least as strong as the default, the user is redirected to the Authentication URL for the default URI. The user is then authenticated. This process establishes a minimum authentication level that is required to generate an assertion.
  2. The IdP generates the assertion and includes the authentication context in it. The assertion is then sent to the SP.
  3. If configured, the SP verifies whether the authentication context URI in the assertion is valid as compared to its configuration. If the validation is successful, the authentication transaction is complete.
If
CA Single Sign-On
 is at the SP, you can configure the SP to validate the incoming authentication context. For successful validation, the authncontext value in the assertion must match one of authentication context URIs in the template that the SP partnership uses.