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 identity provider and service provider that enables single sign-on and single log-out.
An authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of Identity Server.
Click Devices > Identity Servers > Edit > SAML 2.0 > [Identity Provider] > Authentication Card > Authentication Request.
Configure the name identifier format:
|
Field |
Description |
|---|---|
|
Persistent |
A persistent identifier federates a user profile on the identity provider with the user profile on the service provider. It remains intact between sessions. The persistent identifier is saved to the user data store. It hides a user’s identity to prevent tracking of user activities across different relying parties.
|
|
Transient |
Specifies that a transient identifier that expires between sessions, can be sent. |
|
Unspecified |
Allows a persistent or a transient identifier to be sent. |
Select one of the following options for the Requested By option:
|
Field |
Description |
|---|---|
|
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 must be used. Select the type of comparison:
For more information, see Understanding Comparison Contexts. Select the types from Available types 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 must be used. Select the type of comparison:
For more information, see Understanding Comparison Contexts. Select the contract from Available contracts. For a contract to appear in the Available contracts list, the contract must have the Satisfiable by External Provider 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 Configuring Authentication Contracts. Most third-party identity providers do not support contracts. |
Configure the following options:
Response protocol binding: Select Artifact or Post or Let IDP Decide. Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.
If you select Let IDP Decide, the binding is selected based on the profile that is enabled at Identity Provider and the binding selected in the service provider.
NOTE:You can configure the post binding to be sent as a compressed option by performing the following steps:
Click Devices > Identity Servers > Edit > Options > New.
Select IS SAML2 POST INFLATE in Property Type and true in Property Value.
Click OK.
Click Devices > Identity Servers > Edit > SAML 2.0 > Service Provider or Identity Provider> Options > New.
Select SAML2 POST DEFLATE TRUSTEDPROVIDERS in Property Type and enter trusted providerʹs name, metadata URI, or provider ID in Property Value. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect SAML2 POST messages in deflated format. In other words, this provider has to send deflated SAML2 POST messages to the listed trusted providers.
Click OK.
Restart Identity Server by using this command: /etc/init.d/novell-idp restart.
For the Docker deployment, perform the following steps:
Run the kubectl get pods command to view the Access Manager pods.
Go to the Identity Server pod by running the kubectl exec --namespace <name-of-the-namespace> -it pod/<name-of-the-identity-server-pod> -- sh command.
Run the /etc/init.d/novell-idp restart orsystemctl restart novell-idp.service command.
Allowable IDP proxy indirections: Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of None 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 Let IDP Decide 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 Use automatic introduction only when the identity provider is up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Authentication is disabled because the browser is never redirected to the login page.
This option must be enabled only when you know the identity provider is available most of the time or when the service provider is dependent upon this identity provider for authentication.
Click OK > OK.
Update 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 values to determine which authentication procedure to execute.
The following are four comparison contexts:
|
Comparison Context |
Description |
|---|---|
|
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, access is denied. |
|
Better |
Indicates the contract that must be stronger than the class or type specified in the authentication statement. If the identity provider is a NetIQ Identity Server, 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 NetIQ Identity Server, 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 NetIQ Identity Server, 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. |
While configuring an authentication request, specify the comparison context for a type or a contract.