5.1 Authentication Framework

To guard against unauthorized access, Access Manager supports a number of ways for users to authenticate. You configure authentication at Identity Server by creating authentication contracts that Access Manager components (such as an Access Gateway) can use to protect a resource.

Figure 5-1 illustrates the components of a contract.

Figure 5-1 Local Authentication

User stores

User stores to which users authenticate in the back-end. You set up your user store while creating an Identity Server cluster configuration. See Configuring Identity User Stores.

Classes

Implements a particular authentication type (name/password, RADIUS, X.509) or means of obtaining credentials. It specifies how Identity Server requests for the authentication information and what it must do to validate credentials. See Creating Authentication Classes.

Methods

The pairing of an authentication class with one or more user stores, and whether the method identifies a user. See Configuring Authentication Methods.

Contracts

The basic unit of authentication. Contracts can be local (executed at the server) or external (satisfied by another Identity Server). Contracts are identified by a unique URI that can be used by Access Gateways and agents to protect resources. Contracts are comprised of one or more authentication methods used to uniquely identify a user. You can associate multiple methods with one contract. See Configuring Authentication Contracts.

This section explains the following topics:

5.1.1 Creating Authentication Classes

Authentication classes let you define ways of obtaining end user credentials.

Several authentication classes are included with Access Manager to provide a variety of ways to authenticate end users. Custom authentication classes provided by other vendors can also be configured to run in the system.

Access Manager provides the following predefined classes:

  • Introductions: Allows users to select an identity provider from a list of introducable identity providers. For information about configuring it, see Configuring the Introductions Class.

  • Name/Password - Basic: Basic authentication over HTTP using a standard login pop-up page provided by the web browser.

  • Name/Password - Form: Form-based authentication over HTTP or HTTPS.

  • Secure Name/Password - Basic: Basic authentication over HTTPS using a standard login page provided by the web browser.

  • Secure Name/Password - Form: Form-based authentication over HTTPS.

  • Trust Levels: Defines authentication levels for classes that can be used in authentication requests. For information about configuring it, see Configuring the Trust Levels Class.

For information about how to create a name/password class, see the following sections:

Some classes require additional configuration to enable their use for authentication. See the following sections:

5.1.2 Creating Custom Authentication Class to Obtain Unstored Transitional Data

