4.1 Local Authentication

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 4-1 illustrates the components of a contract.

Figure 4-1 Local Authentication

  • User stores: The user directories to which users authenticate in the back-end. You set up your user store when you create an Identity Server cluster configuration. See Section 4.1.1, Configuring Identity User Stores.

  • Classes: The code (a Java class) that implements a particular authentication type (name/password, RADIUS, and X.509) or means of obtaining credentials. Classes specify how Identity Server requests authentication information, and what it must do to validate those credentials. See Section 4.1.2, 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:

4.1.1 Configuring Identity User Stores

User stores are LDAP directory servers to which end users authenticate. You must specify an initial user store when configuring Identity Server. The procedure for setting up the initial user store, adding a user store, or modifying an existing user store is same.

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

  2. Select from the following actions:

    New: To add a user store, click New. For more information, see Configuring the User Store.

    Delete: Select the user store, then click Delete.The user store list needs to contain at least one configured user store for Identity Server to be functional.

    Modify: To modify the configuration of an existing user store, click the name of a user store. For configuration information, see Configuring the User Store.

  3. Click OK, then update Identity Server if you have modified the configuration.

See the following sections for specific configuration tasks:

Using More Than One LDAP User Store

You can configure Identity Server to search for more than one user store during authentication. Figure 4-2 illustrates this type of configuration.

Figure 4-2 Multiple LDAP Directories

It is assumed that each LDAP directory contains different users. Ensure that the users have unique names across all LDAP directories. If both directories contain a user with an identical name, the name and password information discovered in the search of the first directory is always used for authentication. You can specify the search order when configuring the authentication method.

When users are added to the configuration store, objects are created for Access Manager profiles. If you delete a user from the LDAP directory, orphaned objects for that user remain in the configuration store.

If you add a secondary Administration Console and you have added replicas to the user store of the primary Administration Console, ensure to add the replicas to the secondary Administration Console.

All user stores that you add are included in health checks. If health problems occur, the system displays the user store on the Health page and in the trace log file.

Configuring the User Store

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

  2. In the User Stores list, click New or the name of an existing user store.

    If you are creating an Identity Server configuration, this is Step 3 of the wizard.

  3. Specify the following details:

    Field

    Description

    Name

    The name of the user store for reference.

    Admin Name

    The distinguished name of the admin user of the LDAP directory, or a proxy user with specific LDAP rights to perform searches. For the LDAP extension to work, the proxy user requires write rights on the ACL. Administrator-level rights are required for setting up a user store. This ensures read/write access to all objects used by Access Manager. For more information about this user, see Configuring an Admin User for the User Store.

    Each directory type uses a slightly different format for the DN:

    • eDirectory: cn=admin,ou=users,o=novell

    • Active Directory: cn=Administrator,cn=users,dc=domeh,dc=test,dc=com

      or cn=john smith,cn=users,dc=domeh,dc=test,dc=com

    • Sun ONE: cn=admin,cn=users,dc=novell,dc=com

    Admin Password and Confirm Password

    Specify the password for the admin user and confirm it.

    Directory Type

    Select eDirectory, Active Directory, or Sun ONE. If you have installed an LDAP server plug-in, you can select the custom type that you have configured it to use. For more information, see LDAP Server Plug-In in the NetIQ Access Manager 4.5 SDK Guide.

    If eDirectory has been configured to use Domain Services for Windows, eDirectory behaves like Active Directory. When you configure such a directory to be a user store, its Directory Type must be set to Active Directory for proper operation.

    Install NMAS SAML method

    (eDirectory only) Extends the schema on the eDirectory server and installs an NMAS method. This method converts Identity Server credentials to a form understood by eDirectory. This method is required if you have installed Novell SecretStore on the eDirectory server and you are using that SecretStore for Access Manager secrets. If you select this option, ensure that the admin configured for the user store has sufficient rights to extend the schema and add objects to the tree.

    For more information, see Configuring a User Store for Secrets.

    Enable Secret Store lock checking

    (eDirectory only) Enables Access Manager to prompt users for a passphrase when secrets are locked.

    • If Access Manager shares secrets with other applications and these applications use the security flag that locks secrets when a user’s password is reset, you need to select this option.

    • If Access Manager does not share secrets with other applications, the secrets are never locked, and you do not need to select this option.

  4. Under LDAP timeout settings, specify the following details:

    Field

    Description

    LDAP Operation

    Specify how long a transaction can take before timing out in seconds.

    Idle Connection

    Specify how long before connections begin closing in seconds. If a connection has been idle for the specified duration, the system creates another connection.

  5. To specify a server replica, click New, then specify the following details:

    For an eDirectory server, you must use a replica of the partition where the users reside. Ensure that each LDAP server in the cluster has a valid read/write replica. One option is to create a users partition (a partition that points to the OU containing the user accounts) and reference this server replica.

    Field

    Description

    Name

    The display name for the LDAP directory server. If your LDAP directory is replicated on multiple servers, use this name to identify a specific replica.

    IP Address

    The IP address of the LDAP directory server.

    Port

    The port of the LDAP directory server. Specify 389 for the clear text port, and 636 for the encrypted port.

    Use secure LDAP connections

    Specifies that the LDAP directory server requires secure (SSL) connections with Identity Server.

    This is the only recommended configuration for the connection between Identity Server and the LDAP server in a production environment. If you use port 389, usernames and passwords are sent in clear text on the wire.

    Enable this option if you use this user store as a Novell SecretStore User Store Reference in the Credential Profile details. See Configuring Credential Profile Security and Display Settings. If you specify that this user store is a SecretStore User Store Reference, this option is enabled but not editable.

    Connection limit

    The maximum number of pooled simultaneous connections allowed to the replica. Valid values are between 5 and 50. How many you need depends upon the speed of your LDAP servers. If you modify the default value, monitor the change in performance. Larger numbers do not necessarily increase performance.

  6. Click Auto import trusted root.

  7. Click OK to confirm the import.

  8. Select one of the certificates in the list.

    You are prompted to choose either a server certificate or a root CA certificate. To trust one certificate, choose Server Certificate. Choose Root CA Certificate to trust any certificate signed by that certificate authority.

  9. Specify an alias, then click OK.

  10. Click OK in Specify server replica information.

  11. Select the replica and click Validate to test the connection between Identity Server and replica.

    The system displays the result under Validation Status. The system displays a green check mark if the connection is valid.

  12. (Optional) To add additional replicas for the same user store, repeat Step 5 through Step 11.

    Adding multiple replicas adds load balancing and failover to the user store. Replicas must be exact copies of each other.

    For load balancing, a hash algorithm is used to map a user to a replica. All requests on behalf of that user are sent to that replica. Users are moved from their replica to another replica only when their replica is no longer available.

  13. Add a search context.

    The search context is used to locate users in the directory when a contract is executed.

    • If a user exists outside of the specified search context (object, subtree, one level), Identity Server cannot find the user, and the user cannot log in.

    • If the search context is too broad, Identity Server might find more than one match, in which case the contract fails, and the user cannot log in.

    For example, if you allow users to have the same username and these users exist in the specified search context, these users cannot log in if you are using a simple username and password contract. The search for users matching this contract would return more than one match. In this case, you need to create a contract that specifies additional attributes so that the search returns only one match. For more information about how to create such contracts, see Authentication Classes and Duplicate Common Names.

    IMPORTANT:For Active Directory, do not set the search context at the root level and set the scope to Subtree. This setting can cause serious performance problems. It is recommended that you set multiple search contexts, one for each top-level organizational unit.

  14. Click Finish.

  15. If prompted to restart Tomcat, click OK. Otherwise, update Identity Server.

Configuring an Admin User for the User Store

Identity Server must log in to each configured user store. It searches for users, and when a user is found, it reads the user’s attributes values. When you configure a user store, you must supply the distinguished name of the user you want Identity Server to use for logging in. You can use the admin user of your user store, or you can create a specialized admin user for the this purpose. When creating this admin user, you need to grant the following rights:

  • The admin user needs rights to browse the tree, so Identity Server can find the user who is trying to authenticate. The admin user needs browse rights to object class that defines the users and read and compare rights to the attributes of that class. When looking for the user, Identity Server uses the GUID and naming attributes of the user class.

    Directory

    Object Class

    GUID Attribute

    Naming Attribute

    eDirectory

    User

    guid

    cn

    Active Directory

    User

    objectGUID

    sAMAccountName

    Sun ONE

    inetOrgPerson

    nsuniqueid

    uid

  • The admin user needs read rights to any attributes used in policies (Role, Form Fill, Identity Injection).

  • If a secret store is used in Form Fill policies, the admin user needs write rights to the attributes storing the secrets.

  • If a password management servlet is enabled, the admin user needs read rights to the attributes controlling grace login limits and remaining grace logins.

  • If you use an LDAP extension, the user must have write rights on ACL allowing the user to check for account locks, password expiration, grace logins used, and so on.

    To perform these operations, the user must have additional rights. Access Manager uses NMAS that requires the user to have write rights on ACL.

  • If you enable provisioning with the SAML or Liberty protocols, the admin user needs write rights to create users in the user store.

  • If you use X.509 authentication, the admin user needs write rights to update the user’s login status attributes.

If your user store is an eDirectory user store, Access Manager verifies that the admin user has sufficient rights to browse for users in the specified search contexts.

IMPORTANT:This check is not performed for Active Directory or Sun ONE. If your users cannot log in, verify that the user store admin has appropriate rights to the specified search contexts.

Configuring a User Store for Secrets

Access Manager allows you to securely store user secrets. Secrets are a way to capture user input, such as Login ID and password credentials. These input data can later be reused or injected using Form Fill and Identity Injection policies. This feature is helpful when your Access Manager Credential Profile does not contain credentials for an application protected by Access Manager yet a single sign-on experience is required. Where and how the secrets can be stored is configurable and depends upon your user store:

For troubleshooting tips, see Troubleshooting Secrets Storage.

Configuring the Configuration Datastore to Store Secrets

If you want to do minimal configuration, use the configuration datastore on Administration Console to store the secrets. You can use this option without changes, but is recommended only for use in small Access Manager environments. To increase the security of the secrets, NetIQ recommends that you change the default security options. When you use the configuration datastore of Administration Console as the secret store, the nidswsfss attribute of the nidsLibertyUserProfile object is used to store the secrets.

IMPORTANT:Using this option adds additional load on Administration Console and introduces login delays compared to other options. Therefore, it is recommended that this option is used wisely.

  1. Click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click Credential Profile.

  3. Scroll to the Local Storage of Secrets section and configure the following security options:

    Encryption Password Hash Key: (Required) Specify the password that you want to use as a seed to create the encryption algorithm. To increase the security of the secrets, we recommend that you change the default password to a unique alphanumeric value.

    IMPORTANT:Before using Access Manager to store and encrypt secrets, ensure that you choose your Preferred Encryption Method and change the default Encryption Password Hash Key value. If any of these options is changed after secrets are stored, Access Manager cannot retrieve the secrets.

    Preferred Encryption Method: Specify the preferred encryption method. Select the method that complies with your security model:

    • Password Based Encryption With MD5 and DES: MD5 is an algorithm that is used to verify data integrity. Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key.

    • DES: Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key. Like other private key cryptographic methods, both the sender and the receiver must know and use the same private key.

    • Triple DES: A variant of DES in which data is encrypted three times with standard DES, using two different keys.

    Extended Schema User Store References: Do not specify a user store reference. When this option contains no values, the configuration datastore is used to store the secrets.

  4. Click OK.

  5. Update Identity Server.

  6. To use the secret store to store policy secrets, see Creating and Managing Shared Secrets.

Configuring an LDAP Directory to Store the Secrets

This is the recommended option. You can use it with any LDAP directory. To use this option, extend the schema to add an attribute to your user object on the LDAP directory that will encrypt and store the secrets.

When you use an LDAP directory to store the secrets, you need to enable the user store for the secrets. You select the LDAP directory, then specify an attribute. The attribute you specify is used to store an XML document that contains encrypted secret values. This attribute must be a single-valued case ignore string that you have defined and assigned to the user object in the schema.

