5.1 Local Authentication

To guard against unauthorized access, Access Manager supports a number of ways for users to authenticate. These include name/password and X.509 digital certificates. You configure authentication at Identity Server by creating authentication contracts that Access Manager components (such as an Access Gateway) can use to protect a resource.

Figure 5-1 illustrates the components of a contract:

Figure 5-1 Local Authentication

  • User stores: The user directories to which users authenticate on the back end. You set up your user store when you create an Identity Server cluster configuration. See Section 5.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 5.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 Section 5.1.3, 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 Section 5.1.4, Configuring Authentication Contracts.

This section explains the following:

5.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 creating an Identity Server configuration. You use the same procedure for setting up the initial user store, adding a user store, or modifying an existing user store.

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

  2. Select from the following actions:

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

    Delete: To delete a user store, 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 more than one user store during authentication. Figure 5-2 illustrates this type of configuration.

Figure 5-2 Multiple LDAP Directories

It is assumed that each LDAP directory contains different users. You must 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 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 that you also add the replicas to the secondary Administration Console.

All user stores that you add are included in health checks. If health problems are found, 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. Fill in the following fields:

    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: The type of LDAP directory. You can 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.3 Developer 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 going to use that SecretStore for Access Manager secrets. If you select this option, ensure that the admin you have configured for the user store has sufficient rights to extend the schema and add objects to the tree.

    For additional configuration steps required to use secrets, 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 is sharing secrets with other applications and these applications are using the security flag that locks secrets when a user’s password is reset, you need to enable this option.

    • If Access Manager is not sharing secrets with other applications, the secrets it is using are never locked, and you do not need enable this option.

  4. Under LDAP timeout settings, specify the following:

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

    Idle Connection: Specify how long in seconds before connections begin closing. If a connection has been idle for this amount of time, the system creates another connection.

  5. To specify a server replica, click New, then fill in the following fields:

    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.

    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 configuration we recommend 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.

    This option must be enabled 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 have specified 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 the Specify server replica information dialog box.

  11. Select the replica, then click Validate to test the connection between Identity Server and the 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, you need to verify that you have given the admin for the user store sufficient 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 like Login ID and password credentials. These input data can later be reused or injected using Form Fill and Identity Injection policies. This feature is especially 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:

  • Configuring the Configuration Datastore to Store Secrets.

    If you want to do minimal configuration, you can use the configuration datastore on Administration Console to store the secrets. This option can be used 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.

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

  • Configuring an LDAP Directory to Store the Secrets.

    This is the recommended option and can be used 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.

  • 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 Novell 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 troubleshooting tips, see Troubleshooting the Storing of Secrets.

Configuring the Configuration Datastore to Store Secrets

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.

  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 either of these options are changed after any secrets are stored, Access Manager will not be able to 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. On Identity Servers page, update Identity Server.

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

Configuring an LDAP Directory to 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 they aren’t, click the name of the replica and reconfigure it.

To configure the LDAP directory:

  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 Section 8.5.4, Creating and Managing Shared Secrets.

For troubleshooting information, see Troubleshooting the Storing of Secrets.

Configuring an eDirectory User Store to Use SecretStore

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 the 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 higher 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 the SecretStore

When an administrator resets a user's password, secrets written to the Novell 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, complete the following configuration 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 the SecretStore is locked, this feature of Access Manager cannot unlock the SecretStore. If it is necessary to unlock the SecretStore by using the user’s prior password, another tool must be used. See your 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 twice, 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 8.5.4, Creating and Managing Shared Secrets.

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

Troubleshooting the Storing of Secrets

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. On Identity Servers page, 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.

Either 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

5.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 drop-down menu.

    • 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 Section 5.1.8, 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 5.4, Social Authentication.

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

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

      Risk-based Pro-Auth Class: The authentication class used for assessing the risk before authentication. See Section 5.5, Risk-based Authentication.

      ProtectedBasicClass: BasicClass protected by HTTPS.

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

      ProtectedRadiusClass: RadiusClass protected by HTTPS. See Section 5.3.2, RADIUS Authentication for configuration steps.

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

      NMASAuthClass: The authentication class used for Novell Modular Authentication Services (NMAS), which uses fingerprint and other technology as a means to authenticate a user. For instructions on using the NMAS NESCM method, see Section 5.1.12, 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 Section 5.1.9, 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 5.1.11, Password Retrieval.

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

      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 Novell Access Manager Developer Tools and Examples.

      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 3.5.9, Specifying Advanced Authentication Server Details.

      IMPORTANT:To enable CSRF check, perform the steps mentioned in LOGIN CSRF CHECK (This option is available in Access Manager 4.3 Service Pack 3 and later versions.) 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 you enter 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 5.1.3, Configuring Authentication Methods.

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

Specifying Common Class Properties

The following properties can be used by the basic and password classes:

These properties can also be specified on a method derived from the class. If you are going 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.

Query Property

Normally, 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.

The LDAP query parameter of Kerberos method can be modified using 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 Kerberos Method

  3. Click Properties > New

  4. In the Add Property dialog box, specify the following:

    Property Name: SearchQuery

    Property Value: (&(objectclass=person)(mail=%Email%))

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 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 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 information about how to create a custom login page, see Customizing Identity Server Login Page.

Modifying LDAP Query Parameter of Kerberos Method

The LDAP query parameter of Kerberos method can be modified using 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 Kerberos Method

  3. Click Properties > New

  4. In the Add Property dialog box, specify the following:

    Property Name: SearchQuery

    Property Value: Specify one of the following parameters:

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

    • (&(objectclass=person)(givenName=%AMTEST.COM%))

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

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

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 the latest No CAPTCHA reCAPTCHA version of the reCAPTCHA. For more information, see Google 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:

  • One or more supported identity sources:

    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 should be configured with an intrusion detection policy. For more information, see Configuring Intrusion Detection for Failed Logins.

  • A Google reCAPTCHA account. For more information, see Setting Up a reCAPTCHA Account.

Configuring Intrusion Detection for Failed Logins

Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your 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, you should 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 logon 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.

After you have configured 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. Click Register.

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

  6. Continue with Configuring reCAPTCHA.

Configuring reCAPTCHA

To configure reCAPTCHA, perform the following steps:

  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 threshold value. It is the number of failed attempts before you are prompted for reCAPTCHA authentication.

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

  5. Click OK, then update Identity server.

Enabling reCAPTCHA in Login Page