Follow the procedure:

  1. Click Devices > Identity Server > Servers > Edit > Local > Classes > New.

  2. Specify the following values.

    Display Name: Specify RHPClass

    Java Class: Specify Other

    Java class path: Specify com.novell.nidp.authentication.local.RequestHeaderParser

  3. Click Next.

  4. Click New to add properties.

    REQUEST_HEADERS_LDAP_ATTRIBUTE_NAME = requestHeaders

    REQUEST_HEADERS_KEY_VALUE_SEPARATOR = -->

    REQUEST_HEADERS_SEPARATOR = ||

  5. Click Local > Method > New to create a new method.

  6. Specify a name to identify the method. Example: RHPMethod

  7. Select RHPClass from Class.

  8. Deselect Identifies User.

  9. Select <Default User Store> from the list of Available User Stores.

  10. Click Devices > Identity Servers > Edit > Local > Contracts > New.

  11. Specify the following details:

    Field

    Description

    Display name

    Specify the name of the authentication contract. Example RHPContract

    URI

    Specify a unique value. It is used to identify this contract for external providers and is a unique path value that you create. No space is allowed. The following are examples:

    /mycompany/name/password/form
    http://mycompany.com/login
    secure/form/password/bcompany

    Password expiration servlet

    Specify 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, see Using a Password Expiration Service.

    Allow User Interaction

    If you specify a password expiration servlet, you can select this option. This allows 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 select this option.

    Login Redirect URL

    Specify the URL to which users will be redirected. Use this setting in the following scenarios:

    • Forcing the user to a specific home page after successful authentication.

    • Forcing the user to configure challenge/response forgotten password questions.

    For more information, see Using Login Redirect URL Parameters.

    Allow User Interaction

    Select this option to allow 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, a user frequently accesses www.a.com and have specified the redirect URL as https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>, continue will allow the user to continue with that website that is www.a.com and redirect URL will take the user 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

    Specify a number to indicate its security level or rank. This setting preserves authentication contracts of a higher security level. When you enable Satisfiable by a contract of equal or higher level, this value is used as a reference.

    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 65535 minutes and must be divisible by 5.

    If you modify the timeout value for a contract, the new value is given to users as they log in. Currently logged in users retain the old value until they re-authenticate.

    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:When Name/Password - Basic and Secure Name/Password - Basic contracts are assigned to a protected resource, the session is timed out. The session gets renewed after timeout without user’s intervention using the Basic header sent from browser to Identity Server.

    For information about using it with Access Gateway, see Assigning a Timeout Per Protected Resource.

    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. See Using Activity Realms.

    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 Authentication Level of an authentication contract.

    When you enable this option, consider 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. You must enable this option 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. While configuring an authentication request, you can select a contract when this option is enabled for the contract and require the identity provider to use this contract 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 must be used.

      Select the types from Available types 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 must be used.

      Select the contract from Available contracts. To appear in Available contracts, you must select Satisfiable by External Provider for this contract. To use the contract for federated authentication, the contract’s URI must be the same on identity provider and service provider. For information about contract options, see Configuring Authentication Contracts.

      Most third-party identity providers do not use contracts.

    Allowable Class

    Specify the class that instructs a service provider to send a request for a specific authentication type to the identity provider. You can modify this option only when you select authentication types.

    In SAML 2.0 federation with Access Manager as a service provider, if an external identity provider authenticates a user, it sends the <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 provider sends the following AuthnContext:

    <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> <saml:AuthnContextDeclRef>adroit:login:user:np</saml:AuthnContextDeclRef> </saml:AuthnContext> 

    And 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, it matches the contract.

    NOTE:Allowable class is blank when an inbuilt authentication class is used in Identity Server.

    Methods and Available Methods

    Specify 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. Example RHPMethod.

    The RHPMethod should be either the second or last in the order.

  12. Click Update All next to the required Identity Server or cluster

  13. Click Devices > Access Gateways > Edit.

  14. Click Protected Resource for the proxy service with Authentication Procedure (RHPContract).

  15. Click Policies > Policies.

  16. Select the policy container, then click New.

  17. Specify a name for the policy, select Access Gateway: Identity Injection for the LdapAttribute policy, then click OK.

  18. Update Access Gateway.

    The headers will be available in Ldap Attribute (requestHeaders) in format below. This can accessed from virtual attributes to perform modifications on the result.

  19. Click Devices > Identity Server > Shared Settings > Virtual Attributes > Virtual Attribute.

  20. Click + to create a virtual attribute. Create a virtual attribute for the requestHeaders using Advanced : Javascript Function. For more information, see Creating a Virtual Attribute.

    Sample JavaScript:

    'NameIDPolicy=' and returns value of it.
    
    function main(P1){
      return getParameter(P1,'NameIDPolicy=');
    }
    function getParameter(attribute, param){
      var str=attribute.substring(attribute.search(param));
       return  str.substring(param.length,str.search('&'));  
    }

5.1.3 Configuring Authentication Methods

Authentication methods let you associate authentication classes with user stores. A particular authentication class is used to obtain credentials about an entity, and then credentials are validated against a list of user stores.

After the entity is located in a particular user store, no further checking occurs even if credentials fail to validate the entity. Typically, this entity is a user, and the definition of an authentication method specifies whether this is the case. You can alter the behavior of an authentication class by specifying properties (name/value pairs) that override those of the authentication class.