To use an LDAP directory to store secrets, your network environment must conform to the following requirements:

  • The user class object must contain an attribute that can be used to store the secrets. This attribute must be a string attribute that is single valued and case ignore.

  • The user store must be configured to use secure connections (click Devices > Identity Servers > Edit > Local > User Stores > [User Store Name]. In the Server replicas section, ensure that the Port is 636 and that Use SSL is enabled. If not, click the name of the replica and reconfigure it.

To configure the LDAP directory, perform the following steps:

  1. Click Devices > Identity Servers > Edit > Liberty > Web Service Providers.

  2. Click Credential Profile.

  3. Scroll to the Local Storage of Secrets section and configure the following options:

    Encryption Password Hash Key: (Required) Specifies the password that you want to use as a seed to create the encryption algorithm. To increase the security of the secrets, we recommend that you change the default password to a unique alphanumeric value.

    Preferred Encryption Method: Specifies the preferred encryption method. Select the method that complies with your security model:

    • Password Based Encryption With MD5 and DES: MD5 is an algorithm that is used to verify data integrity. Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key.

    • DES: Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key. Like other private key cryptographic methods, both the sender and the receiver must know and use the same private key.

    • Triple DES: A variant of DES in which data is encrypted three times with standard DES, using two different keys.

    IMPORTANT:Before using Access Manager to store and encrypt secrets, ensure that you choose your Preferred Encryption Method and change the default Encryption Password Hash Key value. If either of these options are changed after any secrets are stored, Access Manager will not be able to retrieve the secrets.

  4. To specify where to store secret data, click New under Extended Schema User Store References and fill in the following:

    User Store: Select the user store where you want secret store enabled.

    Attribute Name: Specify the LDAP attribute that you have created to store the secrets on the selected user store.

  5. Click OK twice.

  6. On Identity Servers page, update Identity Server.

  7. To create policies that use the stored secrets, see Creating and Managing Shared Secrets.

For troubleshooting information, see Troubleshooting Secrets Storage.

Configuring an eDirectory User Store to Use SecretStore

If your user store is eDirectory and you have installed Novell SecretStore, you can choose to use the SecretStore on your eDirectory server to store the secrets. This differs from the schema extension method as Novell SecretStore can also be accessed and managed by NetIQ SecureLogin. This allows secrets to be shared with SecureLogin to provide a thick client single sign-on while Access Manager can provide a web single sign-on experience without credential collisions.

For Access Manager to use Novell SecretStore, the user store must be eDirectory and Novell SecretStore must be installed there. When configuring this user store for secrets, Access Manager extends the eDirectory schema for an NMAS method. This method converts authentication credentials to a form understood by eDirectory. For example, Access Manager supports smart card and token authentications, and these authentication credentials must be converted into the username and password credentials that eDirectory requires. This allows Identity Server to authenticate as that user and access the user’s secrets. Without this NMAS method, Identity Server is denied access to the user’s secrets.

To use a remote SecretStore, your network environment must conform to the following requirements:

  • The eDirectory server must have Novell SecretStore installed.

  • When you configure a user store to use Novell SecretStore, the admin user that you have configured for the user store must have sufficient rights to extend the schema on the eDirectory server, to install the SAML NMAS method, and set up the required certificates and objects. For more information about the rights required, see Configuring an Admin User for the User Store.

  • The user store must be configured to use secure connections (click Access Manager > Identity Servers > Edit > Local > User Stores > [User Store Name]. In the Server replicas section, ensure that the Port is 636 and that Use SSL is enabled. If they aren’t, click the name of the replica and reconfigure it.

    NOTE:While configuring new replicas for the same user store, by default the Use secure LDAP connections option will be selected and the default port will be 636. The Use secure LDAP connections option will be non-editable.

  • If you have enabled a firewall between Administration Console and the user store, and between Identity Server and the user store, ensure that both LDAP ports (389 and 636) and the NCP port (524) are opened.

  • If you are going to configure Access Manager to use secrets that are used by other applications, you need to plan a configuration that allows the user to unlock a locked SecretStore. See Determining a Strategy for Unlocking SecretStore.

To configure the user store:

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

  2. Click the name of your user store.

  3. Select Install NMAS SAML method, then click OK.

    This installs a required NMAS method in the eDirectory schema and adds required objects to the tree.

    IMPORTANT:If your eDirectory user store is running on SLES 11 SP1 64-bit operating system (or a later version), the eDirectory server is missing some support libraries that this SAML method requires. For information about installing these libraries, see TID 7006437.

  4. Click Liberty > Web Service Providers.

  5. Click Credential Profile.

  6. Scroll to the Remote Storage of Secrets section.

  7. Click New under Novell Secret Store User Store References.

    This adds a reference to a user store where SecretStore has been installed.

  8. Click the user store that you configured for SecretStore.

  9. Click OK twice.

  10. On Identity Servers page, update Identity Server.

  11. Continue with one of the following:

Determining a Strategy for Unlocking SecretStore

When an administrator resets a user's password, secrets written to SecretStore with an enhanced security flag become locked. Identity Server does not write the secrets that it creates with this flag, but other applications might:

  • If Access Manager is not sharing secrets with other applications, the secrets it is using are never locked, and you do not need to configure Access Manager to unlock secrets.

  • If Access Manager is sharing secrets with other applications and these application are using the security flag that locks secrets when a user’s password is reset, you need to configure Access Manager so that users can unlock their secrets.

If you want users to receive a prompt for a passphrase when secrets are locked, perform the following steps:

  1. Require all users to set up a passphrase (also called the Master Password).

    Access Manager uses the SecretStore Master Password as the passphrase to unlock the secrets. If the user has not set a passphrase before SecretStore is locked, this feature of Access Manager cannot unlock SecretStore. If it is necessary to unlock SecretStore by using the user’s prior password, another tool must be used. See the SecretStore documentation.

  2. Configure Identity Server to perform the check:

    1. Click Devices > Identity Servers > Edit > Local > [User Store Name].

    2. Select the Enable Secret Store lock checking option.

    3. Click OK > OK, then update Identity Server.

  3. Ensure that Web Services Framework is enabled:

    1. Click Devices > Identity Servers > Edit > Liberty > Web Services Framework.

    2. In the Framework General Settings section, ensure that Enable Framework is selected.

    3. Click OK. If you made any changes, update Identity Server.

  4. Continue with Section 10.5.4, Creating and Managing Shared Secrets.

When SecretStore is locked and users log in, the users are first prompted for their login credentials, then prompted for the passphrase that is used to unlock SecretStore.

Troubleshooting Secrets Storage

Secrets Are Not Stored in Novell SecretStore

When you use Novell SecretStore to store the secrets, the schema on the eDirectory server must be extended, and specific SAML objects and certificates must be created.

To verify that the schema was extended and the objects were created on the eDirectory server:

  1. Open an LDAP browser and connect to the LDAP server.

  2. Browse to the Security container.

  3. Look for objects similar to the following:

    If the schema has been extended correctly, you can find a SAML Assertion object in the Authorized Login Methods container. The SAML_Assertion object contains an alphanumeric generated name for a SAML affiliate object. This object has four attributes.

    The SAML affiliate object name is used to generate another container in the Security container. This new container is the <AffiliateObjectName> Trusted Root container that contains public key signing certificate.

  4. Complete one of the following:

  5. In Administration Console, modify the secret store configuration so that it is resent to the user store:

    1. Click Devices > Identity Servers > Edit > Liberty > Web Service Providers > Credential Profile.

    2. In the Remote Storage of Secrets section, remove the user store, then add it again.

    3. Click OK.

  6. Update Identity Server.

Users Are Receiving Invalid Credential Messages

The <SAML_Affiliate_Object>.SAML-Assertion.AuthorizedLoginMethods.Security object contains two attributes that determine how long credentials are valid. If your Identity Server and eDirectory server are not time synchronized, the credentials can become invalid before a user has time to use them.

Ensure that the time of your Identity Server and eDirectory server are synchronized, or increase the value of the authsamlValidAfter and authsamlValidBefore attributes of the SAML affiliate object.

Secrets Are Not Stored in the LDAP Directory

  1. Open an LDAP browser and connect to the eDirectory server.

  2. Browse to the user object.

  3. Verify that the user object contains the LDAP attribute that you have specified as the attribute to store the secrets.

  4. If the attribute exists, browse to the schema and verify that the attribute has the following characteristics:

    • Single valued

    • Case ignore

    • String

4.1.2 Creating Authentication Classes

Authentication classes let you define ways of obtaining end user credentials.You specify the code (Java class) and properties to be executed to implement a particular authentication type.

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.

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

    The following classes are predefined for Access Manager:

    • Introductions: When the class is configured, it allows users to select an identity provider from a list of introducable identity providers. For information about how to configure and use this class, 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: When this class is configured, it defines authentication levels for classes that can be used in authentication requests. For more information about how to configure and use this class, see Configuring the Trust Levels Class.

  2. To delete a class, select the class, then click Delete.

    You cannot delete a class if a method is using it.

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:

Creating Basic or Form-Based Authentication Classes

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

  2. Click New to launch the Create Authentication Class Wizard.

  3. Specify a display name, then select a class from the Java class list.

    The following classes are recommended only for testing purposes:

      • BasicClass: Uses basic HTTP authentication.

      • PasswordClass: Passes the user name and password over HTTP in readable text, and uses a form-based login to collect the name and password.

      • RadiusClass: RADIUS enables communication between remote access servers and a central server. For a production environment, use ProtectedRadiusClass.

    For a production environment, select one of the following protected classes:

    • X509Class: Certificate-based authentication. See Mutual SSL (X.509) Authentication.

    • SocialAuthClass: The authentication class used for implementing authentication through external OAuth providers such as Facebook, GooglePlus, LinkedIn and Twitter. See Section 4.4, Social Authentication.

    • TOTPClass: The authentication class used for implementing two-factor authentication. See Two-Factor Authentication Using Time-Based One-Time Password.

    • Risk-based Auth Class: The authentication class used for assessing the risk after authentication. See Risk-based Authentication.

    • Risk-based Pre-Auth Class: The authentication class used for assessing the risk before authentication. See Risk-based Authentication.

    • ProtectedBasicClass: BasicClass protected by HTTPS.

    • ProtectedPasswordClass: PasswordClass protected by HTTPS (form-based).

    • ProtectedRadiusClass: RadiusClass protected by HTTPS. See RADIUS Authentication for configuration steps.

    • KerberosClass: The authentication class used for using Kerberos for Active Directory and Identity Server authentication. See Kerberos Authentication for configuration steps.

    • NMASAuthClass: The authentication class used for Novell Modular Authentication Services (NMAS). It uses fingerprint and other technology to authenticate a user. For information about using the NMAS NESCM method, see Configuring Access Manager for NESCM.

    • NPOrRadiusOrX509Class: The authentication class that allows the creation of a contract from which the user can select an authentication method: name/password, RADIUS, or X.509. For configuration information, see ORed Credential Class.

    • PasswordFetchClass: The authentication class that allows Identity Server to retrieve the user’s password when the user has used a non-password class for authentication. For configuration information, see Section 4.1.10, Password Retrieval.

    • PersistentAuthClass: The authentication class that allows for persistent logins, long authentication sessions, or remember my password functionality. For configuration information, see Section 4.1.6, Persistent Authentication.

    • IDP Select Class: The authentication class that allows the user to authenticate with the desired external IDP and provides an option to remember the user choice. For configuration information, see Configuring IDP Select Class.

    • Other: Used for third-party authentication classes or if you have written your own Java class. For information about how to write your own class, see Access Manager Developer Resources.

    • AliasUserPasswordClass: This class supports authentication of a user against user's alias name. This class uses the alias object of the user object and the password of the corresponding user object to authenticate.

    • Advanced Authentication: The authentication classes that support Advanced Authentication (for example, Email OTP, FIDO U2F). For configuration information, see Section 2.3.9, Configuring Advanced Authentication Server.

      IMPORTANT:To enable CSRF check, perform the steps mentioned in LOGIN CSRF CHECK and add a property AntiCSRFCheck=true to the class. You do not need to add this property to Password Class and TOTP Class.

      NOTE:You cannot enable CSRF check for Advanced Authentication class and Social Authentication class.

  4. Click Next to configure the properties for each class. Click New, then enter a name and value. The names and values are case-sensitive. See Specifying Common Class Properties for the properties that are used by the basic and password classes.

  5. Click Finish.

  6. Continue with Section 4.1.3, Configuring Authentication Methods.

    To use an authentication class, the class must have one or more associated methods.

Specifying Common Class Properties

Both basic and password classes can use Query Property, JASP Property, and MainJSP Property. You can also specify these properties on a method derived from the class.

If you are planning to create multiple methods from the same class, consider the following conditions:

  • If you want the methods to share the same properties, you can save configuration steps by defining the properties on the class.

  • If you want the methods to use different values for the properties such as one method specifying one custom login page and another method specifying a different custom login page, then you must specify the properties on the method.

This section includes the following topics:

Query Property

Typically, Identity Server uses the username to find a user in the user store. You can change this behavior by using the Query property. This property determines the username value for authentication. The default Query string prompts the users for the value of the CN attribute. You can modify this by requesting a different attribute in the LDAP query.

The Query property can be used by the following classes:

  • BasicClass

  • PasswordClass

  • ProtectedBasicClass

  • ProtectedPasswordClass

For example, to query for the user’s UID attribute to use for the username, you would specify the following query:

Property Name: Query

Property Value: (&(objectclass=person)(uid=%Ecom_User_ID%))

The values are case sensitive. The name of the property must be Query with an initial capital. The %Ecom_User_ID% variable is used in the default login.jsp for the username in the four classes that support the Query property. The variable is replaced with the value the user enters for his or her username, and the LDAP query is sent to the user store to see if the user’s attribute value matches the entered value. You can specify any attribute for the Query that is defined in your user store for the object class of person and that is used to identify the user.

The Query you define for the BasicClass and the ProtectedBasicClass needs to use an attribute that your users define as their username. The PasswordClass and the ProtectedPasswordClass do not have this requirement. They also support the JSP property, which allows you to specify a custom login.jsp and have it prompt for other attributes that can be used for login.

For example, you can define the following Query to prompt the users for their email address rather than their username.

Property Name: Query

Property Value: (&(objectclass=person)(email=%EMail Value%))

The %EMail Value% must match the variable in the custom login page that is filled in when the users enter their credentials. The objectclass value must be a valid object class in the LDAP user store. The email attribute must be a valid attribute of the person class.

When you specify such a Query, you must also modify the login page to prompt the user for the correct information. Instead of prompting the user for a username, the login form must prompt the user for an e-mail address. The JSP Property allows you to specify a custom login page. For information about creating a custom login page, see Customizing the Identity Server Login Page.

JSP Property

The JSP property allows you to specify a custom login page. This property can be used with the following classes:

  • PasswordClass

  • ProtectedPasswordClass

The property name is JSP and the property value is the filename of the login page you customized without the .jsp extension of the file. The property value cannot contain nidp in its name.

For example, if you created a custom file named emaillogin.jsp,you would specify the following values. The values are case sensitive. The property name needs to be entered as all capitals.

Property Name: JSP

Property Value: emaillogin

If you use two methods to create a contract, this property must be set to the same value on both or set on only one. When it is set on only one method, the value is applied to both. This property needs to be used with the MainJSP Property. For information about how to create a custom login page, see Customizing the Identity Server Login Page.

MainJSP Property

When the MainJSP property is set to true, it indicates that you want to use the page specified in the JSP property for the login page. When this property is set to false, which is the default value, the nidp.jsp is used for the login page. If you use two methods to create a contract, this property must be set to the same value on both or set on only one. When it is set on only one method, the value is applied to both.

Property Name: MainJSP

Property Value: true

For more information about a custom login page, see Customizing the Identity Server Login Page.

Enabling reCAPTCHA

reCAPTCHA helps you to protect your user login page against spam, malicious registrations, and other forms of attack where bots or malicious software pretend as humans to access your computer. reCAPTCHA can help you secure Access Manager against attacks such as denial-of-service (DoS) and brute-force, which can impact the system performance to a large extent.

reCAPTCHA provides an additional layer of security by requesting users to confirm that they are not a robot. It displays images that users must select based on a matching criteria. If a response succeeds, Access Manager authenticates the user’s authentication credentials. If a response fails, Access Manager does not authenticate the user credentials, and redirects to the login page. Software bots typically cannot scan the images to provide a response.

Access Manager supports only the latest invisible reCAPTCHA. For more information, see Google developer guide for reCAPTCHA.

reCAPTCHA works on both Name/Password – Form and Secure Name/Password – Form authentication.

The following sections provide information about configuring reCAPTCHA:

Prerequisites

Ensure that you meet the following prerequisites before configuring the reCAPTCHA:

  • Active Directory, eDirectory, or both identity sources are configured.

    reCAPTCHA supports Active Directory and eDirectory. It does not support other types of identity sources, such as Microsoft SQL Server or Oracle Database type identity sources that use the JDBC identity source connector.

  • Each identity source is configured with an intrusion detection policy. See Configuring Intrusion Detection for Failed Logins

  • A Google reCAPTCHA account is available. See Setting Up a reCAPTCHA Account.

Configuring Intrusion Detection for Failed Logins

Anyone who attempts to use more than a few unsuccessful passwords while trying to log on to the system might be a malicious user. reCAPTCHA cannot prevent attacks by malicious users who can read the image. It cannot differentiate between malicious users and legitimate users. reCAPTCHA cannot prevent coordinated human DoS attacks.

To prevent brute-force or human attacks that bypass the reCAPTCHA protection, enable the user’s identity source to respond to this type of potential attack by disabling the user account for a preset period of time after a specified number of failed login attempts.

The supported identity sources have the following built-in intrusion detection systems:

Active Directory Account Lockout Policy: Active Directory allows you to specify an account lockout policy for users and global security groups in a domain. Set the policy on the domain group policy object from the domain controller.

To configure the Account Lockout Policy settings:

  1. Log in as an Active Directory administrator user to the Windows Server that hosts Active Directory Domain Services (the domain controller).

  2. Configure the Account Lockout Policy on the group policy object for the domain controller.For more information, see the Account Lockout Policy in Microsoft TechNet Library.

  3. Verify that the Account Lockout Threshold value is higher than the number of failed login attempts you plan to specify for Start reCAPTCHA at in the reCAPTCHA tool.

  4. Repeat these steps for each configured Active Directory identity source.

eDirectory Intruder Lockout Policy: eDirectory allows you to enable intruder detection and specify an Intruder Lockout policy for the container object where your user objects reside.

To configure eDirectory Intruder Detection and Intruder Lockout Policy:

  1. Log in as the eDirectory administrator user to the eDirectory server management console.

  2. Configure Intruder Detection and the Intruder Lockout policy on the container object where your user objects reside.For more information, see Setting Up Intruder Detection for All Users in a Container in the eDirectory 9.0 Administration Guide.

  3. Verify that the Intruder Lockout value is higher than the number of failed login attempts you plan to specify for Start reCAPTCHA at in the reCAPTCHA tool.

  4. Repeat these steps for each configured eDirectory identity source.

NOTE:By default, the intruder detection is disabled when you create a new container object. Perform the following steps in Administration Console to enable the intruder detection:

  1. Click <username> > Manage Directory Objects > Tree > <container name> > (current level) > General > Intruder Detection.

  2. Select Detect intruders.

  3. Select Lock account after detection.

    If you do not select this option, no action is taken when intruder detection is activated.

  4. Click Apply > OK.

After you configure the intrusion detection for the supported identity sources, continue with Setting Up a reCAPTCHA Account.

Setting Up a reCAPTCHA Account

Before configuring reCAPTCHA, you must set up a reCAPTCHA account.

To set up an account, perform the following steps:

  1. Log in to the Google reCAPTCHA website.

  2. Click Get reCAPTCHA > Sign up Now.

  3. Specify a label and the registered domains.

  4. Select Invisible reCAPTCHA as the type of reCAPTCHA.

  5. Click Register.

  6. Make a note of Site Key and Secret Key for future use.

  7. Continue with Configuring reCAPTCHA.

Configuring reCAPTCHA
  1. Click Devices > Identity Server > Servers > Edit > Local > Classes > Name/Password – Form OR Secure Name/Password – Form. Click Properties.

  2. Select Enable reCAPTCHA.

  3. Specify the value that you noted down when setting up your reCAPTCHA account, for the following fields:

    • Site Key

    • Secret Key

    For more information, see Setting Up a reCAPTCHA Account.

  4. Click OK and update Identity Server.

4.1.3 Configuring Authentication Methods

Authentication methods let you associate authentication classes with user stores. You use a particular authentication class to obtain credentials about an entity, and then validate those credentials against a list of user stores.

After the system locates the entity in a particular user store, no further checking occurs, even if the credentials fail to validate the entity. Typically, the entity being authenticated 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. 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.

    You can select from the list of all the user stores you have set up. 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 the User stores list, 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:

    Advanced Authentication Property: Select a property from the list. For more information about each property, see Optional Properties for Authentication Methods.

    Property Name: The name of the property. This value is case-sensitive and specific to an authentication class. The same properties can be set on the method.

    You can use the method properties to override the property settings specified on the authentication class. For example, you might want to use the 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 the available properties for the basic and form classes, see Specifying Common Class Properties.

    The RADIUS classes have the following additional properties that can be set on the method:

    • 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.

    If this method is part of a 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.

    Property Value: The values associated with the Property Name field.

  5. Click Finish.

  6. Continue with Section 4.1.4, Configuring Authentication Contracts.

    To use a method for authenticating a user, each method must have an associated contract.

4.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 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 requires. You can also restrict a contract to be used for local authentication and not with other providers.

  1. 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 Access Gateway.

  3. To create a new contract, click New.

  4. Specify the following details:

    Field

    Description

    Display name

    Specify the name of the authentication contract.

    URI

    Specify 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 space is allowed.

    The following are example of valid values for URI:

    /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 about how to use this type of servlet, 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 the users will be redirected. Use this setting for the following scenarios:

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

    • Forcing a 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, the user may frequently 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 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 this authentication contract to indicate its security level or rank. This setting preserves 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 65535 minutes and must be divisible by 5.

    If you modify the time-out 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 time-outs 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 time-outs, 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 time-out to 5 minutes, an authentication check needs to be done 12 times each hour for each user authenticating with this contract. If the time-out is set to 60 minutes, an authentication check is done only one time each hour for each user. However, for the 5 minute time-out, resources can be freed within 5 minutes of inactivity by the user. For the 60-minute time-out, 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 time-out without user intervention using the Basic header sent from browser to Identity Provider.

    For information about how to use this feature 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.

    For more information about this feature, see Using Activity Realms.

    Satisfiable by a contract of equal or higher level

    Select to allow 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, 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 must be enabled to avoid prompting for authentication in the Target Service Provider.

    Satisfiable by External Provider

    Select to allow 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 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 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 must 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 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.

    NOTE:In SAML 2.0 federation with Access Manager as a service provider, if external identity provider 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 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 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.

    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.

  5. Click Next.

  6. 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

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

  7. Click Finish, then OK.

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

  9. 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].

  2. Click Options > New.

  3. Specify the following details:

    Property

    Description

    AUTHENTICATE WITH EXPIRED PASSWORD

    Select the Property Value as true if you want 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 the Property Value as true if you want to disable showing any other higher level authentication cards, if Satisfiable by a contract of equal or higher level is enabled.

    OTHER

    Specify Property Name and Value if you want to configure any other property for this contract.

  4. 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 are defining the URL for the password service on the Contracts page, the following optional tags can be used in the parameter definitions of the URL. You need to 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 or might not use these, and might 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 behave 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.

For 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 Has 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 the 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 the user is redirected to the password management service URL because of an expired password, the POST data in that redirect contains the 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 when you have 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 has defederated the account, the next time the user 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 the 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 and then click Options > New.

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

  7. Click OK > Apply, and then Update Identity Server.

Using Login Redirect URL Parameters

When you are defining the URL for login redirect URL on the Contracts page, the following optional tags can be used in the parameter definitions of the URL. You need to 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>

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.

For example:

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

NOTE:If you copy this text, ensure to 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 the above three parameters you can also configure other parameters.

Using Activity Realms

Activity realms are designed to be used with an Access Manager system that uses multiple contracts to protect resources that require different activity time-outs. Activity realms allow you to define how activity at one protected resource affects the activity time-out at another protected resource.

An activity realm essentially 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 having activity. 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, suppose you create an activity realm called shared1 and assign it to contract C1 with a time-out of 30 minutes and to contract C2 with a time-out of 15 minutes. Any activity at the resource protected by C1 or C2 marks activity to the shared1 time line. Figure 4-3 illustrates this scenario.

Figure 4-3 Two Contracts Sharing an Activity Realm

In Figure 4-3, 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, you need to 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.

4.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. Configure the following fields as necessary:

    User Store: Specifies the default user store for local authentication. If you selected <Default User Store> when configuring an authentication method, the system 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 the default, ensure that you update 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. For more information, 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 a contract or 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 a 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:

  • You can define a contract for the class whose URI matches the requested class type. When the authentication request is received, Identity Server uses the URI to match the request with a contract.

    When you create such a contract, you state that the contract is security equivalent to the class that is being requested. See Creating a Contract for a Specific Authentication Type.

  • You can 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 contracts meet the requirements of the request. If one or more contracts match the request, the user is presented with the appropriate authentication prompts.

    For configuration 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.

  2. To create a new contract, click New.

  3. 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. 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 the URI.

    The 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 Section 4.1.4, Configuring Authentication Contracts.

  4. Click Next.

  5. Configure an authentication card for the contract.

    For information about these fields, see Configuring Authentication Contracts.

  6. Click Finish > OK.

  7. Update Identity Server.

4.1.6 Persistent Authentication

This authentication class stores user session on the browser after successful login. When the user is prompted for authentication subsequently, this class will reuse the saved authentication instead of prompting the user for credentials. The user will be prompted for credentials again only when the cookie lifetime expires. This authentication class is used only for applications that do not require very high security. You can configure persistent authentication as a standalone class.

Frequent Re-authentication Using Password

This class helps in configuring websites that have low security such as enterprise forums. Frequently typing the password to re-authenticate may be vulnerable and cause security issues. With PersistentAuthClass configuration, you do not require to re-authenticate using the password frequently. For sites that you use a low-grade identity, for example, enterprise forums or some websites that restrain your preferences, having to re-authenticate every few-hours is annoying. Some websites offer the remember my password feature that will not ask the user to re-authenticate if you select this option. This class provides the remember my password functionality, so that the user does not need to frequently re-authenticate.

PersistentAuthClass Properties

You can set the following properties in the class properties tab:

  • CryptoKey: This key is used to encrypt the user's information in the cookie. If this value is long and random, the user information will be secure. The value must be at least ten characters. The certificate private key will be used if you do not set this value. The certificate private key will be used if you do not set this value. If you change or update the certificate, the user is re-authenticated.

  • CookieSuffix: The cookie name is derived using this suffix. PA_ is added as a prefix to the cookie name. By default, the cookie name is PA_PERSISTENT_AUTH. For example, if you configure CookieSuffix as PER_AUTH, Identity Server sends the cookie with the PA_PER_AUTH name at the browser.

  • MaxAgeSeconds: This property decides the cookie lifetime. The default value is 86400 seconds (1 day). The maximum value is 4294967295 seconds.

  • ParamName: The name of the HTTP parameter to enable this feature. The default value of the parameter is EnableCookieAuth. If you want to modify the default value of parameter name, for example to TestCookieName, perform the following steps:

    1. Log in to Identity Server.

    2. Go to /opt/novell/nids/lib/webapp/jsp.

    3. Open the login.jsp file using an editor.

    4. Search for the EnableCookieAuth parameter name and specify the new name as TestCookieName.

    5. Select Remember Me.

    6. Restart Identity Server.

      This value is used by Identity Server to identify if the user has selected Remember Me on the login page.

Customizing Login Page For Persistent Authentication

To enable the Remember Me option on a custom login page, use the following custom code:

<td align=left>
<input type="checkbox" name="EnableCookieAuth" value="true" /> <label> Remember Me </label>
</td>
</tr>
<tr></tr>
<tr> <td> <span class="instructions">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(Do not check this box if you are using public computer.)</span> </td></tr>

NOTE:

Configuring the Persistent Authenticator Class

  1. Log in to Administration Console.

  2. Click Devices > Identity Servers > Edit > Local > Classes.

  3. Click New, then specify a Display name. For example, PersistentAuth.

  4. Select PersistentAuthClass from the Java Class list.

  5. Click New.

  6. (Optional) In the Add property window, specify the following values:

  7. Click OK > Finish.

  8. Continue with creating a contract and method for this class.

    For configuration information, see Section 4.1.3, Configuring Authentication Methods and Section 4.1.4, Configuring Authentication Contracts.

Logging Out of the Persistent Sessions

When a user performs an explicit logout, Identity Server clears the persistent authentication cookie at the browser if the logout request goes through the browser.

If SOAP communication is used between the service provider and Identity Server, then Identity Server does not clear the cookie automatically. The cookie can only be cleared by sending a request to a page on the server that issued it. If the page is available on Identity Server, the clearCookieAuth.jsp file clears the page. You must customize the service provider’s logout page to run Identity Server’s clearCookieAuth.jsp page.

The clearCookieAuth.jsp file clears it. The URL for this page is https://idpserver.example.com/nidp/clearCookieAuth.jsp. Any request to that URL clears the authentication cookie.

With this class in use, the user will be unable to logout of the system because re-accessing any protected page will simply re-authenticate the user using the user information stored in the browser store. There are at least two ways to invalidate an outstanding browser stored authentication cookie. The first is to change the user’s password and second is to clear the stored cookie from the browser. Only way to invalidate the cookie is to change the encryption key used. The cookie that is created can only be cleared by a request from the server which created it.

The following configurations are specific to the Novell service provider. If the users uses third party service provider, then the user must customize the logout pages.

In a federation scenario, add the following to the logoutSuccess.jsp file at /opt/novell/nam/idp/webapps/nidp/jsp/ of the service provider. You can redirect the logout page to this page, or have an <iframe> that references the page. You may also customize the /opt/novell/nam/mag/webapps/nesp/jsplogoutSuccess.jsp file to provide login links or instructions to your user.

<tr>
   <td> <iframe src="https://idp.labs.com:8443/nidp/jsp/clearCookieAuth.jsp" width="0" height="0"> </td>
</tr>

where idp.labs.com is the URL of Identity Server.

Limitations of Using Persistent Authentication Class

  • User is authenticated even if the password is changed.

  • If the user is already logged in with Remember Me option enabled, you cannot stop the session until the cookie expires.

4.1.7 Mutual SSL (X.509) Authentication

In mutual authentication, a trusted source issues an X.509 certificate and the certificate is used to identify the user. To ensure the validity of the certificates, Access Manager supports both Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) methods of verification.