To enable reCAPTCHA in login page, see Enabling reCAPTCHA in Login Page.

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

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

    A method cannot be deleted if a contract is using it.

  3. To modify an authentication method, click its name, or to create one, click New.

  4. Fill in the following fields:

    Display Name: The name to be used to refer to the new method.

    Class: The authentication class to use for this method. See Section 5.1.2, Creating Authentication Classes.

    Identifies User: Specifies whether this authentication method must be used to identify the user. Usually, you must enable this option. When 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 on back end web application when the passwordfetch class is enabled, see TID.

    Overwrite Temporary User: If you select this check box, then the temporary user credentials profile got form previous authentication method in the same session will be overwritten with real user credentials profile got from this authentication method.

    Overwrite Real User: If you select this check box, then the real user credentials profile got form previous authentication method in the same session will be overwritten with real user credentials profile got from this authentication method.

  5. 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 Section 5.1.5, Specifying Authentication Defaults.

  6. (Optional) Under Properties, click New, then fill in the following fields:

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

    Property Name: The name of the property to be set. This value is case sensitive and specific to an authentication class. The same properties that can be set on an authentication class 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.

  7. Click Finish.

  8. Continue with Section 5.1.4, Configuring Authentication Contracts.

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

5.1.4 Configuring Authentication Contracts

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

Each contract is assigned a URI that uniquely identifies it. This URI can be shared with other providers so that they can identify the type of credentials the Identity Provider is requiring. You can also restrict a contract so that it can only be used for local authentication and not with other providers.

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

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

    You cannot delete a contract if it is in use by an Access Gateway.

  3. To create a new contract, click New.

  4. Fill in the following fields:

    Display name: Specifies the name of the authentication contract.

    URI: Specifies a value that uniquely identifies the contract from all other contracts. It is used to identify this contract for external providers and is a unique path value that you create. No spaces can exist in the URI field.

    The following are all valid values for the URI:

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

    Password expiration servlet: Specifies a URL to a page where the user can change password when the password expires or is within the grace login period. You must use eDirectory to change the number of grace logins. Grace logins work only with eDirectory.

    For more information about how to use this type of servlet, see Using a Password Expiration Service.

    Allow User Interaction: If you specify a password expiration servlet, you can enable this option, which allows the users to decide whether to go to the servlet and change their passwords or to skip the servlet. If you always want to force the users to go the servlet to change their passwords, do not enable this option.

    Login Redirect URL: You will be redirected to the URL specified in this field. Use this field for the following scenarios:

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

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

    For more information about the URL parameters, see Using Login Redirect URL Parameters.

    Allow User Interaction: You can enable this option, which allows the user to decide whether to continue to access a pre-configured URL or to continue to the page that the user usually accesses. For example, the user may usually access www.a.com and have specified the redirect URL as https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL> then, continue will allow you to continue with the website you access i.e. www.a.com and redirect URL will take you to the URL https://someservice.com/path/password?user=<USERID>&store=<STOREID>&returl=<RETURN_URL>&action=expire and then to www.a.com.

    Authentication Level: A number you can assign to this authentication contract to specify its security level or rank. You use this setting to preserve authentication contracts of a higher security level. When you enable the Satisfiable by a contract of equal or higher level option on this page, the system uses this value as a reference.

    For example, you might create a name/password authentication contract and assign it to level one. You might also create an X.509 authentication contract and assign it to level two. If a user supplies the credentials for the X.509 level-two contract, the system does not require the credentials to satisfy the name/password level-one authentication contract.

    Authentication Timeout: Specify how long the session can be inactive before the user is prompted to log in again. The value can be from 5 minutes to 66535 minutes and must be divisible by 5.

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

    You need to experiment to discover what values are best for your network configuration, your security requirements, and your users.

    • Shorter timeouts increase back-channel traffic and require more threads for authentication checks, but quickly free resources that are being used by inactive users. If you have slow back-end services, users could get disconnected waiting for a response, and these disconnects can generate more authentication traffic.

    • Longer timeouts, which allow inactive users to remain connected, increase memory requirements to store session information, but require fewer threads and don't generate as much back-channel traffic.

    For example, if you set the timeout to 5 minutes, an authentication check needs to be done 12 times each hour for each user authenticating with this contract. If the timeout is set to 60 minutes, an authentication check is done only one time each hour for each user. However, for the 5 minute timeout, resources can be freed within 5 minutes of inactivity by the user. For the 60-minute timeout, resources can take as long as 60 minutes to be freed, depending upon when the user goes inactive.

    NOTE:In case of Name/Password - Basic and Secure Name/Password - Basic contracts applied to a protected resource, then you won’t find the session as timed out, as the session gets renewed after timeout without user intervention using the Basic header sent from browser to Identity Provider.

    For information about how to use this feature with 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: Allows the system to satisfy this authentication contract if a user has logged in using another contract of an equal or higher authentication level, as specified in the Authentication Level field of an authentication contract.

    When you enable this option, you need to be aware of the authentication levels you have set for other contracts and the level that has been assigned to the default contract.

    When the protected resource is configured with Name/Password -Form as Authentication procedure, the user authentication details are prompted with transient federation. This option must be enabled to avoid prompting for authentication in the Target Service Provider.

    Satisfiable by External Provider: Allows this contract to be selected when configuring an identity provider for Liberty or SAML 2.0. When you configure the authentication request, you can select a contract that has this option enabled and require the identity provider to use this contract 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 Section 5.1.4, Configuring Authentication Contracts.

      Most third-party identity providers do not use contracts.

    Allowable Class: Specifies the class that instructs a service provider to send a request for a specific authentication type to the Identity Provider. You are allowed to modify this option only when you select authentication types.

    NOTE:In SAML 2.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: Specifies the authentication method to use for the contract. You can specify the order in which the methods are executed for login; however, this is not a graded list, so all the methods you specify are required. Available methods are the authentication methods you have set up.

    You can enable the multi-factor authentication by associating more than one methods to a contract.

    If you add more than one X.509 method, only the first one is used and it is automatically moved to the top of the list.

    When you choose a secure method, such as Secure Name/Password, ensure that you have enabled security for Identity Server configuration by setting the protocol to HTTPS. See Section 17.0, Enabling SSL Communication.

  5. Click Next.

  6. Configure a card for the contract by filling in the following:

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

    Image: Specify the image to be displayed on the card. Select the image from the drop down list. To add an image to the list, click Select local image.

    Show Card: Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

    Passive Authentication Only: Select this option if you do not want 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 works with 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 table below lists a few common ones. 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 and paste this text, ensure that you 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 and paste this text, ensure that you 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 timeouts. Activity realms allow you to define how activity at one protected resource affects the activity timeout 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 timeout of 30 minutes and to contract C2 with a timeout of 15 minutes. Any activity at the resource protected by C1 or C2 marks activity to the shared1 time line. Figure 5-3 illustrates this scenario.

Figure 5-3 Two Contracts Sharing an Activity Realm

In Figure 5-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 timeout, 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 timeouts of the other contracts in the activity realm.