To configure a method for an authentication class:

  1. Click Devices > Identity Servers > Edit > Local > Methods > New.

  2. Specify the following details:

    Field

    Description

    Display name

    The name of the method.

    Class

    The authentication class that will use this method. See Creating Authentication Classes.

    Advanced Authentication Chains

    (Conditional) Select a chain. If you do not specify any chain, the user is prompted to select the chain when the user authenticates.

    This option is available when the Advanced Authentication server is configured and you select AAGenericClass in Class. For more information, see Configuring Advanced Authentication.

    Identifies User

    Specifies whether this authentication method must be used to identify the user. While configuring multiple methods for a contract, you might need to disable this option for some methods.

    If you enable this option on two or more methods in a contract, these methods need to identify the same user in the same user store.

    If you enable this option on just one method in the contract, that method identifies the user when the authentication method succeeds. The other methods in the contract must succeed, but might not authenticate the user. For example, the method that identifies the user could require a name and a password for authentication, and the other method in the contract could prompt for a certificate that identifies the user’s computer.

    To achieve SSO to backend web applications when the passwordfetch class is enabled, see TID.

    Overwrite Temporary User

    If you select this option, the temporary user credentials profile got from the previous method in the same session is overwritten with real user credentials profile got from this authentication method.

    Overwrite Real User

    If you select this option, the real user credentials profile got from the previous method in the same session is overwritten with real user credentials profile got from this authentication method.

  3. Add user stores to search.

    If you have several user stores, the system searches through them based on the order specified here. If a user store is not moved to User stores, users in that user store cannot use this method for authentication.

    <Default User Store>: The default user store in your system. See Specifying Authentication Defaults.

  4. (Optional) Under Properties, click New and specify the following details:

    Field

    Description

    Advanced Authentication Property

    Select a property from the list. For more information about each property, see Optional Properties (KEY/Value) for Authentication Methods.

    Property Name

    The name of the property is case-sensitive and specific to an authentication class. You can set the same properties to an authentication class and to a method.

    You can use method properties to override the property settings specified in an authentication class. For example, you want to use an authentication class for multiple companies, but use a slightly different login page that is customized with the company’s logo. You can use the same authentication class, create a different method for each company, and use the JSP property to specify the appropriate login page for each company. For information about available properties for basic and form classes, see Specifying Common Class Properties.

    If this method is part of multi-factor authentication, you can set the following additional property:

    PRINCIPAL_MISMATCH_ERR: Specifies the error message to be displayed if this method identifies a different principal than other methods in the multi-factor authentication. Specify the value in the Property Name field.

    RADIUS classes have the following additional properties:

    • RADIUS_LOOKUP_ATTR: Defines an LDAP attribute whose value is read and used as the ID is passed to the RADIUS server. If not specified, the user name entered is used.

    • NAS_IP_ADDRESS: Specifies an IP address used as a RADIUS attribute. You might use this property for situations in which service providers are using a cluster of small network access servers (NASs). The value you enter is sent to the RADIUS server.

    The following property is available for RADIUS methods in Access Manager 5.0 Service Pack 1 and later:

    RADIUS_AUTHN_FIRST: Set this property to true if you want RADIUS authentication to be performed first preceded by LDAP authentication. By default, this property is set to false.

  5. Click Finish.

  6. Continue with Section 5.1.4, Configuring Authentication Contracts. To use a method for authenticating a user, each method must have an associated contract.

5.1.4 Configuring Authentication Contracts

Authentication contracts define how authentication occurs. An Identity Server can have several authentication contracts, such as name/password, X.509, or Kerberos. From the available contracts, you assign a contract to specific resources. Access to a resource triggers the authentication process. If a user has already supplied the required credentials for the contract, the user is not prompted for them again.

Each contract is assigned a unique URI. You can share this URI with other providers so that they can identify the type of credentials the identity provider requires. You can also restrict a contract to be used only for local authentication.

  1. Click Devices > Identity Servers > Edit > Local > Contracts > New.

  2. Specify the following details:

    Field

    Description

    Display name

    Specify the name of the authentication contract.

    URI

    Specify a unique value. It is used to identify this contract for external providers and is a unique path value that you create. No space is allowed. The following are examples:

    /mycompany/name/password/form
    http://mycompany.com/login
    secure/form/password/bcompany

    Password expiration servlet

    Specify 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, see Using a Password Expiration Service.

    Allow User Interaction

    If you specify a password expiration servlet, you can select this option. This allows 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 select this option.

    Login Redirect URL

    Specify the URL to which users will be redirected. Use this setting in the following scenarios:

    • Forcing the user to a specific home page after successful authentication.

    • Forcing the user to configure challenge/response forgotten password questions.

    For more information, see Using Login Redirect URL Parameters.

    Allow User Interaction

    Select this option to allow 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, a user frequently accesses www.a.com and have specified the redirect URL as https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>, continue will allow the user to continue with that website that is www.a.com and redirect URL will take the user 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

    Specify a number to indicate its security level or rank. This setting preserves authentication contracts of a higher security level. When you enable Satisfiable by a contract of equal or higher level, this value is used as a reference.

    For example, create a name/password authentication contract and assign it to level one. 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.

    Note: If two contracts have the same methods but different authentication levels, then methods take precedence.

    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 65535 minutes and must be divisible by 5.

    If you modify the timeout value for a contract, the new value is given to users as they log in. Currently logged in users retain the old value until they re-authenticate.

    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:When Name/Password - Basic and Secure Name/Password - Basic contracts are assigned to a protected resource, the session is timed out. The session gets renewed after timeout without user’s intervention using the Basic header sent from browser to Identity Server.

    For information about using it with Access Gateway, see Assigning a Timeout Per Protected Resource.

    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. See Using Activity Realms.

    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 Authentication Level of an authentication contract.

    When you enable this option, consider 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. You must enable this option 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. While configuring an authentication request, you can select a contract when this option is enabled for the contract and require the identity provider to use this contract 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 must be used.

      Select the types from Available types 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 must be used.

      Select the contract from Available contracts. To appear in Available contracts, you must select Satisfiable by External Provider for this contract. To use the contract for federated authentication, the contract’s URI must be the same on identity provider and service provider. For information about contract options, see Configuring Authentication Contracts.

      Most third-party identity providers do not use contracts.

    Allowable Class

    Specify the class that instructs a service provider to send a request for a specific authentication type to the identity provider. You can modify this option only when you select authentication types.

    In SAML 2.0 federation with Access Manager as a service provider, if an external identity provider authenticates a user, it sends the <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 provider sends the following AuthnContext:

    <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef> <saml:AuthnContextDeclRef>adroit:login:user:np</saml:AuthnContextDeclRef> </saml:AuthnContext> 

    And 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, it matches the contract.

    NOTE:Allowable class is blank when an inbuilt authentication class is used in Identity Server.

    Methods and Available Methods

    Specify 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 Identity Server configuration by setting the protocol to HTTPS. See Enabling SSL Communication.

  3. Click Next.

  4. Specify the following details to configure a card for the contract:

    Field

    Description

    ID

    (Optional)

    Specify an alphanumeric value that identifies the card. If you need to reference this card outside of Administration Console, specify a value here. If you do not assign a value, Identity Server creates one for its internal use.

    Text

    Specify the text that is displayed on the card to the user.

    Image

    Select the image to be displayed on the card.

    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 if you do not want Identity Server to prompt users for credentials. If Identity Server can fulfill the authentication request without any user interaction, the authentication succeeds. Otherwise, it fails.

  5. Click Finish > OK.

  6. Update Identity Server and any devices that use Identity Server configuration.

  7. To use this contract, you must configure Access Manager to use it.