Configuring X.509 Authentication

To configure X.509 authentication, you need to create an authentication class, then configure the validation and attribute mapping options.

  1. Log in to Administration Console.

  2. Import the trusted root certificate or certificate chain of the certificate authority (CA) into Identity Server trusted root store.

    For more information, see Importing Public Key Certificates (Trusted Roots).

    Identity Server must trust the CA that created the user certificates.

  3. To create the X.509 authentication class, click Devices > Identity Servers > Edit > Local > Classes > New.

  4. Specify a display name, then select X509Class from the list.

  5. Click Next.

  6. Configure the following validation options:

    Option

    Description

    Validations

    Select the validation type. Trust validation occurs if the certificate chain is verified in NIDP Trust Store. In addition to usual certificate validations, Identity Server supports certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP) validations for each authentication request.

    Access Manager caches CRLs. The status of a newly revoked certificate is not picked up until the next cache refresh. For higher security requirements, use OCSP validation with CRL validation. You can select None, CRL, OCSP, OCSP-CRL, or CRL-OCSP validation. In a production environment, select OCSP-CRL or CRL-OCSP validation for highest security. The default setting is to check OCSP first, then CRL.

    CRL Validation

    Checks the CRL. If you enable CRL validations, the CRL distribution point extension is read out of the user’s X.509 certificate. The CRL distribution point contains the URL where the complete CRL can be found, as published by the certificate authority. The system checks the CRL itself and then checks to see if the user certificate is on the revoked list. The system can get the CRL over HTTP and LDAP. If you are not expecting the distribution point in user certificates, you can specify a value in the LDAP URL option to get the CRL.

    Access Manager supports two schemes for a URL: http:// and ldap://.

    OCSP Validation

    If OCSP validation is enabled, the Authority Info Access point (AIA) is read out of the user certificate, which contains the URL for the OCSP responder. A signed OCSP request for the user certificate is sent to OCSP responder. A signed OCSP response is received from the responder that has the revoked status for the user certificate. Alternately, if you are not expecting an AIA in a user certificate, you can specify a value in the OCSP responder URL field. The value you enter here overrides any OCSP responder URLs in a certificate.

    Access Manager supports two schemes for a URL: http:// and ldap://.

    Disable Root CA Revocation Check

    Select to disable checking if a certificate authority has been revoked. This option checks CRL and OCSP for the trusted root certificate in the chain. You can enable or disable this option for X.509 user authentication performance.

    If you do not select this option, checks performed by Identity Server depends on the certificates that have been added to the Identity Server trust store. If the root certificate and the intermediate certificates in the chain are in the trust store, Identity Server only validates the client (leaf) certificate. If the trust store only contains the root certificate, the browser sends the intermediate and leaf certificates, which are then validated by Identity Server.

  7. Configure the trust stores.

    NIDP Trust Store: This trust store must contain the trusted root certificate of the certificate authorities that signed your user certificates. Click this link to add certificates to the trust store.

    OCSP Trust Store: This trust store must contain the signing certificate of the OCSP servers you want to trust. Click this link to add certificates to the trust store. You must add the signing certificate, not the trusted root certificate, for this feature to work.

  8. Under Trusted Roots for Validation, click New and add the trusted roots that you want to use in the authentication. Access Manager uses these trusted roots to validate the user’s identity.

    If you do not specify any trusted root, Access Manager validates the user’s certificate against the default Access Manager trusted root. For more information, see Restricting the X.509 Authentication to a Specific Certificate Authority.

  9. Select Force browser restart on logout.

    Some browsers, such as Internet Explorer, keep the SSL session active until the user closes the browser. When the user logs in with the certificate on a smart card, removes the card, and logs out without closing the browser, the SSL session remains active. Another user can use the existing session if the machine is accessible. Selecting this options ensures that the session gets closed after a user logs out.

  10. Select Read certificate from http header and specify the header name. This configuration is required when Identity Server is configured as a public resource behind a reverse proxy other than an Access Manager Access Gateway reverse proxy. If the proxy is configured to send the user certificate to Identity Server as part of HTTP header in the PEM encoded data, Identity Server can read this header value and completes X.509 authentication.

    For example, if Identity Server is behind Apache, add the following advanced Apache configuration with the rewrite module to send the user certificate to Identity Server through a custom header called SSL-Client-Cert.

    • SSLVerifyClient optional_no_ca

    • SSLVerifyDepth 10

    • RequestHeader set SSL-Client-Cert "%{SSL_CLIENT_CERT}s“

  11. Click Next.

  12. Continue with Configuring Attribute Mappings.