When you configure protected resources to use different contracts with different timeouts, 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 timeout 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 timeout value equal to the value of the Tomcat session. (The Tomcat session timout is set to the greatest timeout 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.

5.1.5 Specifying Authentication Defaults

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

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

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

  2. 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 contract or for an authentication type. When the request is for an authentication type, Identity Server must translate the type to a contract before authenticating the user. You can use the Authentication Type section of the Defaults page to specify which contract to use for the common types (classes).

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

  • 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 are stating that the contract is security equivalent to the class that is being requested. For configuration information, 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 5.1.4, Configuring Authentication Contracts.

  4. Click Next.

  5. Configure an authentication card for the contract.

    For information about these fields, see Section 5.1.4, Configuring Authentication Contracts.

  6. Click Finish, then OK.

  7. Update Identity Server.

5.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. To avoid this with PersistentAuthClass configuration you will not be required to re-authenticate using the password frequently. For sites that you use a low-grade identity for example, enterprise forums or some web sites that restrain your preferences, having to re-authenticate every few-hours is annoying. Some web sites offer the remember my password feature that will not ask the user to re-authenticate if you select this option. This class provides that remember my password functionality so that the user does not need to frequently re-authenticate.

PersistentAuthClass Properties

You can set the following class properties in the configuration file.

  • 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, cookie name is PA_PERSISTENT_AUTH. For example, if you configure the CookieSuffix as PER_AUTH, Identity Server sends cookie with PA_PER_AUTH name at browser.

  • MaxAgeSeconds: This property will decide the cookie lifetime. Default value is 86400 seconds (1 day). 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, follow the procedure given below.

    1. Login to Identity Server.

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

    3. Open login.jsp file using an editor.

    4. Search for EnableCookieAuth parameter name and provide the new name as TestCookieName in the input tag.

    5. Ensure that you select the Remember Me option.

    6. Restart Identity Server.

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

Customizing Login Page For Persistent Authentication

To enable 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 Persistent Authenticator Class

The following procedure allows you to configure the PersistentAuthClass. Persistent Authentication supports method properties described in the following section.

  1. Login 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 drop-down list.

  5. Click New to create a new authentication class.

  6. In the Add property window, specify the following values. Specifying these values are optional.

    • Property Name: Specify the name of the property. For more information on the names you can specify here, see PersistentAuthClass Properties

    • Property Value: Specify the property value you would like to define here.

  7. Click OK and Finish.

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

    For configuration information, see Section 5.1.3, Configuring Authentication Methods and Section 5.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 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 will be . Any request to that URL will clear 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 stored. 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 have logout page redirect 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

Following are the limitations with the 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 will be unable to stop the session until the cookie expires.

5.1.7 Client Integrity Check

You can configure a client integrity check policy to verify the recommended software (such as firewall and antivirus software) are installed on the client machine. You can configure different policies for Windows, Linux, and Macintosh machines and specify software that must be available in client machines to pass the client integrity check.

You need to create an identity provider authentication class that checks for the specified software on the client machine. You can configure policies to check processes, files, Windows registry, system services, and so on. This class can be executed with the first method of the contract. If the check fails, the user authentication fails.

Configuring Client Integrity Check

  1. Download the Client Integrity Check (CIC) package from the CIC Package download page and extract the CIC_utility.tar.gz file.

    Specifying details for the Operating System

  2. Traverse to CICtool/conf/config.xml file. Add the following details to the config.xml file:

    <OperatingSystem Name="Linux" UserInterfaceID="Linux" CICOSID="Linux"> . . . </OperatingSystem>

    To define operating system details for Windows and Macintosh, substitute UserInterfaceID, Name and CICOSID with Macintosh or Windows.

    NOTE:The attribute Name indicates the identifier for the operating system. Ensure that you use the same identifier for UserInterfaceID and CICOSID.

    Adding a Category

    A category is a group of similar software. For example, a firewall category can contain a list of firewalls such as the Windows Firewall and ZoneAlarm firewall. You can configure multiple software categories under each operating system in single cic policy.

    When multiple categories are configured for an operating system, if one of the enabled category does not exist on the client, the client integrity check fails.

  3. A category can be added to a operating system by adding <Type> tag in config.xml as follows:

    <OperatingSystem Name="Linux" UserInterfaceID="Linux" CICOSID="Linux"> <Type Name="Firewall_Linux" UserInterfaceID="Firewall_Linux" Status="true" CICTypeID="Firewall_Linux"> ... </Type> <Type Name="Antivirus_Linux" UserInterfaceID="Antivirus_Linux" Status="true" CICTypeID="Antivirus_Linux"> . </Type></OperatingSystem>

    As described in this example, multiple categories can be configured under an operating system.The Name attribute inside the <Type> tags indicate the category name.

    Set status to true to enable a specific category.

    Adding Applications for a Category

    A category consists of group of applications. You can add more than one application under a category. A client workstation is checked for the presence of any one of the software items in the category. If at least one of the enabled application definition exists on the system, the client integrity check passes for that category.

  4. To configure applications to a category, add <Info> tag as shown below.

    <OperatingSystem Name="Linux" UserInterfaceID="Linux" CICOSID="Linux"> <Type Name="Firewall_Linux" UserInterfaceID="Firewall_Linux" Status="true" CICTypeID="Firewall_Linux"> <Info Name="FireStarter" UserInterfaceID="FireStarter" Status="true"> . . . </Info> </Type> <Type Name="Antivirus_Linux" UserInterfaceID="Antivirus_Linux" Status="true" CICTypeID="Antivirus_Linux"> <Info Name="AntiVir" UserInterfaceID="AntiVir" Status="true"> . . . </Info> </Type></OperatingSystem>

    The Name attribute inside the <Info> tags indicate the application name. Set status to true to enable a specific application.

    NOTE:To enable an application you must have already enabled the category that it belongs to.

    Adding Attributes for an Application

    After you have added an application to a category, you must configure the attributes for each of these applications. These attributes can be in the form of RPMs, processes, registry keys, or executable files. The client integrity check detects the presence of these attributes.

  5. These attributes can be configured under each application by adding attribute type tags to config.xml as follows:

    <OperatingSystem Name="Linux" UserInterfaceID="Linux" CICOSID="Linux"> <Type Name="Firewall_Linux" UserInterfaceID="Firewall_Linux" Status="true" CICTypeID="Firewall_Linux"> <Info Name="FireStarter" UserInterfaceID="FireStarter" Status="true"> <AbsoluteFile UserInterfaceID="0" Name="/var/lock/subsys/firestarter" HashMD5="" /> <RPM UserInterfaceID="1" Name="FireStarter" Version="0.9.3" /> </Info> </Type> <Type Name="Antivirus_Linux" UserInterfaceID="Antivirus_Linux" Status="true" CICTypeID="Antivirus_Linux"> <Info Name="AntiVir" UserInterfaceID="AntiVir" Status="true"> <Process UserInterfaceID="0" Name="antivir" Owner="root" /> <AbsoluteFile UserInterfaceID="1" Name="/usr/lib/AntiVir/avguard" HashMD5="ss" /> </Info> </Type> </OperatingSystem>

    In this example, <AbsoluteFile>,<RPM>,<Process>,<AbsoluteFile> are examples of attribute type tags and fields like Name,Version,Owner are examples of attribute names.

    For more information about attributes for applications on different operating systems, see Configuring Attributes for an Application

    Client Security Levels

  6. You can configure different levels of client security. For more information about the different levels of client security, see Client Security Levels

    The security level can be configured by adding the following details to the config.xml file:

    <SecurityLevel Name="None" UserInterfaceID="None" DisplayMessage="Client Integrity failed" SecurityLevelID="None" CICReferenceCount="0" TrafficReferenceCount="1" /><SecurityLevel Name="Low" UserInterfaceID="Low" DisplayMessage="Your workstation is at Least Secure Level" SecurityLevelID="1" CICReferenceCount="3" TrafficReferenceCount="1"> . . .</SecurityLevel>

    The value of the Name field can be None,Low,Moderate and High,and the SecurityLevelID value in each case must be None,1,2 and 3 respectively.

    Adding Operating System details to the Security Level

  7. Under each security level, an operating system can be configured by adding <CICOS> tag as follows:

    <SecurityLevel Name="Low" UserInterfaceID="Low" DisplayMessage="Your workstation is at Least Secure Level" SecurityLevelID="1" CICReferenceCount="3" TrafficReferenceCount="1"> <CICOS UserInterfaceID="Linux" CICOSIDRef="Linux"> . </CICOS> <CICOS UserInterfaceID="Windows" CICOSIDRef="Windows"> . </CICOS> <CICOS UserInterfaceID="Macintosh" CICOSIDRef="Macintosh"> . . . </CICOS></SecurityLevel>

    This example shows configuration of operating system for security level Low,Other levels can be incorporated in the same manner.

  8. Under each operating system, category can be configured by adding <CICType> tag as follows:

    <SecurityLevel Name="Low" UserInterfaceID="Low" DisplayMessage="Your workstation is at Least Secure Level" SecurityLevelID="1" CICReferenceCount="3" TrafficReferenceCount="1"> <CICOS UserInterfaceID="Linux" CICOSIDRef="Linux"> <CICType UserInterfaceID="Firewall_Linux" CICTypeIDRef="Firewall_Linux" CICTypeStatus="true" /> <CICType UserInterfaceID="Antivirus_Linux" CICTypeIDRef="Antivirus_Linux" CICTypeStatus="true" /> </CICOS> <CICOS UserInterfaceID="Windows" CICOSIDRef="Windows"> <CICType UserInterfaceID="Firewall_Windows" CICTypeIDRef="Firewall_Windows" CICTypeStatus="true" /> <CICType UserInterfaceID="Antivirus_Windows" CICTypeIDRef="Antivirus_Windows" CICTypeStatus="true" /> </CICOS> <CICOS UserInterfaceID="Macintosh" CICOSIDRef="Macintosh"> <CICType UserInterfaceID="Antivirus_Mac" CICTypeIDRef="Antivirus_Mac" CICTypeStatus="true" /> </CICOS></SecurityLevel>

  9. Traverse to the CIC/CICtool/bin directory. Execute the CICtool binary by using the following command:

    $./CICtool ../conf/config.xml.

    This creates .txt policy files in the CICtext folder.

  10. In Identity Server, create the following directories by using the following commands:

    For Linux: $mkdir /opt/novell/nam/idp/webapps/nidp/classUtils/linux

    For Macintosh: $mkdir /opt/novell/nam/idp/webapps/nidp/classUtils/mac

    For Windows: $mkdir /opt/novell/nam/idp/webapps/nidp/classUtils/windows

  11. From the CICtext directory, copy the cic_linux.txt, cic_mac.txt and cic_windows.txt to the respective CIC system directory created in step 10.

    Use the following command to copy:

    For Linux: $ scp cic_linux.txt <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/linux

    For Macintosh: $ scp cic_mac.txt <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/mac

    For Windows: $ scp cic_windows.txt <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/windows

    Substitute idp login credentials with the server IPaddress, port, username and password to login to Identity Server.

  12. From the CIC bin directory, copy the LinCic, MacCic and wincic.exe to the respective CIC system directory created in step 10.

    Use the following commands to copy:

    For Linux: $ scp LinCic <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/linux

    For Macintosh: $ scp MacCic <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/mac

    For Windows: $ scp wincic.exe <idp login credentials>:/opt/novell/nam/idp/webapps/nidp/classUtils/windows

    Substitute idp login credentials with the server IPaddress, port, username and password to login to Identity Server

  13. Click Identity Server > Edit > Local > Classes > New

  14. Specify a name for the class and select ClientIntegrityCheckClass in Java class. Click Next.

  15. Click New and specify the following property name and property value:

    Name

    Value

    windowsBinary

    /nidp/classUtils/windows/wincic.exe

    windowsPolicy

    /nidp/classUtils/windows/cic_windows.txt

    linuxBinary

    /nidp/classUtils/linux/LinCic

    linuxPolicy

    /nidp/classUtils/linux/cic_linux.txt

    maci386Binary

    /nidp/classUtils/mac/MacCic

    maci386Policy

    /nidp/classUtils/mac/cic_mac.txt
  16. Click OK > Finish.

  17. Create a method for this class and deselect Identifies User check box and set all other fields to default settings and click OK. For instructions, see Section 5.1.3, Configuring Authentication Methods.

  18. Go to the Contracts tab and select CIC method from the Available Methods list and click OK. For instructions, see Section 5.1.4, Configuring Authentication Contracts.

Client Security Levels

You can configure the level of security configured at the client machine. You can decide the categories of software that you want to be present for each level.

You can configure the following security levels:

  • Least Secure: Specifies the minimum categories of software that must be present on a client machine for the client to be at the lowest secure level. When a client is at a least secure level, you can configure the traffic policies so that the client has access to limited set of resources.

  • Moderately Secure: Specifies the categories of software that must be present on a client machine for the client to be at a moderately secure level. When a client is at a moderately secure level, you can configure the traffic policies accordingly.

  • Secure: Specifies the software categories that must be present on a client machine for the client to be secure. When a client is at a secure, the traffic policies can be configured so that the client has access to all or most of the protected resources, depending on the role of the client.

  • None: If a client does not have any of the software such as firewall or antivirus specified in the client integrity check policy, then the security level of that client is None. When a client is at this level, the SSL VPN connection is established, but the client is given access to only a minimal set of resources.

Configuring Attributes for an Application

Specify details for the attributes. The following table lists the attributes for applications on different operating systems:

Operating System

Attribute Type

Attribute Name

Linux

RPM

Name: Specify the name of the RPM that must be present on the client machine.

Version: Specify the version of the RPM that must be present on the client machine.

Process

Name: Specify the name of the process that must be present on the client machine.

Owner: Specify the owner of the process.

Absolute File

Name: Specify the name and absolute path of the file that must be present on the client machine.

HashMD5: Specify the MD5 checksum value of the absolute file. To calculate the MD5 checksum value of an absolute file located in your local system, click Select File to select the file. The MD5 checksum value of the selected file is displayed.

To calculate the MD5 checksum value for an absolute file that is on another system, remotely connect to that system, calculate the MD5 value, then copy the value in the HasMD5 field.

NOTE:You can also copy the file from the remote system to the local system, then calculate the MD5 checksum by using the Select File option. However, this might change the MD5 value of the file during the process. If you want to use this method, then ensure that the file size and file contents did not change during the process.

Macintosh

Package

Name: Specify the name of the software package that must be present on the client machine.

 

Version Specify the version of the software package.

Process

Name: Specify the name of the executable file that must be present on the client machine.

 

Owner: Specify the owner of the process.

Absolute File

Name: Specify the name and absolute path of the file that must be present on the client machine.

HashMD5: Specify the MD5 checksum value of the absolute file. To calculate the MD5 checksum value of an absolute file located in your local system, click Select File to select the file. The MD5 checksum value of the selected file is displayed.

To calculate the MD5 checksum value for an absolute file that is on another system, remotely connect to that system, calculate the MD5 value, then copy the value in the HasMD5 field.

NOTE:You can also copy the file from the remote system to the local system, then calculate the MD5 checksum by using the Select File option. However, this might change the MD5 value of the file during the process. If you want to use this method, then ensure that the file size and file contents did not change during the process.

Windows

Process

Name: Specify the name of the executable file that must be present on the client machine.

 

RegistryKeyName: Specify the registry key name. When you add this name, make sure that you also specify a value for RegistryKey Value.

 

ValueName: Specifies the value for RegistryKey configured. The data found in this key value must be the absolute path of the folder where the process file is present.

 

Version: Specify the version of the software process that must be running in the client machine.

NOTE:The version attribute specifies the Windows Explorer file version number.

 

RegistryKey

Name: Specify the name and absolute path of the registry key that must be present on the client machine.

Value Name: Specify the name of the registry key value.

Value Data: Specify a data for the registry key value. This data can be for registry type REG_BINARY, REG_DWORD, REG_DWORD_LITTLE_ENDIAN, REG_MULTI_SZ, or REG_SZ. The value for REG_DWORD and REG_DWORD_LITTLE_ENDIAN is hexadecimal or decimal. The value of a REG_MULTI_SZ or REG_SZ can be a string value or, numeric or alphanumeric. The value of REG_BINARY can be binary or hexadecimal.

The Value name and Value data are separated by a comparison operator such as =, >. <, <=, >=. You must always use = with a string or with the registry type REG_BINARY. You can use any comparison operator with other registry types

For example, if the registry key name is specified as RegKey with a Value Name of RegValue, a comparison operator of =, and a Value Data of RegData, the client integrity check process looks for the presence of RegKey with a value name RegValue = value data RegData on the client machine. If the registry is present with the specified values, the client passes the client integrity check.

NOTE:Registry keys are not case sensitive, and they can contain either a single backslash (\) or double backslash (\\).

For example: One of the registry key descriptions is HKEY_Local_Machine\\Software\\Symantec. It can also be written as HKEY_Local_Machine\Software\Symantec.

 

Absolute File

Name: Specify the name and absolute path of the file that must be present on the client machine.

Version: Specify the version of the absolute file that must be running on the client machine.

HashMD5: Specify the MD5 checksum value of the absolute file. To calculate the MD5 checksum value of an absolute file located in your local system, click Select File to select the file. The MD5 checksum value of the selected file is displayed.

To calculate the MD5 checksum value for an absolute file that is on another system, remotely connect to that system, calculate the MD5 value, then copy the value in the HasMD5 field.

NOTE:You can also copy the file from the remote system to the local system, then calculate the MD5 checksum by using the Select File option. However, this might change the MD5 value of the file during the process. If you want to use this method, then ensure that the file size and file contents did not change during the process.

 

Service

Name: Specify the display name of the service.

Status: Specify the status of the process in the client machine. The status of the process can be Running or Stopped.

5.1.8 Mutual SSL (X.509) Authentication

Mutual authentication is used when a user is issued an X.509 certificate from a trusted source, and the certificate is then 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.

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 into Identity Server trusted root store.

    For information about how to import trusted roots, see Importing Public Key Certificates (Trusted Roots).

    Identity Server must trust the Certificate authority that created the user certificates.

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

  4. Click New.

  5. Specify a display name, then select X509Class from the drop-down menu.

  6. Click Next.

  7. Configure the validation options:

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

    Access Manager caches CRLs, so the revoked 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, for highest security, select either OCSP-CRL or CRL-OCSP validation. 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 in 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: Disables whether to check if a certificate authority has been revoked. This option checks the 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 enable the root CA revocation check, what Identity Server checks depends upon the certificates that have been added to 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.

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

  9. Configure the browser restart option.

    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, then removes the card and logs out but does not close the browser, the SSL session is still active. If another user has access to the machine, that user can use the existing session.

    To prevent this from happening, select Force browser restart on logout.

  10. Click Next.

  11. Continue with Configuring Attribute Mappings.

Configuring Attribute Mappings

The attribute mapping options allow you to specify how Identity Server maps the certificate to a user in the user store. Subject name is the default map.

  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.

    Show certificate errors: Displays an error page when a certificate error occurs. This option is disabled by default.

    Auto Provision X509: Enables using X.509 authentication for automatic provisioning of users. This option allows you to activate X.509 for increased security, while using a less secure way of authentication, such as username/password. Extra security measures can even include manual intervention to activate X.509 authentication by adding an extra attribute that is checked during authentication.

    An example of using this option is when a user authenticates with an X.509 certificate, a lookup is performed for a matching SASallowableSubjectNames with the name of the user certificate. When no match is found, and Auto Provision X509 is enabled, the user is presented with a custom error page specifying to click a button to provide additional credentials, such as a username and password, or to start an optional Identity Manager workflow. If the authentication is successful, then the user’s SASallowableSubjectNames attribute is filled in with the certificate 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, you need to ensure that the LDAP attribute that is used can store string values with a length 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 64 characters. The authentication works if a valid name and password is given. However, provisioning fails.

    Attributes: The list of attributes currently used for matching. If multiple attributes are specified, the evaluation of these attributes must resolve to only one user in the user store.

    The evaluation 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 available X.509 attributes. To use an attribute, select it and move it to the Attributes list. When the attribute is moved to the Attributes list, you can modify the mapping name in the Attribute Mappings section. The mapped name must match an attribute in your LDAP user store.

    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 in the same list. The issuer name needs to be the first item in the list, with the serial number being the second and last item in 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.)

  3. Click Finish.

  4. Create a method for this class.

    For instructions, see Section 5.1.3, Configuring Authentication Methods.

  5. Create a contract for the method:

    For instructions, see Section 5.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 5.1.11, Password Retrieval.

  6. Update Identity Server.