Configuring Options for an Authentication Contract

You can configure an authentication contract to perform the following actions:

Perform the following steps:

  1. Click Identity Servers > Edit > Local > Contracts > [Contract Name] > Options > New.

  2. Specify the following details:

    Property

    Description

    AUTHENTICATE WITH EXPIRED PASSWORD

    Select Property Value as true to redirect a user logging with an expired password to the password management URI protected by an Access Gateway.

    HIDE CARDS WITH EQUAL LEVEL

    Select Property Value as true to disable showing another higher level authentication cards, if Satisfiable by a contract of equal or higher level is enabled.

    OTHER

    Specify Property Name and Value to configure another property.

  3. Click OK.

Using a Password Expiration Service

Access Manager supports any password management service that works with your user store. For an implementation example, see Configuring Access Manager for UserApp and SAML.

Configure the following options:

URL Parameters

When you define the URL for the password service on the Contracts page, you can use the following optional tags in the parameter definitions of the URL. Use parameter names that are understood by the service you have selected to use. Identity Server does not need to understand these parameters, but the password expiration service needs to understand them.

The following table lists common parameters. Your service might not use these and require others.

Parameter

Description

<USERID>

Provides the DN of the user with a password that is expired or expiring.

<STOREID>

Provides the name of the user store that authenticated the user before redirecting the user to the password expiration service.

<RETURN_URL>

Provides the URL at Identity Server to which the user can be redirected after the password service completes.

action=expire

Causes the password expiration service to act as though the user’s password policy is set to allow the user to reset the password even though the user’s policy might be set to show the user a hint. The user sees the page to create a new password rather than seeing a hint for an existing password.

Example:

https://someservice.com/path/password?user=<USERID>&store=<STOREID>
&returl=<RETURN_URL>&action=expire

NOTE:If you copy this text, ensure to remove the white space between <STOREID> and &returl.

Identity Server fills in these values, which results in the following URL:

https://someservice.com/path/password?user=joe.novell&store=userstore1& returl=https://myidp.com/nidp/idff/sso&action=expire

Forcing Authentication after the Password Is Changed

The password service can also include parameters on the return URL sent to Identity Server. Identity Server understands the following parameter:

Parameter

Description

forceAuth=TRUE

When a user is returned to Identity Server, this parameter forces the user to authenticate with the new password. This eliminates the possibility of an old password being used in an Identity Injection policy.

The following example sends this parameter with https://testnidp.novell.com:8443 as the base URL of Identity Server:

<form id="externalForm" action='https://testnidp.novell.com:8443/nidp/idff/sso?sid=0&id=117&forceAuth=TRUE' method="post">

When a user is redirected to the password management service URL because of an expired password, the POST data in that redirect contains sid=<> and id=<> values as part of the value used for Identity Server return URL.

Grace Logins

If you specify a password service and do not specify a value for the number of grace logins in eDirectory, the contract redirects to the password management service only when the grace login count has reached 0 and the password has expired.

Identity Server needs to read the value of the grace login attribute to properly redirect to the password management servlet. If restricting grace logins is not important to your security model, enable grace logins and set the maximum to 9999 (the equivalent of infinite in most environments). For more information, see TID 3465171.

Federated Accounts

A user’s password does not expire and grace logins are not decremented in the following setup:

  • Identity Server is configured to act as a service provider

  • User identification is configured to allow federation

  • Federation is set up with SAML 2.0, Liberty, or WS Federation protocols

The password expiration service is not called because the user is not using a password for authentication. The service can only be called when the user’s account is defederated. After the user defederates the account and logs in, a password is required and the service is called.

Redirection to Password Management Servlet Protected by Access Gateway When Password Expires

When an Active Directory user with an expired password logs in to an authentication contract with a Password Expiration servlet configured, the user is redirected to the password management URI. If the Password Management portal is protected by Access Manager, the user is prompted again for authentication and is not permitted to login as the user password has expired.

If you want the user to be redirected to Password Management Servlet, perform the following steps:

  1. Click Devices > Identity Servers > Edit > Local > Methods.

  2. Select the authentication method, which is used by the contract where Password Management Servlet is configured.

  3. Add the following property for the method used by contract with Password Expiration servlet:

    Property Name = ExpiredCheck

    Property Value = true

  4. Go to Identity Servers > Edit > Local > Contracts.

  5. Click the associated contract > Options > New.

  6. Select AUTHENTICATE WITH EXPIRED PASSWORD in Property Type and true in Property Value.

  7. Click OK > Apply.

  8. Update Identity Server.

Using Login Redirect URL Parameters

While defining the login redirect URL on the Contracts page, you can use the following optional tags in the parameter definitions of the URL. Use parameter names that are understood by the service you have selected to use. The login redirect URL must understand the name-value pairs you have defined and will use the resolved values in the redirected URL.

Parameter

Description

<USERID>

DN of the user with a password that is expired or expiring.

<STOREID>

The name of the user store that authenticated a user before redirecting the user to the password expiration service.

<RETURN_URL>

The URL at Identity Server to which a user is redirected after the password service is completed.

For example:

https://someservice.com/path/password?user=<USERID>&store=<STOREID>
&returl=<RETURN_URL>

NOTE:If you copy this text, you must remove the white space between <STOREID> and &returl.

Identity Server fills in these values that results in the following URL:

https://someservice.com/path/password?user=joe.novell&store=userstore1& returl=https://myidp.com/nidp/idff/sso

In addition to these parameters, you can configure other parameters.

Using Activity Realms

Activity realms are used when Access Manager uses multiple contracts to protect resources that require different activity timeouts. Activity realms allow you to define how activity at one protected resource affects the activity timeout at another protected resource.

An activity realm represents a time line that tracks the last activity for any resource that is protected by a contract assigned to the activity realm. When a protected resource is accessed, the activity realm associated with the contract is marked as active. The contract times out for a protected resource when the elapsed time for activity on the activity realm is greater than the time limit specified in the contract.

For example, you create an activity realm called shared1 and assign it to contract C1 with a timeout of 30 minutes and to contract C2 with a timeout of 15 minutes. Any activity at the resource protected by C1 or C2 marks activity to the shared1 time line. Figure 5-2 illustrates this scenario.

Figure 5-2 Two Contracts Sharing an Activity Realm

In Figure 5-2, the user logs into PR1 at time 0, then logs into PR2 at time 6. During the next 30 minutes, the user is active on PR1. The time line for the shared1 activity realm is updated with the user’s activity. The user then access PR2 at time 38. Even though no activity has taken place on PR2 for more than the 15-minute contract time-out, PR2 does not time out because activity has occurred within this time at PR1 and because the resources share the same activity realm. Assigning two or more contracts to the same activity realm allows the contracts to influence the time-outs of the other contracts in the activity realm.

When you configure protected resources to use different contracts with different time-outs, they can keep each other alive when they share the same activity realm. If protected resources must not affect each other's activity, they must not share a common activity realm.