Configuring Attribute Mappings

  1. Step 3 of the wizard or click Devices > Identity Servers > Edit > Local > Classes > [Name of X.509 class] > Properties > Attributes.

  2. Configure attribute mappings.

    Option

    Description

    Show certificate errors

    Select to displays an error page when a certificate error occurs. This option is not selected by default.

    Auto Provision X509

    Select to enables automatic provisioning of users for X.509 authentication.

    This option enhances the security of X.509 authentication when using a less secure way of authentication, such as username/password. Additional security measures include manual intervention to activate X.509 authentication by adding an additional attribute that is checked during authentication. For example, when a user authenticates with an X.509 certificate, Access Manager looks up for a matching SASallowableSubjectNames with the name of the user certificate. If no match is found and Auto Provision X509 is enabled, an error page is displayed that prompts the user to specify additional credentials such as a username/password or to start an optional Identity Manager workflow. If the authentication is successful, the user’s SASallowableSubjectNames attribute is filled with the name of the user certificate.

    When Auto Provision X509 is enabled and the attribute that is used for subject name mapping is changed from the default sasAllowableSubjectNames, ensure that the LDAP attribute that is used can store string values as long as the longest client certificate subject name. For example, if you use the LDAP attribute title (which has an upper bound of 64 characters), the Auto Provision X509 fails the provisioning part of the authentication if the client certificate subject name is longer than 64 characters. The authentication works if a valid name and password is given, but provisioning fails.

    Attributes

    Select attributes from Available attributes used for matching. If multiple attributes are specified, the evaluation of these attributes must resolve to only one user in the user store.

    Access Manager first does a DN lookup for subject name or directory name mapping. If this fails, the rest of the mappings are looked up in a single LDAP query.

    Available attributes

    The list of available X.509 attributes. To use an attribute, select it and move it to Attributes.

    • Directory name: Searches for the directory address in the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

    • Email: Searches for the email attribute in the client certificate and tries to match it with a value in the LDAP mail attribute.

    • Serial number and issuer name: Lets you match a user’s certificate by using the serial number and issuer name. The issuer name and the serial number must be put into the same LDAP attribute of the user, and the name of this attribute must be listed in the Attribute Mappings section.

      When using a Case Ignore String attribute, both the issuer name and the serial number must be in the same attribute separated by a dollar sign ($) character. The issuer name must precede the $ character, with the serial number following the $ character. Do not use any spaces preceding or following the $ character. For example: O=CURLY, OU=Organization CA$21C0562C5C4

      The issuer name can be from root to leaf or from leaf to root. The issuer name must be comma-delimited with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

      The serial number cannot begin with a zero (0) or with a hexadecimal notation (0x). If the serial number is 0x0BAC05, the value of the serial number in the attribute must be BAC05. The certificate number is displayed in Internet Explorer with a space after every fourth digit. However, you must enter the certificate number without using spaces.

      The LDAP attribute can be any Case Ignore List or Case Ignore String attribute of the user. If you are configuring your own attribute, ensure that the attribute is added to the Person class. When using a Case Ignore List attribute, both the issuer name and the serial number must be on the same list. The issuer name needs to be the first item on the list, with the serial number being the second and last item on the list.

    • Subject name: Searches for the Subject name of the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches the Subject name of the client certificate. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

    Attribute Mappings

    This option allows you to specify how Identity Server maps the certificate to a user in the user store. Subject name is the default map.

    When an attribute is moved to Attributes, you can modify the mapping name here. The mapped name must match an attribute in your LDAP user store.

    You can also configure regular expression for attributes to use a partial value of the X.509 certificate attribute for searching users. See Regular Expression for Extracting the Partial String from DN.

  3. Click Finish.

  4. Create a method for this class.

    During step-up authentication with X509 method as primary method, if a user specifies a different username while authentication for secondary method, an error is displayed. While configuring a method, configure the following property to enable customizing this error message.

    Property: PRINCIPAL_MISMATCH_ERR

    Value: provide string to display on user principal mismatch

    If this property is not configured, the default intruder detection error is displayed to users.

    For instructions, see Section 4.1.3, Configuring Authentication Methods.

  5. Create a contract for the method:

    For instructions, see Section 4.1.4, Configuring Authentication Contracts.

    If you want the user’s credentials available for Identity Injection policies, add the password fetch method as a second method to the contract. See Password Retrieval.

  6. Update Identity Server.