Setting Up Mutual SSL Authentication

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

  • Authentication and nonrepudiation 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 nonrepudiation of the client, using digital signatures.

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

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

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

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

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

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

  7. Assign the contract to protect resources.

    See Section 3.8.4, Configuring Protected Resources.

  8. Update Access Gateway.

Customizing Certificate Errors

In case of certificate validation failure, 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 procedure:

  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 cliantauth=want in a connector, ensure that the connector also 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. This will result in a prompt being displayed on the browser during authentication.

  4. Export the user and server certificate 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. For details, see Section 30.5.2, Resolving Certificate Import Issues.

Configuring X.509 Authentication to Provide Access Manager Error Message

You can configure the X.509 class property and Identity Server to avoid the browser provided message and display Access Manager error message. This occurs when the SSL mutual handshake fails because of non availability of client certificate.

NOTE: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: To configure you must have a parent domain, for example, https://240onbox.provo.novell.com:8443/nidp/ and sub-domain https://onbox.provo.novell.com:8443/ available. You can also have a different port or IP combination.

To create a sub-domain, perform the following steps:

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

  2. Specify the sub-domain IP address and URL in the hosts file.

Perform the following steps to configure Access Manager specific error messages during X.509 authentication:

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

  2. Open the server.xml file using the vi editor.

  3. Search for <Connector NIDP_Name="connector" and create a copy of the existing connector.

  4. Go to the new connector you created and search for the clientAuth=false string and change it to clientAuth=want and add protocol""org.apache.coyote.http11.Http11Protocol".

  5. Save the server.xml file and exit.

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

  7. 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=".provo.novell.com"> <!-- Disable session persistence across Tomcat restarts --> <Manager pathname="" saveOnRestart="false"/> </Context>

  8. 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: provo.novell.com

      Property Name: CLUSTER COOKIE PATH

      Property Value: /nidp

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

  9. For X.509Class-based redirection, add the property in the X.509 method for X.509 to be redirected to the new connector as follows:

    Property Name: CONNECTOR_HOST Property Value: https://onbox.provo.novell.com:8443

    Here, the DNS name onbox is a sub-domain as indicated in the prerequisite.

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

  10. Restart Tomcat using the following commads.

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

    • Windows: Enter the following commands:

      • net stop Tomcat7

      • net start Tomcat7

