MainJSP Property
3.4 Configuring Authentication Contracts
Authentication contracts define how authentication occurs. An Identity Server can have several authentication contracts available, such as name/password, X.509, or Kerberos. From the available contracts, you assign a contract to a specific resource or resources. It is access to a resource that triggers the authentication process. If the user has already supplied the required credentials for the contract, the user is not prompted for them again.
Each contract is assigned a URI that uniquely identifies it. This URI can be shared with other providers so that they can identify the type of credentials the Identity Provider is requiring. You can also restrict a contract so that it can only be used for local authentication and not with other providers.
1 In the Administration Console, click Devices > Identity Servers > Edit > Local > Contracts.
2 To delete a contract, select the contract, then click Delete.
You cannot delete a contract if it is in use by an Access Gateway.
3 To create a new contract, click New.
4 Fill in the following fields:
Display name: Specifies the name of the authentication contract.
URI: Specifies a value that uniquely identifies the contract from all other contracts. It is used to identify this contract for external providers and is a unique path value that you create. No spaces can exist in the URI field.
The following are all valid values for the URI:
/mycompany/name/password/form http://mycompany.com/login secure/form/password/bcompany
Password expiration servlet: Specifies a URL to a page where the user can change password when the password expires or is within the grace login period. You must use eDirectory to change the number of grace logins. Grace logins work only with eDirectory.
For more information about how to use this type of servlet, see Section 3.4.1, “Using a Password Expiration Service,” on page 132.
Allow User Interaction: If you specify a password expiration servlet, you can enable this option, which allows the users to decide whether to go to the servlet and change their passwords or to skip the servlet. If you always want to force the users to go the servlet to change their
passwords, do not enable this option.
Login Redirect URL: You will be redirected to the URL specified in this field. Use this field for the following scenarios:
Forcing the user to a specific home page after successful Access Manager authentication.
Forcing the user to configure challenge/response forgotten password questions
For more information about the URL parameters, see Section 3.4.2, “Using Login Redirect URL Parameters,” on page 135.
Allow User Interaction: You can enable this option, which allows the user to decide whether to continue to access a pre-configured URL or to continue to the page that the user usually accesses. For example, the user may usually access www.a.com and have specified the redirect URL as https://someservice.com/path/
password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL> then, continue will allow you to continue with the website you access i.e. www.a.com and redirect URL will take you to the URL https://someservice.com/path/
password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>&action=expire and then to www.a.com.
Authentication Level: A number you can assign to this authentication contract to specify its security level or rank. You use this setting to preserve authentication contracts of a higher security level. When you enable the Satisfiable by a contract of equal or higher level option on this page, the system uses this value as a reference.
For example, you might create a name/password authentication contract and assign it to level one. You might also create an X.509 authentication contract and assign it to level two. If a user supplies the credentials for the X.509 level-two contract, the system does not require the credentials to satisfy the name/password level-one authentication contract.
Authentication Timeout: Specify how long the session can be inactive before the user is prompted to log in again. The value can be from 5 minutes to 66535 minutes and must be divisible by 5.
If you modify the timeout value for a contract, the newly assigned value is given to users as they log in. Currently logged in users retain the old value until they re-authenticate.
You need to experiment to discover what values are best for your network configuration, your security requirements, and your users.
Shorter timeouts increase back-channel traffic and require more threads for authentication checks, but quickly free resources that are being used by inactive users. If you have slow back-end services, users could get disconnected waiting for a response, and these disconnects can generate more authentication traffic.
Longer timeouts, which allow inactive users to remain connected, increase memory requirements to store session information, but require fewer threads and don't generate as much back-channel traffic.
For example, if you set the timeout to 5 minutes, an authentication check needs to be done 12 times each hour for each user authenticating with this contract. If the timeout is set to 60 minutes, an authentication check is done only one time each hour for each user. However, for the 5 minute timeout, resources can be freed within 5 minutes of inactivity by the user. For the 60-minute timeout, resources can take as long as 60 minutes to be freed, depending upon when the user goes inactive.
NOTE: In case of Name/Password - Basic and Secure Name/Password - Basic contracts applied to a protected resource, then you won’t find the session as timed out, as the session gets renewed after timeout without user intervention using the Basic header sent from browser to Identity Provider.
For information about how to use this feature with the Access Gateway, see “Assigning a Timeout Per Protected Resource” in the NetIQ Access Manager 4.0 SP1 Access Gateway Guide Activity Realm(s): Specify the name of the realm that can be used to indicate activity. Use a comma-separated list to specify multiple realms. This allows a user’s session to be kept alive when the user is accessing resources that are protected by different contracts. If both contracts belong to the same realm, activity on either resource keeps the session alive on the other resource. For more information about this feature, see Section 3.4.3, “Admin can configure some more parameters that wiUsing Activity Realms,” on page 135.
Satisfiable by a contract of equal or higher level: Allows the system to satisfy this authentication contract if a user has logged in using another contract of an equal or higher authentication level, as specified in the Authentication Level field of an authentication contract.
When you enable this option, you need to be aware of the authentication levels you have set for other contracts and the level that has been assigned to the default contract.
When the protected resource is configured with Name/Password -Form as Authentication procedure, the user authentication details are prompted with transient federation. This option should be enabled to avoid prompting for authentication in the Target Service Provider.
Satisfiable by External Provider: Allows this contract to be selected when configuring an identity provider for Liberty or SAML 2.0. When you configure the authentication request, you can select a contract that has this option enabled and require the identity provider to use this contract in order for authentication to succeed.
Requested By: Select one of the following options:
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 Available types 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 Available contracts list. 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 Section 3.4, “Configuring Authentication Contracts,” on page 128.
Most third-party identity providers do not use contracts.
Allowable Class: Specifies the class that instructs a service provider to send a request for a specific authentication type to the Identity Provider. You are allowed to modify this option only when you select authentication types.
NOTE: In SAML 2 federation with Access Manager as Service Provider, if external Identity Server is authenticating a user, it sends <AuthnContext> information after authentication in the response. Access Manager uses this <AuthnContext> to find a matching contract at the Service Provider to identify the user. It identifies the contract by trying to match
<saml:AuthnContextClassRef> with AllowableClass attribute or
<saml:AuthnContextDeclRef> with URI attribute of existing contracts at the Service Provider.
For example, if the external Identity Server sends the following AuthnContext
<saml:AuthnContext>
and if Access Manager (as a Service Provider) has a contract A with uri = adroit:login:user:np, or with Allowable class =
urn:oasis:names:tc:SAML:2.0:ac:classes:Password, then it matches the contract.
NOTE: The Allowable class field is blank when an inbuilt Authentication Class is used in Identity Server.
For more information about using CloudAccess as a trusted Identity Provider, see Using NetIQ®
CloudAccess as a Trusted Identity Provider for NetIQ® Access Manager.
Methods and Available Methods: Specifies the authentication method to use for the contract.
You can specify the order in which the methods are executed for login; however, this is not a graded list, so all the methods you specify are required. Available methods are the
authentication methods you have set up.
You can enable the multi-factor authentication by associating more than one methods to a contract.
If you add more than one X.509 method, only the first one is used and it is automatically moved to the top of the list.
When you choose a secure method, such as Secure Name/Password, ensure that you have enabled security for the Identity Server configuration by setting the protocol to HTTPS. See
“Enabling SSL Communication” in the NetIQ Access Manager 4.0 SP1 Setup Guide.
5 Click Next.
6 Configure a card for the contract by filling in the following:
ID: (Optional) Specify an alphanumeric value that identifies the card. If you need to reference this card outside of the Administration Console, you need to specify a value here. If you do not assign a value, the Identity Server creates one for its internal use.
Text: Specify the text that is displayed on the card to the user.
Image: Specify the image to be displayed on the card. Select the image from the drop down list.
To add an image to the list, click Select local image.
Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.
Passive Authentication Only: Select this option if you do not want the Identity Server to prompt the user for credentials. If the Identity Server can fulfill the authentication request without any user interaction, the authentication succeeds. Otherwise, it fails.
7 Click Finish, then OK.
8 Update the Identity Server and any devices that use the Identity Server configuration.
9 To use this contract, you must configure Access Manager to use it:
You can assign it as the default contract for the Identity Server. See Section 3.5, “Specifying Authentication Defaults,” on page 137.
You can configure a protected resource to use it. See “Configuring Protected Resources” in the NetIQ Access Manager 4.0 SP1 Access Gateway Guide.
3.4.1 Using a Password Expiration Service
Access Manager works with any password management service that works with your user store. For an implementation example, see Configuring Access Manager for UserApp and SAML.
As you configure the service, be aware of the following configuration options:
“URL Parameters” on page 133
“Forcing Authentication after the Password Has Changed” on page 133
“Grace Logins” on page 134
“Federated Accounts” on page 134
“Redirection to Password Management Servlet Protected by Access Gateway When Password Expires” on page 134