Restricting the X.509 Authentication to a Specific Certificate Authority

In an ideal mutual authentication scenario, a user gets an X.509 certificate from a trusted CA. The CA is imported to the Access Manager trust store and Access Manager uses the same CA for authenticating this user.

Access Manager trust store contains many other trusted certificate authorities. If the user submits a certificate issued by a different CA that is trusted by Access Manager, the authentication succeeds. In some scenarios, this behavior is not suitable, such as when smart cards and X.509 authentications are used in an enterprise. You can restrict this behavior and configure to allow the X.509 authentication only for configured CA. After enabling the restriction, the mutual authentication succeeds only when a user submits an X.509 user certificate issued by the specified CA. This restriction does not restrict the certificates available on the client side. This restriction is only applicable during processing or validating the certificates.

For example, an organization has two departments: HR and Finance. Each department issues smart cards to its respective employees. In Access Manager, contracts are configured for both departments as follows:

Department

Contract

CA

HR

X509_HR

CA_HR

Finance

X509_Finance

CA_ Finance

Employees of the HR department use the certificate signed by CA_ HR and employees of the Finance department use the certificate signed by CA_ Finance. Both certificates are imported into the trust store.

If not specified, Access Manager does not validate certificates with any specific CA. In this case, employees can authenticate with any certificate that is imported to the trust store irrespective of the contracts they use. As a result, employees of the HR department can use the certificate signed by CA_ Finance and employees of the Finance department can use the certificate signed by CA_ HR for authentication.

When you specify the CA, Access Manager validates the certificates with the configured CA. Therefore, you can restrict employees of the HR department to use the X509_ HR contract and employees of the Finance department to use the X509_ Finance contract. Access Manager validates the certificate with the CA configured in the Access Manager authentication method property.

For information about configuring X.509 authentication, see Configuring X.509 Authentication.

Regular Expression for Extracting the Partial String from DN

By default, Access Manager uses the complete string of the X.509 certificate attribute to identify a user in the userstore. When the X.509 subject name contains a long DN or string, you can configure regular expression (regex) to extract the partial value. You can configure regex for the following attributes of the certificate:

  • Subject name
  • Directory name
  • Email
  • Serial number and issuer name

If the subject of the certificate is fully qualified DN, Access Manager can use the CN value or ignore it while searching for a user. You can also configure regex for each attribute that is available with the X.509 certificate configuration.

You can configure regex while creating an X.509 class. See Attribute Mappings.

For example, the X.509 subject is EMAILADDRESS=martial@novell.com, CN=martial, OU=NTS, O=MF, L=Malahide, ST=Dublin

To retrieve the martial CN value, you can use regex (?<=CN=)([^,]+).

The expression CN=(.*?) matches the common name field. So, if the subject name in the certificate is "CN=martial, OU=...", this will give a username “martial". The matches are case-sensitive.

"EMAILADDRESS =(.*?)," will match "EMAILADDRESS=martial@novell.com,CN=... “ and will give username “martial@novell.com”.

OU=(.*?)(?:,|$) will match “EMAILADRESS=martial@novell.com,CN=..,OU=NTS...” and match value to “NTS”.

For more information about regex, see Regular Expression.info and for editing and testing a regex, you can try Online Regex Tester or Regexr.

Setting Up Mutual SSL Authentication

SSL provides the following security services from the client to the server:

  • Authentication and non-repudiation of the server, using digital signatures

  • Data confidentiality through the use of encryption

  • Data integrity through the use of authentication codes

Mutual SSL provides the same things from the server to the client as SSL. It provides authentication and non-repudiation of the client, using digital signatures.

  1. Set up Access Manager certificates for security, and import them into the Access Manager system. (See Section 15.0, Creating Certificates.)

  2. Create an X.509 authentication class. (See Mutual SSL (X.509) Authentication.)

  3. Create an authentication method using this class. (See Configuring Authentication Methods.)

  4. Create an authentication contract using the X.509 method. (See Configuring Authentication Contracts.)

  5. Update Identity Server cluster configuration. (See Updating Identity Server Configuration.)

  6. Update any associated Access Gateways to read the new authentication contract.

  7. Assign the contract to protect resources.

    See Section 2.6.5, Configuring Protected Resources.

  8. Update Access Gateway.

Customizing Certificate Errors

When certificate validation fails, the browser displays a standard Page expired error. If you want Identity Server to display an Access Manager error instead of the usual error messages provided by the browser, edit the /opt/novell/nam/idp/conf/server.xml by using the following steps:

  1. Search for the clientAuth attribute in the server.xml file.

  2. Modify the value of the clientAuth attribute from the default value of false to want.

    NOTE:If you use clientAuth=want in a connector, ensure that the connector contains protocol="org.apache.coyote.http11.Http11Protocol".

  3. Save the file and restart Identity Server by using the rcnovell-idp restart command.

    This setting ensures that the certificate is exchanged between the client and the server.

  4. Export the certificate of the user and the server from Administration Console by using the Security > Certificates option.

    To avoid the untrusted certificate messages in browsers, import the trusted root certificate of the CA into your browsers. See Resolving Certificate Import Issues.

Configuring X.509 Authentication to Display the Access Manager Error Message

You can configure the X.509 authentication class to avoid the browser provided message and display the Access Manager error message. This error message is displayed when the SSL mutual handshake fails because of non-availability of the client certificate. To display the Access Manager specific error message during X.509 authentication, you must configure a dual connector setup in Identity Server.

Configuring a Dual Connector Setup in a Single-Node Identity Server Environment

IMPORTANT:Add the DNS name of the second connector in the browser exception list or proxy settings.

You can specify the port and URL name as per your environment. The URL name and port number specified in the following procedure is an example.

Prerequisite:You must have a parent domain and a sub-domain.

For example, you must have the following domains:

Parent Domain: https://240onbox.nam.example.com:8443/nidp/

Sub-Domain: https://onbox.nam.example.com:8443/

To create a sub-domain, create a secondary Ethernet in Identity Server with the IP address that you want to create the sub-domain.

Perform the following steps to configure a dual connector setup:

  1. In Identity Server, navigate to the /opt/novell/nam/idp/conf directory.

    1. Open the server.xml file.

    2. Search the <Connector NIDP_Name="connector" string and create a copy of the existing connector in the same file.

    3. In the new connector, change the port number to 8448.

    4. Change the clientAuth="false" string to clientAuth="want".

    5. Add protocol="org.apache.coyote.http11.Http11Protocol".

    6. Save the server.xml file.

  2. Navigate to the /opt/novell/nids/lib/webapp/META-INF/ directory and open the context.xml file.

  3. Change Tomcat context.xml to set a same cookie for sub-domains. Ensure that the path is set to "/" as follows:

    <?xml version="1.0" encoding="UTF-8"?> <Context sessionCookiePath="/" sessionCookieDomain=".nam.example.com"> <!-- Disable session persistence across Tomcat restarts --> <Manager pathname="" saveOnRestart="false"/> </Context>

  4. Uncomment the following string in the context.xml file:

    <CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />

  5. Change session proxying for setting this cookie.

    1. Navigate to Devices > Identity Servers > Edit > Options.

    2. Click New and specify the following details:

      Property Name: CLUSTER COOKIE DOMAIN

      Property Value: nam.example.com

      Property Name: CLUSTER COOKIE PATH

      Property Value: /nidp

      NOTE:Before you proceed to the next step, ensure that you have configured the X.509 class, method, and contract. For information, see Mutual SSL (X.509) Authentication.

  6. Navigate to Devices > Identity Servers > Edit > Options.

  7. Select the X.509 authentication method and click New under Properties.

    Specify the following details:

    Property Name: CONNECTOR_HOST

    Property Value: https://onbox.nam.example.com:8448

    NOTE:Do not add a / after the port number.

    For X.509Class-based redirection, this property will redirect X.509 to the new connector. The DNS named onbox is a sub-domain as indicated in the prerequisite.

    Use a wildcard name for the identity server certificate. For example, *.nam.example.com.

  8. Restart Tomcat by using the following commands:

    • Linux: /etc/init.d/novell-idp restart

    • Windows:

      • net stop Tomcat8

      • net start Tomcat8

Verify the configuration as follows:

Access the Identity Server URL in a browser that does not have the client certificate. Access the X.509 authentication card and verify the behavior. It must redirect to the connector page and redirect to the original page with an Access Manager error message or error code.

Configuring a Dual Connector Setup in a Multi-Node Identity Server Environment

Let us consider that your setup details are as follows:

  • Base URL of the Identity Server cluster: https://abc.idp.com:8443/nidp

  • Value of the common name of the Certificate, cn=*.idp.com

  • Details of the Identity Server nodes:

    Identity Server

    IP Address

    Host

    Node 1

    1.1.1.10

    abc

    Node 2

    1.1.1.11

    auth

Perform the following steps to configure a dual connector setup:

NOTE:The second Identity Sever node acts as a connector host.

  1. Create an X.509 authentication class and method. See Configuring X.509 Authentication and Configuring Attribute Mappings.

  2. Navigate to Devices > Identity Servers > Edit > Local > Methods.

  3. Select the X.509 authentication method and click New under Properties.

    Specify the following details:

    Property Name: CONNECTOR_HOST

    Property Value: https://auth.idp.com:8448

    NOTE:Do not add a / after the port number.

  4. Navigate to Devices > Identity Servers > Edit > Options.

  5. Click New and specify the following details:

    Property Name: CLUSTER COOKIE DOMAIN

    Property Value: .idp.com

    Property Name: CLUSTER COOKIE PATH

    Property Value: /nidp

  6. (Identity Server Node 1 and Node 2) Back up server.xml and context.xml files located at the following paths:

    server.xml: /opt/novell/nam/idp/conf

    context.xml: /opt/novell/nids/lib/webapp/META-INF

  7. In the Identity Server Node 1, navigate to the /opt/novell/nam/idp/conf directory.

    1. Open the server.xml file.

    2. Search the <Connector NIDP_Name="connector" string and create a copy of the existing connector in the same file.

    3. In the new connector, change the port number to 8448.

      NOTE:Ensure that clientAuth="false".

    4. Save the server.xml file.

  8. In the Identity Server Node 2, navigate to the /opt/novell/nam/idp/conf directory.

    1. Open the server.xml file.

    2. Search the <Connector NIDP_Name="connector" string and create a copy of the existing connector in the same file.

    3. In the new connector, change the port number to 8448.

    4. Change the clientAuth="false" string to clientAuth="want".

    5. Add protocol="org.apache.coyote.http11.Http11Protocol".

    6. Save the server.xml file.

  9. (Identity Server Node 1 and Node 2) Navigate to the /opt/novell/nids/lib/webapp/META-INF directory and open the context.xml file.

  10. Ensure that the following strings are available:

    <Context sessionCookiePath="/" sessionCookieDomain=".idp.com"> 
        <Manager pathname="" saveOnRestart="false"/> 
        <CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
    </Context>
  11. Save the files and restart both the Identity Server nodes.

    NOTE:Check the log files and ensure that there are no errors.

  12. Create a user certificate. See Section 15.0, Creating Certificates.

  13. Import the certificate to the browser.

  14. Create a contract for the method. See Configuring Authentication Contracts.

Verifying the Dual Connector Setup

To verify that the dual connector setup configuration is successful, execute the X.509 dual connector contract as an end user and ensure that the CONNECTOR_HOST URL is visible in the browser URL and in the Identity Server logs.

  1. At the User Portal, select the X.509 dual connector contract.

  2. Select the user certificate when prompted.

A successful login to the User Portal verifies that the dual connector setup configuration is complete.

4.1.8 ORed Credential Class

Access Manager includes a class that can be configured to accept any combination of name/password, X.509, or RADIUS credentials. When this class executes as part of a contract, users can select and enter their preferred type of credential.

For example, if a name/password credential is ORed with an X.509 credential, the user can select to use a certificate or to enter a name and password. As an administrator, you have decided that both credentials are equally secure for the protected resource the contract is protecting.