Verify the configuration as follows:

Access Identity Server URL in a browser that does not have 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.

5.1.9 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 Section 5.3.2, RADIUS Authentication.

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

    For information about the configuration options, see Section 5.1.8, 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 Section 5.1.8, 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 5.1.3, Configuring Authentication Methods and Section 5.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.

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

    The Java class path is configured automatically.

  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 5.1.3, Configuring Authentication Methods.

  6. Create a contract for the method:

    For instructions, see Section 5.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 5.1.11, Password Retrieval.

  7. Update Identity Server.

5.1.11 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 5.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:

  8. Click Apply and update Identity Server.

5.1.12 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

You need to create a contract that uses the NESCM method. To do this, you need to first create an NMAS class, then a method that uses that class. The last task is to create a contract that uses the method. The following sections describe these tasks:

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 the 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

When you create a method, you can specify property values that are applied to just this method and not the entire class. In this tutorial, we want the method to use the same login sequence as the class. The method also allows you to specify which user stores can use the method. For a smart card method, you need to ensure that the user store or 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 the Available methods list, 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 Section 5.1.11, 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 3.8.4, 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 the Protected Resource link for the proxy service where you want to assign the NESCM contract.

  3. To enable the NESCM contract on an existing protected resource, click the Authentication Procedure link 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 have 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.

