When you are configuring the Identity Server to trust an identity provider and to use that identity provider for authentication, you can specify the conditions under which the Identity Server accepts the authentication credentials of the identity provider. The authentication request contains these conditions.
The Liberty and SAML 2.0 protocols have slightly different options for configuring an authentication request.
You can configure how the Identity Server creates an authentication request for a trusted identity provider. When users authenticate, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.
The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of the Identity Server.
In the Administration Console, click > > > > > > .
Configure the federation options:
Allow Federation: Determines whether federation is allowed. The federation options that control when and how federation occurs can only be configured if the identity provider has been configured to allow federation.
After authentication: Specifies that the federation request can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally, then they can federate by using the option on the card in the Login page of the Access Manager User Portal. Because the user is required to authenticate locally, you do not need to set up user identification.
During authentication: Specifies whether federation can occur when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider to complete the federation. If you enable this option, make sure you configure a user identification method. See Section 11.1.1, Selecting a User Identification Method for Liberty or SAML 2.0.
Select one of the following options for the option:
Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.
Use Types: Specifies that authentication types should be used.
Select the types from the field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, Secure Name/Password, X509, Token, and so on.
Use Contracts: Specifies that authentication contracts should be used.
Select the contract from the list. For a contract to appear in the list, the contract must have the option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity provider and the service provider. For information about contract options, see Section 3.4, Configuring Authentication Contracts.
Most third-party identity providers do not use contracts.
Configure the options:
Response protocol binding: Select or or . Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.
If you select , you are letting the identity provider determine the binding.
Identity Provider proxy redirects: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select to let the trusted identity provider decide how many times the request can be proxied.
Force authentication at Identity Provider: Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.
Use automatic introduction: Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:
When the federated user is authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).
When the federated user is not authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.
IMPORTANT:Enable the option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.
This option should be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.
Click twice, then update the Identity Server.
You can configure how an authentication request is federated. When users authenticate to a service provider, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.
The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of the Identity Server.
In the Administration Console, click > > > > > >
Configure the name identifier format:
Persistent: Specifies that a persistent identifier, which is written to the directory and remains intact between sessions, can be sent.
After authentication: Specifies that the persistent identifier can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally. Because the user is required to authenticate locally, you do not need to set up user identification.
During authentication: Specifies that the persistent identifier can be sent when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider. If you enable this option, make sure you configure a user identification method. See Section 11.1.1, Selecting a User Identification Method for Liberty or SAML 2.0.
Transient: Specifies that a transient identifier, which expires between sessions, can be sent.
Unspecified: Allows either a persistent or a transient identifier to be sent.
Select one of the following options for the option:
Do not specify: Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.
Use Types: Specifies that authentication types should be used.
Select the type of comparison (for more information, see Understanding Comparison Contexts):
Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.
Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.
Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.
Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.
Select the types from the field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/Password, X.509, Token, and so on.
Use Contracts: Specifies that authentication contracts should be used.
Select the type of comparison (for more information, see Understanding Comparison Contexts):
Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.
Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.
Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.
Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.
Select the contract from the list. For a contract to appear in the list, the contract must have the option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity provider and the service provider. For information about contract options, see Section 3.4, Configuring Authentication Contracts.
Most third-party identity providers do not support contracts.
Configure the options:
Response protocol binding: Select or or . Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.
If you select , you are letting the identity provider determine the binding.
Allowable IDP proxy indirections: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select to let the trusted identity provider decide how many times the request can be proxied
Force authentication at Identity Provider: Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.
Use automatic introduction: Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:
When the federated user is authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).
When the federated user is not authenticated at the identity provider: The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.
IMPORTANT:Enable the option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.
This option should be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.
Click twice, then update the Identity Server.
When a service provider makes a request for an identity provider to authenticate a user, the authentication request can contain a class or type and a comparison context. The identity provider uses these to determine which authentication procedure to execute. There are four comparison contexts:
Exact: Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.
For example, when the comparison context is set to exact, the identity provider uses the URI in the request to find an authentication procedure. If an exact URI match is found, the user is prompted for the appropriate credentials. If an exact match is not found, the user is denied access.
Better: Indicates the contract that must be stronger than the class or type specified in the authentication statement.
If the identity provider is a Novell Identity Server, the Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level that is higher than 1. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.
Minimum: Indicates that the contract must be as strong as the class or type specified in the authentication statement.
If the identity provider is a Novell Identity Server, the Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level of 1 or higher. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.
Maximum: Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.
If the identity provider is a Novell Identity Server, the Identity Server first finds the specified classes or types and their assigned authentication levels. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for some types and 3 for other types, the identity provider looks for contracts with an authentication level of 3. If a match or matches are found, the user is presented with the appropriate login prompts. If there are no contracts defined with a authentication level of 3, the identity provider looks for a match with an authentication level of 2, or if necessary, level 1. It cannot search below the lowest level of class in the authentication request or higher than the highest level of a class in the authentication request.
When you configure the authentication request, you specify the comparison context for a type or a contract.