To create an ORed credential class:

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

  2. Click New, then fill in the following fields:

    Display name: Specify a name for the class.

    Java class: Select NPOrRadiusOrX509Class.

  3. Click Next, then select the types of classes you want to OR. You must select at least one of the following:

    Use Name/Password: Select this option if you want the PasswordClass to be one of the authentication options available to the user.

    Use Radius: Select this option if you want the RadiusClass to be one of the authentication options available to the user.

    Use X509: Select this option if you want the X509Class to be one of the authentication options available to the user.

  4. (Conditional) If you want to use the protected version of the PasswordClass or RadiusClass, select the Enforce use of HTTPS option.

  5. (Conditional) If you selected the Use Name/Password option, configure the properties:

    1. In the Name/Password Properties section, click New.

    2. Specify a property name and property value.

      For information about the properties that the PasswordClass and the ProtectedPasswordClass support, see Specifying Common Class Properties.

    3. Click OK.

    4. Repeat Step 5.a through Step 5.c to add more than one property.

  6. Click Next.

  7. (Conditional) If you selected the Use Radius option, configure the Radius properties.

    For information about the configuration options, see RADIUS Authentication.

  8. (Conditional) If you selected the Use X509 option, configure how the certificate is validated.

    For information about the configuration options, see Mutual SSL (X.509) Authentication.

  9. Click Next.

  10. (Conditional) If you selected the Use X509 option, configure the attribute mappings.

    For information about the configuration options, see Mutual SSL (X.509) Authentication.

  11. Click Next.

  12. Click Finish.

  13. Continue with creating a method and a contract for this class.

    For configuration information, see Section 4.1.3, Configuring Authentication Methods and Section 4.1.4, Configuring Authentication Contracts.

    The Radius class prompts the user for a token instead of a password. The user can use the drop-down menu to select between the password and the token. If the user selects to send a certificate, the username and password/token options become unavailable.

4.1.9 OpenID Authentication

OpenID is an open, decentralized method for identifying users which allows users to use the same digital identity for logging in to multiple services. You can configure Identity Server to trust the provider or providers of OpenIDs by configuring the OpenID class. You then configure a method and contract and assign a protected resources to use the contract for authentication. When the users supply the OpenID, they are granted access if Identity Server has been configured to trust the provider of the OpenID server.

NOTE:Access Manager supports OpenID1.1.

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

  2. Click New, then fill in the following fields:

    Display name: Specify a name for the class.

    Java class: Select OpenIdClass.

  3. Click Next, then configure the following properties:

    Open ID Provider Substrings: Specify at least one URL substring of an OpenID provider. The OpenID URL that user enters during the login process must contain one of the strings as a subset of the OpenID URL. For example, if user enters https://user123.myopenid.com, this field needs to contain one of the following strings:

    myopenid.com
    .myopenid.com

    To specify multiple URLs, separate them with a semicolon (;)

    Identity the OpenID user locally: After the user authenticates at the OpenID provider, Access Manager can associate a username from the user store with the OpenID user. With this association, Access Manager can use the policies defined for the username to enforce access to protected resources.

    • When this option is not selected, the OpenID user is not mapped to a local user. The username of the authenticated user remains as the OpenID URL. For example, if the user enters http://user123.myopenid.com for the URL, http://user123.myopenid.com becomes the username.

    • When this option is selected, an attempt is made to map the OpenID user with a username in the user store. You can do this manually by storing the user’s OpenID in the attribute specified in the LDAP Attribute Name option. You can also have Identity Server add the OpenID value to the attribute by selecting the Auto Provision LDAP Attribute option.

    LDAP Attribute Name: Specify the name of the attribute that contains the identification information for the users. For OpenID authentication, this attribute must contain the OpenID for the user.

    Auto Provision LDAP Attribute: Select this option when you want the user to provide additional information for identification for the first authentication, such as a username and password. Identity Server uses this information to identify the user, then writes the user’s OpenID value to the attribute specified in the LDAP Attribute Name option. On subsequent logins, Identity Server can identify the user by using the specified attribute and the user is not prompted for additional information.

  4. Click Finish.

  5. Create a method for this class.

    For instructions, see Section 4.1.3, Configuring Authentication Methods.

  6. Create a contract for the method:

    For instructions, see Section 4.1.4, Configuring Authentication Contracts.

    If you want the user’s credentials available for Identity Injection policies, add the password fetch method as a second method to the contract. For more information about this class and method, see Section 4.1.10, Password Retrieval.

  7. Update Identity Server.

4.1.10 Password Retrieval

If you have configured contracts that do not use a username and password for the credentials and you want to configure single sign-on to protected resources that require a user’s name and password, you can use the PasswordFetchClass to retrieve the user’s name and password.

You need to create the class, then create a method from the class. Assign this method as the second method to the authentication contract that does not prompt for the username and password. When Identity Server executes the contract, the PasswordFetchClass retrieves the username and password and stores these with the LDAP credentials, which makes them available for Identity Injection and Form Fill policies.

For example, your contract is using Kerberos or X.509 certificate authentication where the password is not available. Use the PasswordFetchClass to retrieve the username and password.

IMPORTANT:The PasswordFetchClass works only with eDirectory user stores.

Perform the following steps:

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

  2. Click New, specify a name for the class, and then select PasswordFetchClass in Java class.

    The Java class path is configured automatically.

  3. Click Next, then configure the following general properties:

    Ignore password retrieval failure: Select this option if you want users to continue with their sessions when Identity Server cannot retrieve their passwords. If this option is not selected, users are denied access when their passwords cannot be retrieved.

    Retain Previous Principal: Select this option to retain the principal obtained from the previous authentication method. If you do not select this option, then the principal will be used from the method associated with this class.

    Password to be retrieved: If your users have been configured to use a universal password, select Universal Password. Otherwise, select Simple Password.

    NOTE:

    • Set the Universal Password Retrieval options in the configuration of the Universal Password policy, so that the policy allows the password to be retrieved from the user store.

    • User must reset the password after configuring the password policy for universal password.

    For more information about unable to retrieve universal password from eDirectory by using PasswordFetchClass issue, see TID 7007114.

    The user object must be looked up and found in an eDirectory user store for retrieval to succeed. This is done by matching the currently authenticated user by using the CN attribute. If your CN does not match in both of your directories (common when using Active Directory and eDirectory), then use the DN of the user to locate the matching user object. When NetIQ Identity Manager is used between Active Directory and eDirectory, you will find the Active Directory DN value populated in the DirXML-ADContext attribute, which can be used for lookup or matching. If no attribute has the DN value populated, then use the Auto Provision feature.

  4. Configure the following userstore lookup settings:

    Based on the CN of the user object: CN of users are mapped between two different user stores. CN is mapped with for retrieving the password from the user store. For example, Active Directory CN is mapped with eDirectory CN for retrieving the password from the eDirectory user store.

    Based on the Attribute value of the user object: The user names are detected and handled in the LDAP attribute or DN of users of the Active Directory are mapped with LDAP attribute of the eDirectory. If you select this option, then specify the attribute value in attribute details of the Attribute name of DN and select Auto Provision if required.

    Attribute Name of the DN: Specify the attribute name of DN.

    This attribute must contain CN of user whose password you want to obtain. For example, if you are trying to obtain a password from eDirectory for a user with cn=a,dc=b, then you need to specify name of the attribute, which value is cn=a,dc=b.The passwordfetchclass tries fetching the password from the current user store based on the value of the LDAP attribute specified, which are mapped to user's DN of in Active Directory.

    Auto Provision: If you select this option, the passwordfetchclass tries fetching the password from LDAP attribute specified which has the value of the DN users of Active Directory and retrieves the password, else it prompts to log in to eDirectory. If the login is successful, then the LDAP attribute value gets populated with the DN user of Active Directory. When the user is logged next time, the same value is used.

  5. Click OK.

  6. Create a method for this class.

    For instructions, see Section 4.1.3, Configuring Authentication Methods.

  7. Assign the password fetch method as the second method for a contract that is using one of the following methods:

    NOTE:You can use PasswordFetchClass as the second method of authentication for any of the protocols supported by Identity Server.

  8. Click Apply and update Identity Server.

4.1.11 Configuring Access Manager for NESCM

To use a smart card with Access Manager, you need to configure Access Manager to use the eDirectory server where you have installed the Novell Enhanced Smart Card Login Method for NMAS (NESCM). You then need to create a contract that knows how to prompt the user for the smart card credentials. The last task is to assign this contract to the protected resources that you want protected with a smart card. The following sections describe the prerequisites and the tasks:

Prerequisites

Creating a User Store

Identity Server must be configured to use the eDirectory replica where you have installed the NESCM server method.

  • If you have already configured Identity Server to use this replica, skip this section and continue with Creating a Contract for the Smart Card.

  • If your Identity Server is using a different user store, you need to configure Identity Server.

To configure Identity Server for the eDirectory replica that has the NESCM method:

  1. Click Devices > Identity Servers > Edit > Local> User Stores > New.

  2. On the Create User Store page, fill the following fields:

    Name: A display name for the eDirectory replica (for example, nescm_replica).

    Admin Name: The distinguished name of the admin user of the directory. Administrator-level rights are required for setting up a user store.

    Admin Password and Confirm Password: The password for the admin user and the confirmation for the password.

    NOTE:If the admin account's password needs to be changed in the LDAP directory due to some issue, then change the admin password in the Create User Store page accordingly and apply the change. Else, this admin account of the user store will get locked.

    Directory Type: Select eDirectory.

  3. In the Server replica section, click New, and fill the following fields:

    Name: The display name for the LDAP directory server (for example, nescm_server).

    IP Address: The IP address of the LDAP directory server. The port is set automatically to the standard LDAP ports.

  4. Click Use secure LDAP connections. You must enable SSL between the user store and Identity Server. The port changes to 636, which is the secure LDAP port.

  5. Click Auto import trusted root.

  6. Click OK to confirm the import.

  7. Select the Root CA Certificate to trust any certificate signed by that certificate authority.

  8. Specify an alias, then click OK.

    An alias is a name you use to identify the certificate used by Access Manager.

  9. Click Close, then click OK.

  10. Under Server Replicas, verify the Validation Status.

    The system displays a green check mark if the connection is valid.

  11. Set up a search context.

  12. Click Finish to save the information.

  13. Continue with Creating a Contract for the Smart Card.

Creating a Contract for the Smart Card

The following sections describe the tasks required to create a contract for the smart card:

Creating an NMAS Class for NESCM

When you create a class, you can specify values for properties. In the following steps, you specify a property value that determines the sequence of login prompts that the user receives when authenticating with a smart card.

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

  2. Specify a display name for the class (for example, Class-NMAS-NESCM).

  3. For the Java class, select NMASAuthClass from the selection list.

  4. Click Next.

  5. On the Specify Properties page, click New.

  6. Specify the following values for the property:

    Property Name: Specify NMAS_LOGIN_SEQUENCE

    Property Value: Specify Enhanced Smart Card

    The Property Value matches the method name as displayed in NMAS task > NMAS Login Methods.

  7. Click OK, then click Finish.

  8. Continue with Creating a Method to Use the NMAS Class.

Creating a Method to Use the NMAS Class

While creating a method, you can specify properties that are applied only to this method and not to the entire class. For a smart card method, you need to ensure that the user stores specified for the method have NESCM installed.

  1. On the Local page for Identity Server, click Methods > New.

  2. Specify a Display name (for example, Method-NMAS-NESCM).

  3. From the Class selection list, select the class created in Creating an NMAS Class for NESCM.

  4. In the Available user stores list, select the user store created in Creating a User Store, then click the left-arrow to move this user store into the User stores list.

    Leave other settings on this page unchanged.

  5. Click Finish.

  6. Continue with Creating an Authentication Contract to Use the Method.

Creating an Authentication Contract to Use the Method

Contracts are the element you can assign to a protect a resource.

  1. On the Local page for Identity Server, click Contracts > New.

  2. Specify a Display name (for example, Contract-NMAS-NESCM-UserStore1).

  3. Enter a URI (for example, nescm/test/uri).

    The URI is used to identify this contract for external providers and is a unique path value that you create.

  4. In Available methods, select the method created in Creating a Method to Use the NMAS Class, then click the left-arrow to move this method into the Methods list.

    All other fields can remain in the default state.

  5. (Conditional) If you want the user’s credentials (username and password) to be available for Identity Injection policies, add the password fetch method as a second method for the contract.

    For more information about this method and class, see Password Retrieval.

  6. Click Next, then configure a card for the contract by filling in the following fields:

    ID: (Optional) Specify an alphanumeric value that identifies the card. If you need to reference this card outside of Administration Console, you need to 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, for example Smart Card.

    Image: Select the image to display on the card. You can select the NMAS Biometrics image or you can select the Select local image option and upload an image that your users can associate with using this smart card authentication contract.

    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.

  7. Click Finish, then click OK.

  8. Update Identity Server.

  9. Update Access Gateway.

  10. Continue with Assigning the NESCM Contract to a Protected Resource

Assigning the NESCM Contract to a Protected Resource

Contracts must be created before they can be assigned to protected resources. The following steps explain how to assign the NESCM contract to an existing protected resource. If you have not created a protected resource, see Section 2.6.5, Configuring Protected Resources.

  1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

    The reverse proxy must be configured with a resource that you want to protect with the smart card.

  2. Click Protected Resource for the proxy service where you want to assign the NESCM contract.

  3. To enable the NESCM contract on an existing protected resource, click Authentication Procedure for that resource, then select the NESCM contract created in Creating an Authentication Contract to Use the Method.

    If the contract is not listed, ensure that you have updated the changes to the servers, first to Identity Server and then Access Gateway. If you have multiple Identity Server configurations, ensure that Access Gateway is assigned to Identity Server configuration that contains the NESCM contract (click Access Gateways > Edit > Reverse Proxy / Authentication).

  4. Click OK.

  5. Click the Access Gateways task, then update Access Gateway.

  6. Continue with Verifying the User’s Experience.