5.1.13 Kerberos Authentication

Kerberos is an authentication method that allows users to log in to an Active Directory domain. This authentication method provides them with a token, which an Identity Server can be configured to use 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 lets peers determine which GSSAPI mechanisms are shared and lets 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 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 5-4 Example Kerberos Configuration

Kerberos requires the following configuration tasks:

Prerequisites

Kerberos authentication is supported for the following configuration:

  • Clients must be running one of the following operating systems:

    Windows XP with Internet Explorer 7 or later. Some minimal testing has been done with Internet Explorer 6. To make Kerberos work with Internet Explorer 6, you need to enable integrated Windows authentication. For information about how to enable this feature, see “Authentication Uses NTLM instead of Kerberos”.

    Windows Vista with the latest version of Internet Explorer.

    Windows 7 with Internet Explorer 8 or later. Be aware of the following issues:

    • Internet Explorer needs to have the Internet Options configured to trust the URL of Identity Server.

    • The keytab file must be configured 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 the new procedure, see Configuring the Keytab File.

    For more information about these issues, see TID 7006036.

  • Active Directory must be configured to contain entries for both users and their machines. Active Directory must be running on Windows Server 2003 Enterprise SP2, Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012.

  • 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, the firewall needs to open ports TCP 88 and UDP 88 so that Identity Server can communicate with the KDC on the Active Directory Server.

Configuring Active Directory

You must create a new user in Active Directory for Identity Server, set up this user account to be a service principal, create a keytab file, and add Identity Server to the Forward Lookup Zone. These tasks are described in the following sections:

Installing the spn and the ktpass Utilities for Windows Server 2003

When you install Windows Server 2003 and Active Directory, the spn and ktpass utilities are not installed in a default installation. These utilities are installed in a default Windows Server 2012 installation.

You need the spn and ktpass utilities to configure Identity Server for Kerberos authentication.

  1. Insert the Windows 2003 CD into the CD drive.

  2. To install the utilities, run \SUPPORT\TOOLS\SUPTOOLS.MSI on the CD.

    The utilities are installed in C:\Program Files\Support Tools.