You can assign a contract to multiple activity realms. With this configuration, activity on a resource updates the time lines of all activity realms associated with the contract. As long as one of the activity realms has activity within the contract’s time-out limit, the user’s session remains authenticated.

Activity realms are defined by specifying a name, and the names are case insensitive. Use a comma-separated list to specify multiple names. The system has two default realms that you can use:

  • Any: Leave the field blank or specify any when you want the user’s session to remain alive as long as there is some activity by the user at Access Gateway or at Identity Server.

    When Identity Server receives an assertion from another Identity Server that cannot be mapped to a contract, the activity realm is set to any with the time-out value equal to the value of the Tomcat session. (The Tomcat session timeout is set to the greatest time-out value of the contracts configured for Identity Server.)

  • NIDPActivity: Specify NIDPActivity for the realm when any activity at Identity Server by the user can be used to keep the user’s session alive.

When you place multiple contracts in the same activity realm, plan carefully so that security limits aren’t overruled by activity on less critical protected resources. You also need to carefully balance the desire for single sign-on with the need to require reauthentication for sensitive data. Highly sensitive resources are most secure when they are protected by a contract that is created from its own unique method and that is assigned its own unique activity realm. For more information, see Assigning a Timeout Per Protected Resource.

5.1.5 Specifying Authentication Defaults

You can specify default values for how the system processes user stores and authentication contracts. The default contract is executed when users access the system without a specified contract, and when Access Gateway is configured to use any authentication.

Additional default contracts can be specified for well-known authentication types that might be required by a service provider. These contracts are executed when a request for a specific authentication type comes from a service provider.

  1. Click Devices > Identity Servers > Edit > Local > Defaults.

  2. Specify the following details as necessary:

    Field

    Description

    User Store

    Specifies the default user store for local authentication. If you selected <Default User Store> when configuring an authentication method, Access Manager uses the user store you specify here.

    Authentication Contract

    Specifies the default authentication contract to be used when users access Identity Server directly or a protected resource is configured to use Any Contract. If you create a new contract and specify it as default, ensure that you update the Access Gateway configuration if it has protected resources configured to use Any Contract.

    Authentication Type

    Specifies the default authentication contracts to be used for each authentication type. When a service provider requests a specific authentication type, rather than a contract, the identity provider uses the authentication contract specified here for the requested authentication type. See Specifying Authentication Types.

  3. Click OK.

  4. Update Identity Server.

Specifying Authentication Types

Trusted service providers can send Identity Server an authentication request that contains a request for contract or for an authentication type. When the request is for an authentication type, Identity Server must translate the type to a contract before authenticating the user. You can use the Authentication Type section of the Defaults page to specify which contract to use for the common types (classes).

Identity Server has not implemented all possible types. For types that do not appear on the Defaults page, you can do one of the following:

  • Define a contract for a class whose URI matches the requested class type. When Identity Server receives the authentication request, it uses the URI to match the request with a contract.

    Creating such a contract state that the contract is security equivalent to the class that is being requested. For more information, see Creating a Contract for a Specific Authentication Type.

  • Use the Trust Levels class to assign an authentication level for the requested class. This level is used to rank the requested type. Using the authentication level and the comparison context, Identity Server can determine whether any contract meets the requirements of the request. If one or more contracts match the request, the user is prompted with the appropriate authentication contract.

    For more information, see Configuring the Trust Levels Class.

Creating a Contract for a Specific Authentication Type

The following steps explain how to create a contract that matches what a trusted service provider is asking for in its authentication request.

  1. Click Devices > Identity Servers > Edit > Local > Contracts > New.

  2. Specify the following details:

    Field

    Description

    Display name

    Specify the name of the authentication contract.

    URI

    Specify a unique value. This value must match what the service provider is sending in its authentication request for the type.

    Authentication Level

    (Optional) Specify a security level or rank for the contract. This value is not used when authentication request sets the comparison type to exact. It is only used when a contract is selected based on a comparison of authentication levels.

    If the service provider sets the comparison type to minimum, the authentication level can be the same or higher. If the comparison type is set to better, the authentication level must be higher.

    Methods

    Select the method that matches the class or type you specified in URI.

    Other fields for the contract are not requirements of the authentication request and can be configured to meet the requirements of Identity Server. For information about these fields, see Configuring Authentication Contracts.

  3. Click Next.

  4. Configure an authentication card for the contract. See Configuring Authentication Contracts.

  5. Click Finish > OK.

  6. Update Identity Server.