Verifying the User’s Experience

  1. From the smart-card-equipped workstation, browse to and select the URL of the proxy service where the protected resource requiring NESCM type authentication is enabled.

  2. When prompted by Access Manager, enter a username.

  3. When prompted for the smart card password, enter a password (the smart card PIN).

If the Smart Card contains a certificate that meets the defined criteria (in this example, a matching Subject name and trusted signing CA), the user is now successfully authenticated to the IDP and is connected through Access Gateway to the protected resource.

Troubleshooting

Error

Resolution

Authentication fails without prompting the user for the token

Verify that you configured the class and method correctly. See Creating an NMAS Class for NESCM and Creating a Method to Use the NMAS Class.

Certificate validation fails

Verify that a trusted root object created for the signing CA of the certificate on the smart card exists in the eDirectory trusted root container.

4.1.12 Kerberos Authentication

Kerberos is an authentication method that allows users to log in to an Active Directory domain. This authentication method provides a token. You can configure Identity Server to use this token as a contract. This provides single sign-on for the user between Active Directory and Identity Server.

Kerberos authentication is achieved using SPNEGO with GSS-API (JGSS). SPNEGO (RFC 2478 - Simple and Protected GSSAPI Negotiation implementation in Microsoft Windows 2000/XP/2k3/2k8) is a GSSAPI mechanism for extending a Kerberos single-sign-on environment to web transactions and services. It enables peers determine which GSSAPI mechanisms are shared and enables them select one and establish a security context with it. SPNEGO's most visible use is in Microsoft's HTTP Negotiate authentication mechanism.

The Kerberos module for Access Manager is implemented as an additional out-of-the-box authentication mechanism to securely negotiate and authenticate HTTP requests for protected resources. This makes it possible to seamlessly authenticate (single sign-on) to Identity Server from enterprise-wide Microsoft Windows Domain Logon.

This section explains how to configure Active Directory, Identity Server, and Access Gateway for Kerberos authentication to a protected web server.

Figure 4-4 Example Kerberos Configuration

  1. A user logs in to the computer.

  2. The client computer gets a ticket granting ticket.

  3. The user sends a request to the protected resource.

  4. Access Gateway redirects the request to Identity Server for authentication.

  5. The client sends a request to Identity Server.

  6. Identity Server sends the 401 unauthorized response.

  7. The client sends a request with the Kerberos service ticket.

  8. Identity server decrypts the Kerberos ticket using the key tab file and then it performs an LDAP search with user principal name.

  9. Identity Server receives the success status for the LDAP search, and then the user authentication is completed successfully.

  10. Identity Server redirects the response to Access Gateway.

  11. The user gets access to the protected resource.

Perform the following tasks to configure Kerberos authentication:

  1. Configure Active Directory. See Configuring Active Directory.

  2. Configure Identity Server. See Configuring Identity Server.

  3. Configure clients. See Configuring the Clients.

  4. Configure Access Gateway. See Configuring Access Gateway for Kerberos Authentication.

Prerequisites for Configuring Kerberos Authentication

  • Clients must be running on Windows with Internet Explorer, Chrome, or Firefox.

    To make Kerberos work with Internet Explorer, you need to enable integrated Windows authentication. For information about how to enable this feature, see “Authentication Uses NTLM instead of Kerberos”.

    IMPORTANT:You must perform the following tasks:

    • Configure Internet Options of the web browser to trust the URL of Identity Server.

    • Configure the keytab file to trust more than DES encryption. If you created your keytab file for an earlier version of Access Manager where only DES was supported, you need to recreate the keytab file. For information, see Configuring the Keytab File.

    For more information, see TID 7006036.

  • Active Directory must be configured to contain entries for both users and their machines.

  • Active Directory and Identity Server must be configured to use a Network Time Protocol server. If time is not synchronized, authentication fails.

  • If a firewall separates the Active Directory Server from Identity Server, ports TCP 88 and UDP 88 are opened. So that Identity Server can communicate with Key Distribution Centre (KDC) on the Active Directory Server.

Configuring Active Directory

Perform the following tasks:

Creating and Configuring the User Account for Identity Server

  1. In Administrative Tools on your Windows server, click Active Directory users and computers.

  2. Select to create a new user.

  3. Specify the following details:

    Field

    Description

    First name

    Specify the hostname of Identity Server. This is the username. For the example configuration, this is amser.

    You can verify the hostname by running the hostname command on Identity Server.

    User logon name

    Specify HTTP/<Identity_Server_Base_URL>.

    For example, if base URL of Identity Server is amser.nam.example.com, specify the following:

    HTTP/amser.nam.example.com

    The realm is displayed next to the User logon name.

    User logon name (pre Windows 2000)

    Specify the hostname of Identity Server.

    The default value must be modified. For example, amser.

    (Complete this step regardless of the Windows version you are using.)

  4. Click Next, configure the password, and perform the following actions:

    Field

    Description

    User must change password at next logon

    Deselect this option.

    Password never expires

    Select this option.

  5. Click Next > Finish.

    This creates an Identity Server user. You need to remember the values you assigned to this user for First name and User logon name.

  6. Set the servicePrincipalName (spn) attribute for this user. Open the command prompt or PowerShell and run the following command as an administrator:

    setspn -A HTTP/<userLogonName> <userName>

    IMPORTANT:This command is case-sensitive.

    For this configuration example, run the following command:

    setspn -A HTTP/amser.nam.example.com@AD.EXAMPLE.COM amser

    This adds the servicePrincipalName attribute to the user specified with the value specified in the -A parameter.

    NOTE:For Domain Services for Windows, set HOST spn also by using this command: setspn -A HOST/<userLogonName> <userName>

  7. (Optional) Verify that the user has the required servicePrincipalName attribute with a valid value. Enter the following command:

    setspn -L <userName>

    For this configuration example, enter the following command:

    setspn -L amser

Configuring the Keytab File

The keytab file contains the secret encryption key that is used to decrypt the Kerberos ticket. You need to generate the keytab file and copy it to Identity Server.

  1. On the Active Directory server, open a command window and enter a ktpass command with the following parameters:

    ktpass /out value /princ value /mapuser value /pass value /pType KRB5_NT_PRINCIPAL

    The command parameters require the following values:

    Parameter

    Value

    Description

    /out

    <outputFilename>

    Specify a name for the file, with .keytab as the extension. For example: nidpkey.keytab

    /princ

    <servicePrincipalName> @<KERBEROS_REALM>

    Specify the service principal name for Identity Server, then @, followed by the Kerberos realm. The default value for the Kerberos realm is the Active Directory domain name in all capitals. The Kerberos realm value is case sensitive.

    /mapuser

    <identityServerUser>@<AD_DOMAIN>

    Specify the username of Identity Server user and the Active Directory domain to which the user belongs.

    /pass

    <userPassword>

    Specify the password for this user.

    /pType

    <principalType>

    Specify the principal type as KRB5_NT_PRINCIPAL.

    For this configuration example, specify the following command to create a keytab file named nidpkey:

    ktpass /out nidpkey.keytab /princ HTTP/amser.nam.example.com@AD.
    EXAMPLE.COM /mapuser amser@AD.EXAMPLE.COM /pass example /pType KRB5_NT_PRINCIPAL 
  2. Copy the file to the default location on Identity Server:

    Linux: /opt/novell/java/jre/lib/security

    Windows Server: C:\Program Files\Novell\jre\lib\security

  3. If the cluster contains multiple Identity Servers, copy the keytab file to each member of the cluster.

Adding Identity Server to the Forward Lookup Zone

  1. In Administrative Tools on your Windows server, click DNS.

  2. Click Forward Lookup Zone.

  3. Click the Active Directory domain.

  4. In the right pane, right click, and select New Host (A).

  5. Specify the following details:

    Name: Specify the hostname of Identity Server.

    IP Address: Specify the IP address of Identity Server.

  6. Click Add Host.

Configuring Identity Server

Perform the following tasks:

  • Configure Identity Server to use the Active Directory server as a user store.

  • Configure a Kerberos authentication class, method, and contract.

  • Create a configuration file.

  • Enable logging to verify the configuration.

These instructions assume that you have installed and configured an Identity Server cluster configuration.

See Installing Access Manager in the NetIQ Access Manager 4.5 Installation and Upgrade Guide and Configuring Identity Servers Clusters.

Topics include:

Enabling Logging for Kerberos Transactions

Enabling logging is highly recommended. If Kerberos authentication does not function after you complete the configuration tasks, you can check the reasons in the log file (catalina.out on Linux or stdout.log on Windows).

  1. Click Devices > Identity Servers > Edit > Auditing and Logging.

  2. Select File Logging and Echo To Console options.

  3. In the Component File Logger Levels section, set Application to debug.

  4. Click OK, then update Identity Server.

Configuring Identity Server for Active Directory

You need to configure Identity Server to use Active Directory as a user store or verify your existing configuration for your Active Directory user store.

  1. Click Devices > Identity Servers > Edit.

  2. Click Local.

  3. View installed user stores.

    If you have already configured Identity Server to use the Active Directory server, click its name.

    If you have not configured a user store for the Active Directory server, click New.

  4. For a new user store, specify the following details. For an existing Active Directory user store, verify the values.

    Field

    Description

    Name

    Specify a name of the user store for reference.

    Admin name

    Specify the name of the administrator of the Active Directory server. Administrator-level rights are required for setting up a user store. This ensures read/write access to all objects used by Access Manager.

    Admin password and Confirm password

    Specify the password for the administrator of the Active Directory server and confirm the password.

    Directory Type

    Select Active Directory.

    Search Contexts

    For a new user store, click New and specify the context of the administrator of the Active Directory server. For an existing user store, verify that you have an entry for the context of the administrator and add one if it is missing.

  5. (Conditional) For a new Active Directory user store, add a replica.

    1. In the Server replicas section, click New.

    2. Specify the following details:

      Name: Specify a name of the replica for reference. This can be the name of your Active Directory server.

      IP Address: Specify the IP address of the Active Directory server and the port you want Identity Server to use when communicating with the Active Directory server.

    3. Configure the other fields to fit your security model.

    4. Click OK.

  6. (Optional) Specify values for the other configuration options.

  7. Click OK or Finish.

  8. Continue with Creating the Authentication Class, Method, and Contract.

Creating the Authentication Class, Method, and Contract

Ensure that Prerequisites for Configuring Kerberos Authentication are met.

  1. In the Local page, click Classes > New.

  2. Specify the following details:

    Display name: Specify a name that you can use to identify this class.

    Java class: Select KerberosClass.

  3. Click Next.

  4. Specify the following details:

    Field

    Description

    Service Principal Name (SPN)

    Specify the value of the servicePrincipalName attribute of the Identity Server user.

    For this example configuration, this is HTTP/amser.nam.example.com.

    Kerberos Realm

    Specify the name of the Kerberos realm. The default value for this realm is the domain name of the Active Directory server, entered in all capitals. The value in this field is case-sensitive.

    For this example configuration, this is AD.EXAMPLE.COM.

    JAAS config file for Kerberos

    Verify the default path. This must be the same path to which you copied the keytab file (see Step 2 in Configuring the Keytab File) and end with the name of the configuration file, bcsLogin.conf.

    For Windows, the path needs to contain double slashes, for example: C:\\Program Files\\Novell\\jre\\lib\\security

    For information about creating this file, see Creating the bcsLogin Configuration File.

    Kerberos KDC

    Specify the IP address of KDC. If multiple KDCs are present for fail-over support, then specify the IP addresses separated by colon (:). You can configure up to four IP addresses.

    If a L4 switch is configured for load balancing among KDCs, then specify the virtual IP address of the L4 switch in this field.

    User Attribute

    Specify the name of the Active Directory attribute that combines the cn of the user with the DNS domain name to form its value.

    It is an alternate name for user login. Accept the default value unless you have set up a different attribute.

  5. (Conditional) If you have configured your users to have multiple User Principal Names (UPN) so they can log in using different names (such as jdoe@abc.com, jdoe@bcd.com, and jdoe@cde.com), click New, specify the suffix (such as @abc.com), then click OK.

  6. Click Finish.

    IMPORTANT:You must create only one Kerberos class. This is caused by a limitation in the underlying Sun JGSS.

  7. On the Local page, click Methods > New.

  8. Specify the following details:

    Field

    Description

    Display name

    Specify a name that you can use to identify this method.

    Class

    Select the class that you created for Kerberos.

    User stores

    Move the Active Directory user store to the list of User stores.

    If you have only one installed user store, <Default User Store> can be used.

    If you have multiple user stores, the Active Directory user store must be in this list (or if it is configured to be the default user store, <Default User Store> must be in this list).

    NOTE:The testing procedure to verify Kerberos authentication depends on whether the Active Directory user store configured as the default user store. See Step 13.

    You do not need to configure properties for this method.

  9. Click Finish.

  10. In the Local page, click Contracts > New.

  11. Specify the following details:

    Field

    Description

    Display name

    Specify a name that you can use to identify this method.

    URI

    Specify a value that uniquely identifies the contract from all other contracts.

    Methods

    From the list of Available methods, move your Kerberos method to the Methods list.

    You do not need to configure the other contract options.

  12. Click Finish.

  13. (Optional) To use the procedure that verifies the authentication configuration, make the Active Directory user store as the default user store.

    1. In the Local page, click Defaults.

    2. Specify the following details:

      User Store: Select the name of your Active Directory user store.

      Authentication Contract: Select the name of your Kerberos contract.

    3. Click OK.

      This allows you to log in directly to Identity Server by using the Kerberos contract. If you have already logged in to the Active Directory domain on the Windows machine, single sign-on is enabled and you are not prompted to log in to Identity Server.

  14. On the Identity Servers page, click Update.

    Wait until the Health icon turns green. Click Refresh to update the page.

  15. If you want to configure Access Gateways to use the Kerberos contract, update these devices so that the Kerberos contract is available.

  16. Continue with Creating the bcsLogin Configuration File.