Creating and Configuring the User Account for Identity Server

  1. In Manage Your Server on your Windows server, select the Manage users and computers in Active Directory option.

  2. Select to create a new user.

  3. Fill in the following fields:

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

    User logon name: Specify HTTP/<Identity_Server_Base_URL>. For this example configuration, your Identity Server has a base URL of amser.provo.novell.com, and you would specify the following for the User Logon Name:

    HTTP/amser.provo.novell.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 the example configuration, this is amser.

  4. Click Next, and configure the password and its options:

    Password: Specify a password for this user

    Confirm password: Enter the same password.

    User must change password at next logon: Deselect this option.

    Password never expires: Select this option.

  5. Click Next, then click Finish.

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

  6. To set the servicePrincipalName (spn) attribute for this user, open a command window and enter the following commands:

    setspn -A HTTP/<userLogonName> <userName>

    For this configuration example, you would enter the following command:

    setspn -A HTTP/amser.provo.novell.com@AD.NOVELL.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, you would 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

    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.

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

    ktpass /out nidpkey.keytab /princ HTTP/amser.provo.novell.com@AD.
    NOVELL.COM /mapuser amser@AD.NOVELL.COM /pass novell
  2. Copy the file to the default location on Identity Server:

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

    Windows Server 2012: C:\Program Files (x86)\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 Manage Your Server on your Windows server, click Manage this DNS server.

  2. Click Forward Lookup Zone.

  3. Click the Active Directory domain.

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

  5. Fill in the following fields:

    Name: Specify the hostname of Identity Server.

    IP Address: Specify the IP address of Identity Server.

  6. Click Add Host.

Configuring Identity Server

You need to 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, then restart Tomcat. These instructions assume that you have installed and configured an Identity Server cluster configuration.See Installing Access Manager in the NetIQ Access Manager 4.3 Installation and Upgrade Guide and Section 3.4, Identity Servers Cluster.

Enabling Logging for Kerberos Transactions

Enabling logging is highly recommended. If Kerberos authentication does not function after you have finished the configuration tasks, the first step in solving the problem is to look at the catalina.out (Linux) or the stdout.log (Windows) file.

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

  2. Enable the 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 either configure your 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 your installed user stores.

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

    If you haven’t configured a user store for the Active Directory server, click New.

  4. For a new user store, fill in the following fields. For an existing Active Directory user store, verify the values.

    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. In the Server replicas section, click New.

    1. Fill in the following fields:

      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.

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

    3. Click OK.

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

  7. To save your changes, click OK or Finish.

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

Creating the Authentication Class, Method, and Contract

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

  2. Fill in the following fields:

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

    Java class: Select KerberosClass.

    The Java class path field displays the name of the KerberosClass.

  3. Click Next.

  4. Fill in the following fields:

    Service Principal Name (SPN): Specify the value of the servicePrincipalName attribute of Identity Server user. For this example configuration, this is HTTP/amser.provo.novell.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.NOVELL.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

    Instructions for creating this file are in Creating the bcsLogin Configuration File.

    Kerberos KDC: Specify the IP address of the Key Distribution Center. If multiple KDCs are present for fail-over support, then specify the IP addresses separated by colon (:). Maximum of 4 IP addresses can be configured.

    If a L4 switch is configured for load balancing between the KDCs, then enter 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. Fill in the following fields:

    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 is dependent upon having 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. Fill in the following fields:

    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, you need to make the Active Directory user store the default user store. In the Local page, click Defaults.

    1. Fill in the following fields:

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

      Authentication Contract: Select the name of your Kerberos contract.

    2. 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 Identity Servers page, click Update.

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

  15. If you have Access Gateways or J2EE Agents that you want to configure 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

If you are upgrading from 3.1 SP2 to 3.1 SP3, the syntax of the bcsLogin.conf file has changed.

To create the file:

  1. Open a text editor. A sample bcsLogin.con file called bcsLogin.conf.template is included that can be edited. 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 principle 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.provo.novell.com@AD.NOVELL.COM"
    useKeyTab="true"
    keyTab="/opt/novell/java/jre/lib/security/nidpkey.keytab"
    storeKey="true";
    };

    Identity Server will check 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 keytab file is secure.

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

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

    The path in the ticketCache line must be C:\\Program Files (x86)\\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 correctly. They must be set to 644.

  6. Restart Identity Server:

    • Linux Identity Server: Enter the following command:

      /etc/init.d/novell-idp restart

    • Windows Identity Server: Enter the following commands:

      net stop Tomcat7

      net start Tomcat7

    Whenever you make changes to the bcsLogin.conf file, you need to 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 the stdout.log (Windows) of Identity Server:

  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.provo.novell.com@AD.NOVELL.COM
    Added server's keyKerberos Principal HTTP/amser.provo.novell.com@AD.NOVELL.COMKey Version 3key EncryptionKey: keyType=3 keyBytes (hex dump)=0000: CB 0E 91 FB 7A 4C 64 FE
    
    [Krb5LoginModule] added Krb5Principal HTTP/amser.provo.novell.com@AD.NOVELL.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.provo.novell.com
    KeyTab is /usr/lib/java/jre/lib/security/nidpkey.keytab
  7. (Conditional) If you make any modifications to the configuration, either in Administration Console or to the bcsLogin file, restart Tomcat on Identity Server.

(Optional) Using the Name/Password Form Authentication

You can configure the IP address or the range of IP addresses of the clients for which the 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 at the following locations:

Linux: /var/opt/novell/nids/lib/webapp/WEB-INF/classes

Windows Server 2012: \\Program Files (x86)\\Novell\\Tomcat\\webapps\\nidp\\WEB-INF\\classes

(Optional) Configuring the Fall Back Authentication Class

You can configure an optional authentication class that has to be 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) Using the Name/Password Form Authentication

To configure the fall back authentication class:

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

  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 IDP 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 will use 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

NOTE: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

NOTE:The property name is case-sensitive.

Also, you can configure fall back to other mechanism based on the incoming header. In the kerberos Method, add the name/value in the property field with name as NO_NEGO_HEADER_NAME and in the value filed you can provide the header, which needs to be ignored for the kerberos authentication.

For Example, in the kerberos method properties, if you configure the name as NO_NEGO_HEADER_NAME with value X-NovINet. 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.

Configuring the Clients

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

    For instructions, see your Active Directory documentation.

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

  3. (Conditional) If you are using Internet Explorer, configure the web browser to trust Identity Server:

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

    2. In the Add this website to the zone text box, enter the Base URL for Identity Server, then click Add.

      In the configuration example, this is http://amser.provo.novell.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, configure the Web browser to trust Identity Server:

    1. In the URL field, specify about:config.

    2. In the Filter field, 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, you would add http://amser.provo.novell.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, you would add http://amser.provo.novell.com to the list.

    5. Click OK, then restart your Firefox browser.

  5. In the URL field, enter the base URL of Identity Server with port and application. For this example configuration:

    http://amser.provo.novell.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, either in Administration Console or to the bcsLogin file, restart Tomcat on Identity Server.

  6. (Conditional) If you have users who are outside the firewall, they cannot use Kerberos. SPNEGO defaults first to 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 have set up a Web server that you want to require Kerberos authentication for access, you can set up a protected resource for this Web server as you would for any other Web server, and select the name of your Kerberos contract for the authentication procedure. For instructions, see Section 3.8.4, 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 5.1.11, Password Retrieval.

5.1.14 Managing Direct Access to Identity Server

Users usually log into Identity Server when they request access to a Web resource. Access Gateway redirects users from the resource to Identity Server to provide the required credentials for the resource. After they are authenticated, they are not prompted for credentials again, unless a resource requires credentials that they haven’t already supplied.

Users can log directly into Identity Server and access either the default user portal or the legacy user portal. Alternatively, they can access information about the available Web Services Description Language (WSDL) services.

Logging in to the Default User Portal

Access Manager 4.2 default user portal page is the user portal page that contains appmarks. This is a different portal page than for prior release. For more information, see Access Manager 4.3 Release Notes.

User log directly in to Identity Server through the default user portal page when they access the following URL:

https://NAM-Base-URL:8443/nidp/portal

IMPORTANT:The Access Manager domain name for the IDP must be resolvable through DNS or the hosts file on the IDP.

You can customize the default user portal page through Branding in Administration Console. For more information, see Section 7.8, Changing the Branding of the User Portal Page.

Logging in with the Legacy Customized Portal

If you have customized the legacy user portal page, and want to keep the customized pages, you must perform some manual steps. For more information, see Maintaining Customized JSP Files for Identity Server.

Managing Authentication Cards

The default user portal page prompts the user to authentication with the credentials required for the default contract. When users log directly into Identity Server, the users must use the default card for authentications. The menu in the top left corner displays all available cards, when the users click the menu.

On a newly installed system, the menu displays cards for all the authentication contracts that are installed with the system. To avoid confusing your users, you need to disable the Show Card option for the contracts you do not want your users to use. Also, ensure that you modify the default contract to match a card that Administration Console displays.

If you display multiple cards, users can use different credentials to authenticate multiple times by selecting another authentication card and entering the required credentials. This is only useful if the credentials grant the user different roles or authorize access to different resources.

If you have configured Identity Server to be a service provider and have established a trusted relationship with one or more identity providers, the cards of these trusted identity providers appear in the menu under REMOTE LOGINS, Your users can use the identity provider’s authentication card to federate their account at the identity provider with their account at the service provider. When they federate an account, they are telling the service provider to trust the authentication established at the identity provider. This enables single sign-on between the providers. The card can also be used to defederate the accounts. On the authentication card, click Defederate.

If you have configured Identity Server to be an identity provider for service providers, in the menu in the upper right corner of the user portal page contains a Federations options that displays a Federations page. From this page, users can federate and deferated their accounts with trusted service providers.

To edit the default contracts:

  1. Log in to Administration Console.

  2. Click Devices > Identity Servers > Edit > Local > Contracts > Name of Contract > Authentication Card.

  3. Unselect the Show Card option, then click OK to save the change.

  4. On the Local page for the Identity Service, click Defaults.

  5. Modify the contract to match the cards that Administration Console displays.

  6. Click OK to save the changes.

Specifying a Target

You can specify a target for the new and legacy user portal pages. You must specify a target for the following conditions:

  • You want to direct the users to a specific URL after the users log in to Identity Server.

  • You do not want users to have access to the user portal page.

Use one of the following methods to specify the target:

  • Specify a Target in the URL: You can have your users access Identity Server with a URL that contains the desired target. For example: https://domain.com:8443/nidp/app?target=http://www.acme.com

    where domain.com is the DNS name of your Identity Server. In this example, the users would see the Acme Web site after logging in.

  • Specify a Hidden Target on your Form: If you have your own login form to collect credentials and are posting these credentials to Identity Server, you can add a hidden target to your login form. When authentication succeeds, Access Manager directs the user to this target URL. This entry on your form should look similar to the following:

    <input type="hidden" target="http://www.acme.com">

    These methods work only when the user’s request is for the user portal (/nidp/portal or /nidp/app). If the user’s request is a redirected authentication request for a protected resource, the protected resource is the target and cannot be changed.

Blocking Access to the User Portal Page

This information is for the legacy user portal page only. You cannot block the default user portal page.

If a user is already authenticated and accesses Identity Server, the user is presented with Identity Server user portal page.

This page provides information about the logged-in user:

  • Any federations this user has established with third-party service providers

  • Identity attributes such as Liberty Personal or employee profile attributes, Access Manager credential, or custom profile attributes

  • Policy attributes that users or administrators have selected to share with other service providers

You might want to prevent users from seeing this page for the following reasons:

  • Security: Users accessing this page have access to sensitive information that administrators might want to restrict such as the user’s attributes and federations with other third-party SAML or Liberty providers.

  • Help Desk Support: Most users have no need to access the information presented in this page. As a result, they might be confused if they see it. By preventing access to the page, any potential calls into the help desk are avoided.

When you enable the legacy, mode. all end user login pages use the legacy UI. However, there are several places where Access Manager issues the URL/nidp and shows the portal page. This is because in the index.html file for the nidp webapp there is a redirect from /nidp to /nidp/portal.

To block the legacy user portal page:

  1. Ensure that you create the WEB-INF/legacy directory. For more information, see Logging in with the Legacy Customized Portal.

  2. As a system administrator, edit the /webapp/index.html file.

  3. Change the line:

    <meta http-equiv="refresh" content="0; URL=portal">

    to:

    <meta http-equiv="refresh" content="0; URL=app">
  4. Save the /webapp/index.html file.

After this change takes place, the only way to access the legacy user portal page is to enter the URL in the browser of /nidp/portal.

Blocking Access to the WSDL Services Page

Users can access the WSDL services page when they enter the base URL of Identity Server in their browsers with the path to the Services page. For example, if your base URL is http://bfrei.provo.novell.com:8080/nidp, the users can access the services page by using http://bfrei.provo.novell.com:8080/nidp/services.

The Services page contains the following information and links:

Figure 5-5 WSDL Services Page

The amount of information displayed on this page depends upon the profiles you have enabled. To enable profiles, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

If you do not want your users to have access to this page, you can block access.

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

  2. Click New. Specify the following details:

    Property Type

    Property value

    Select WSF SERVICES LIST.

    Select full to enable users to access the Services page.

    Select 404 to return an HTTP 404 status code: Not Found

    Select 403 to return an HTTP 403 status code: Forbidden

    Select empty to return an empty services list

  3. Restart Tomcat for your modifications to take effect:

    Linux: Enter one of the following commands:

    /etc/init.d/novell-idp restart

    rcnovell-idp restart

    Windows: Enter the following commands:

    net stop Tomcat7

    net start Tomcat7