Creating the bcsLogin Configuration File

The bcsLogin.conf file defines the Login module used for Kerberos implementation, service principal name for Identity server, location of the keytab file, and other configuration options.

Perform the following steps to create the file:

  1. Open a text editor. A sample editable bcsLogin.con file called bcsLogin.conf.template is included. Open this file.

  2. Enter the following lines.

    The file cannot contain any white space, only end-of-line characters. Two lines (principal and keyTab) need to specify unique information for your configuration. The principal line needs to specify the service principal name for Identity Server. The keyTab line needs to specify the location of the keytab file. The following file uses the values of the example configuration for the principal and keyTab lines. The keyTab and ticketCache lines use the default path for SUSE Linux Enterprise Server (SLES).

    com.sun.security.jgss.accept {
    com.sun.security.auth.module.Krb5LoginModule required
    debug="true"
    useTicketCache="true"
    ticketCache="/opt/novell/java/jre/lib/security/spnegoTicket.cache"
    doNotPrompt="true"
    principal="HTTP/amser.nam.example.com@AD.EXAMPLE.COM"
    useKeyTab="true"
    keyTab="/opt/novell/java/jre/lib/security/nidpkey.keytab"
    storeKey="true";
    };

    Identity Server checks the Kerberos server for each user transaction. When you set the isInitiator value to false (isInitiator="false") in the bcsLogin.conf file after the keyTab="/opt/novell/java/jre/lib/security/nidpkey.keytab" line, Identity Server does not communicate to the Kerberos server.

    Path of bcsLogin.conf on SLES and Red Hat is /opt/novell/java/jre/lib/security/.

    NOTE:Before setting the value to false, it is recommended that you access the protected site via https and the keytab file is secure.

    For Windows, the path needs to contain double slashes: C:\\Program Files\\Novell\\jre\\lib\\security

    Windows Server: The path in the keyTab line must be C:\\Program Files\\Novell\\jre\\lib\\security\\nidpkey.keytab

    The path in the ticketCache line must be C:\\Program Files\\Novell\\jre\\lib\\security\\spnegoTicket.cache

  3. Save this file with a name of bcsLogin.conf.

  4. Copy this file to the location specified in the JAAS config file for Kerberos field of Step 4 in Creating the Authentication Class, Method, and Contract.

  5. Ensure that the file permissions are set to 644.

  6. Restart Identity Server.

    • Linux Identity Server: Specify the following command:

      /etc/init.d/novell-idp restart

    • Windows Identity Server: Specify the following commands:

      net stop Tomcat8

      net start Tomcat8

    Whenever you make changes to the bcsLogin.conf file, restart Tomcat.

  7. If the cluster contains multiple Identity Servers, copy the bcsLogin.conf file to each member of the cluster, then restart Tomcat on that member.

Verifying the Kerberos Configuration

To view catalina.out (Linux) or stdout.log (Windows) of Identity Server, perform the following steps:

  1. Click Auditing > General Logging.

  2. In Identity Servers section, select the catalina.out or stdout.log file.

  3. Download the file and open it in a text editor.

  4. Search for Kerberos and verify that a subsequent line contains a Commit Succeeded phrase. For the configuration example, the lines look similar to the following:

    principal's key obtained from the keytab
    principal is HTTP/amser.nam.example.com@AD.EXAMPLE.COM
    Added server's keyKerberos Principal HTTP/amser.nam.example.com@AD.EXAMPLE.COMKey Version 3key EncryptionKey: keyType=3 keyBytes (hex dump)=0000: CB 0E 91 FB 7A 4C 64 FE
    
    [Krb5LoginModule] added Krb5Principal HTTP/amser.nam.example.com@AD.EXAMPLE.COM to Subject
    Commit Succeeded
  5. If the file does not contain any lines similar to these, verify that you have enabled logging. See Enabling Logging for Kerberos Transactions.

  6. If the commit did not succeed, search backward in the file and verify the following values:

    • Service Principal Name

    • Name of keytab file

    For the example configuration, the file must contain lines with text similar to the following:

    Principal is HTTP/amser.nam.example.com
    KeyTab is /usr/lib/java/jre/lib/security/nidpkey.keytab
  7. (Conditional) If you make any modifications to the configuration in Administration Console or in the bcsLogin file, restart Tomcat on Identity Server.

(Optional) Excluding Kerberos Authentication for Specific IP Addresses

You can configure the IP address or the range of IP addresses of the clients for which Kerberos authentication must be skipped or performed using the kerberos.exclude or kerberos.include keywords respectively.

NOTE:You can specify only kerberos.exclude or kerberos.include argument in the kerb.properties file not both.

To configure this option, add the following entry in the kerb.properties file:

  • kerberos.exclude=IP Address/Range separated by comma.

  • kerberos.include=IP Address/Range separated by comma.

For example:

kerberos.exclude=1.1.1.1-9.255.255.255,10.50.1.1 - 10.50.1.50,11.1.1.1-255.255.255.255

or

kerberos.include=10.1.1.1-10.49.255.255,10.50.1.51-10.255.255.255

For the clients coming from the IP addresses specified in kerberos.exclude, Kerberos authentication will be skipped and will fall back to the custom authentication class. See (Optional) Configuring the Fall Back Authentication Class.

For the clients coming from the IP addresses that are not specified in kerberos.include, kerberos authentication will be skipped and will fall back to the custom authentication class. See (Optional) Configuring the Fall Back Authentication Class.

The kerb.properties file is available in /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/.

(Optional) Configuring the Fall Back Authentication Class

You can configure an optional authentication class that is executed when either kerberos authentication fails or when kerberos authentication has to be skipped.

For information about how to skip the Kerberos authentication for certain IP addresses, see (Optional) Excluding Kerberos Authentication for Specific IP Addresses.

To configure the fall back authentication class, perform the following steps:

  1. Go to Identity Server Cluster > Edit > Local > Methods > (Kerberos Method) > Properties.

  2. Add a new property /value pair with name as FALLBACK_AUTHCLASS and set the property value to be the qualified class name, such as com.novell.nidp.authentication.local.PasswordClass.

    The class name value must be same as the value configured in the Java class path of the class at Identity Server Cluster > Edit> Local > Classes> (Authentication class).

NOTE:If your authentication class requires a custom JSP file for seeking credentials, add the property JSP and specify the name of the jsp file. When the JSP property is not specified, Identity Server uses the default login.jsp for seeking the credentials.

If you want to fall back to basic authentication, configure any one of the following properties: Property Name: FALLBACK_AUTHCLASS

Property Value: Basic or com.novell.nidp.authentication.local.BasicClass

IMPORTANT:The property name is case-sensitive.

For example, if you want to fall back to RADIUS, configure the following properties for the kerberos method:

FALLBACK_AUTHCLASS=com.novell.nidp.authentication.local.RadiusClassJSP=radiusloginServer=<<radius IPs with comma separate>>SharedSecret=<<secret string>>Port=<<port>>ReplyTime=7000 (in milli seconds, this is optional)ResendTime=2000 (in milli seconds, this is optional)Retry=5 (this is optional)Password=false

You can configure fall back to other mechanism based on the incoming header. In the kerberos method, add property as NO_NEGO_HEADER_NAME in Property and specify the header that needs to be ignored for the kerberos authentication in value.

For example, you have configure the name as NO_NEGO_HEADER_NAME with the value X-NovINet in the kerberos method properties. Then, if the client comes with header X-NovINet, the kerberos class will not be executed and it will fall back to the name password form by default or to the configured fall back mechanism.

(Optional) Modifying the LDAP Query Parameter of the Kerberos Method

You can modify the LDAP query parameter of the Kerberos method by using the SearchQuery property. For example, if you want to use the SearchQuery property for emails, perform the following steps:

  1. Navigate to Identity Servers > Edit > Local > Methods.

  2. Click the Kerberos method.

  3. Click Properties > New.

  4. Specify the following details:

    Property Name: SearchQuery

    Property Value: Specify one of the following parameters:

    • (&(objectclass=person)(mail=%Email%))

    • (&(objectclass=person)(givenName=%<Kerberos Realm>%))

      NOTE:Let us assume the UPN suffix is configured as AMTEST.COM and the Active Directory givenName is configured as user191. The LDAP search query will be (&(objectclass=person)(givenName=user191@AMTEST.COM)).

    • (&(objectclass=person)(name=%Ecom_User_ID%))

    • (&(objectclass=person)(CN=%Ecom_User_ID%))

Configuring the Clients

  1. Add the computers of the users to the Active Directory domain.

    For instructions, see the Active Directory documentation.

  2. Log in to the Active Directory domain, rather than the machine.

  3. (Conditional) If you are using Internet Explorer, perform the following steps to trust Identity Server:

    1. Click Tools > Internet Options > Security > Local intranet > Sites > Advanced.

    2. In Add this website to the zone, specify Base URL of Identity Server, then click Add.

      In the configuration example, this is http://amser.nam.example.com.

    3. Click Close > OK.

    4. Click Tools > Internet Options > Advanced.

    5. In the Security section, select Enable Integrated Windows Authentication, then click OK.

    6. Restart the browser.

  4. (Conditional) If you are using Firefox, perform the following steps to trust Identity Server:

    1. In URL, specify about:config.

    2. In Filter, specify network.n.

    3. Double click network.negotiate-auth.trusted-uris.

      This preference lists the sites that are permitted to engage in SPNEGO Authentication with the browser. Specify a comma-delimited list of trusted domains or URLs.

      For this example configuration, add amser.nam.example.com to the list.

    4. If the deployed SPNEGO solution is using the advanced Kerberos feature of Credential Delegation, double-click network.negotiate-auth.delegation-uris. This preference lists the sites for which the browser can delegate user to the server. Specify a comma-delimited list of trusted domains or URLs.

      For this example configuration, add amser.nam.example.com to the list.

    5. Click OK, then restart your Firefox browser.

  5. (Conditional) If you are using Chrome, perform the following steps to trust Identity Server:

    1. Click Control Panel > Network and Internet > Internet Options > Security > Local intranet > Sites > Advanced.

    2. In Add this website to the zone, specify Base URL of Identity Server, then click Add.

      In the configuration example, this is http://amser.nam.example.com.

    3. Click Close > OK.

    4. Select Advanced.

    5. In the Security section, select Enable Integrated Windows Authentication, then click OK.

    6. Restart the browser.

    NOTE:If you have configured Internet Explorer settings, then you do not need to perform these steps. Chrome in Windows uses the Internet Explorer settings.

  6. In URL, specify Base URL of Identity Server with port and application. For this example configuration, specify the following:

    http://amser.nam.example.com:8080/nidp

    Identity Server must authenticate the user without prompting the user for authentication information. If a problem occurs, check for the following configuration errors:

    • Verify the default user store and contract. See Step 13.

    • View Identity Server logging file and verify the configuration. See Verifying the Kerberos Configuration.

    • If you make any modifications to the configuration in Administration Console or to the bcsLogin file, restart Tomcat on Identity Server.

  7. (Conditional) Users who are outside the firewall cannot use Kerberos. SPNEGO by default first uses NTLM, then to HTTPS basic authentication. Access Manager does not support NTLM, so the NTLM prompt for username and password fails. The user is then prompted for a username and password for HTTPS basic authentication, which succeeds if the credentials are valid.

    To avoid these prompts, you can have your users enable the Automatic logon with current user name and password option in Internet Explorer 7.x. To access this option, click Tools >Internet Options >Security >Custom Level, then scroll down to User Authentication.

Configuring Access Gateway for Kerberos Authentication

If you want to configure Kerberos authentication for a web server, set up a protected resource for this web server, and select the name of the Kerberos contract for the authentication procedure. For instructions, see Section 2.6.5, Configuring Protected Resources.

When using Kerberos for authentication, the LDAP credentials are not available. If you need LDAP credentials to provide single sign-on to some resources, see Section 4.1.10, Password Retrieval.