How to Integrate NetIQ Access Manager with Google Authenticator for two-factor authentication

Download googleAuthenticator-coolsolution_v06


Many organizations need or desire to implement a multi-factor authentication scheme to satisfy regulatory requirements or increase security. There are several commercial 2-factor solutions on the market that can be integrated with NetIQ Access Manager (NAM) but this cool solution shows you how you can use the Google Authenticator One-Time Password (OTP) as a second authentication factor with your NAM implementation through a NAM authentication contract. Included is a sample NAM authentication class that you can use or enhance and integration/configuration instructions for integration with NAM providing the OTP "something you have" second factor to compliment the "something you know" user ID and password factor.

Google Authenticator is a standards based open source project published by Google based on the HMAC-Based One-time Password (HOTP) algorithm specified in RFC 4226 and the Time-based One-time Password (TOTP) algorithm specified in RFC 6238. Implementations include several one-time passcode generators for several platforms including:

  • Blackberry

  • Pluggable Authentication Module (PAM)

Links to the apps for these platforms is available from Google Authenticator Project home page.

One-time passcodes are generated using open standards developed by the Initiative for Open Authentication (OATH) (unrelated to OAuth). The Google Authenticator provides a six digit number that users must provide in addition to their username and password to log into NAM protected services. Several SaaS providers have adopted Google Authenticator for a second factor of authentication, now you too can use this feature for your NAM protected applications.

Setup Details

NetIQ Access Manager Identity Server setup details

  1. Download and copy the jar files, which has custom authentication class and dependent library jar files to folder to your NAM 3.2.x Identity Server(s) /opt/novell/nam/idp/webapps/nidp/WEB-INF/lib

  • Move existing commons-codec-1.3 to different backup folder and copy commons-codec-1.8.jar file in extractedfolder/lib to lib of above path.

  • Download and copy the sample jsp pages to /opt/novell/nam/idp/webapps/nidp/jsp

  • Modify web.xml (/opt/novell/nam/idp/webapps/nidp/WEB-INF/web.xml) to allow public access to gauthRegistration.jsp

    <display-name>NIDP Jsp Filter</display-name>
    <description>The NIDP server JSP filter. Enforces authentication and handles clustering.</description>
    <param-value>gauthRegistration.jsp </param-value>

  • Restart IDP

  • As you would add any new authentication scheme to NAM, use the NAM Admin Console to define a new authentication Class, Method, and Contract on your Identity Server / Cluster. First define the Google Authenticator Class under the “Local” tab select Classes and click New to add your Google Authenticator Class.


  • Specify the logical name for your class eg. Googleauthenticator below and from the drop-down list select the “java class” parameter as Other and enter the ”java class path” as com.netiq.custom.GoogleAuthenticatorClass


  • Before hitting Apply or OK, add a property to the class which defines where the link between the Google Authenticator and NAM authenticated user will be stored.

    Note: Each user must register their Google Authenticator so that it is uniquely associated with their NAM user store account. This Cool Solution includes Three sample classes, eDirectory user attribute approach implementation class, a file based class and a memory based class.

    Download googleAuthenticator-coolsolution_v06 ->

    eDirectory (any ldap store) user store based approach registration key is stored to one of the attribute of the user in ldap store. Value is encrypted with password Which is defined in edir implementation class file.

    The file based option writes the link to a file on the Identity Server file system; the memory based option writes the link into memory and is therefore lost every time the Identity Server is restarted. Either the file or memory approach are adequate for a single node Identity Server environment. For a multi-server cluster NAM implementation, user store is one choice where this information can be stored in a schema extension on each user object or one of the existing ldap attribute.

    For additional user store types other than edir refer to the section below (How to implement custom Secret Store) gives the key APIs required to do this.

    To use one of the supplied examples, click the Properties tab and add a New property that defines the secret store connector class where each user’s secret seed is stored. Use SECRET_STORE_CLASS as the property Name and,

    1. For the LDAP user attribute use as the property value. Add ldap attribute name as follows, SECRET_LDAP_ATTRIBUTE_NAME as name and value as <ldap attribute name>> if ldap attribute parameter missing default “carLicence” attribute will be used for demo purpose with edir userstore. When complete, click Apply. NOTE: This class had issue of encrypting the secret, please use the patch archive to use different class. Instructions are below under section “New class for user attribute store”

  • for the file based sample use as the property Value

  • for the memory store sample use as the property Value.


  1. The file store class writes to the /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/gauthkeys file. This file must be created manually where the owner must be novlwww (run ‘chown novlwww:novlwww /opt/novell/nam/idp/webapps/nidp/WEB-INF/classes/gauthkeys at console). Restart the Identity Server when done.

  • In memory store GAuthStoreImpl class writes to HashMap in memory. As mentioned above, this information is not persistent and will be lost with a restart of the Identity Server.


  • Your NAM authentication class is now defined. Next, define a NAM Identity Server Method using the custom Google Authenticator Class just created and uncheck checkbox identifies user as shown below. When complete, click Apply.


  • Your NAM authentication Class and Method are complete. The last Identity Server configuration task is to add the Google Authenticator Method just defined to an existing NAM Authentication Contract as the second factor. For example, you can use the NAM default “Name/Password – From” contract as the second method as shown below. When complete, click Apply.

  • Apply changes on IDP and update IDP server

Testing the configuration:

  1. Access NetIQ Identity Server page http(s)://<<idp server >>:<<port>>/nidp or protected resource

  • Select the contract where google authenticator is configured as second method to be executed for two factor authentication.

  • Do login with first method, here name password form for example, provide login credentials username/password and submit


  • After successfully authenticating with the first factor (LDAP User Store Username and Password), the user is prompted for their Google Authenticator OTP:

  • If the user has already registered for Google Authenticator, the user can enter the OTP value generated by their app and enter the 6-digit result here. Upon successful validation of the token, by the NAM Identity Server the user is authenticated and session is established directing the user to the requested resource; in this example the NAM NIDP page depicted below:


  • If the user is registered but token validation fails (e.g. miss-typed entry) an “Invalid Token” error message is displayed:

  • If the user is NOT registered or does not have a token and randomly enters and submits a value, a message is displayed indicating the user is not registered and the user is provided a link to register for two factor authentication.


  • When a user clicks the link for registering for two factor authentication, a unique secret key is generated and QR code also displayed so the user can scan the code with the google authenticator client on mobile. Or the user can manually register the client/device by entering the secret code displayed in google authenticator mobile client.


  • Once registration is complete on the mobile google authenticator application, the token will be shown for this account.

  • Enter the above token and submit the form again.

  • User will be authenticated.

How to implement custom Secret Store?

This cool solution provides three approaches (eDir user attribute, file and memory stores) to save the google authenticator registration Key value between googleauthenticator and the Identity user store users. The following info provides an approach where we can write the information to any store.

  1. Configure required connect parameters as name value pair at class properties in Admin Console UI while defining google authenticator class.

  • Implement GAuthStore interface defined in


    import java.util.List;
    import java.util.Properties;

    * @author chandu
    public interface GAuthStore {

    public void writeToStore(String userName, String secret, List<Object> addlParams) throws Exception;
    public String readSecretFromStore(String userName, List<Object> addlParams) throws Exception;
    public void init(Properties prop);


  • Class properties are sent to init method

  • writeToStore method is writing to store

  • readSecretFromStore method is for reading secret per user

  • Define a parameter SECRET_STORE_CLASS with value as new class at class properties at Admin Console UI

  • Apply changes and update IDP configuration.

Security concerns with registration page

The registration page has access to sensitive user data. The Session parameter is set by token validation class, as the user goes through the registration stage. However, once the registration is complete and the token has been submitted, the session parameter is removed. Hence Registration page is not accessible for the user.

If user access registration jsp file directly, following message will be displayed.


Suggested enhancements:

  1. Expire the registration page after some time by closing the browser or auto submit to server.

  • If the user is not registered identify this automatically after the first factor authentication and display the registration page (depends on your use case; not showing this information is often considered a more secure choice). Consider displaying a message on the initial Google Authenticator login page to provide additional information/instructions/links to the user like “any difficulty please contact administrator”. This can be done by modifying sample gtoken.jsp file.

New class for user attribute store:

This is a new class can be used to store the secret seed for two factor authentication in user profile attribute at Edirectory / Active directory. Configuration steps are as follows:

  1. Copy the java binary classes (com folder) from <google authenticator extracted folder>/bin to /opt/novell/nam/idp/webapps/WEB-INF/classes

  • Restart IDP

  • Under NAM authentication classes, Google authenticator class add the following properties


  • SECRET_LDAP_ATTRIBUTE_NAME = << ldap attribute name>>

    Note: above property of ldap attribute name is not provided default “carLicense” attribute will be tried to used.

  • Apply and update IDP

  • Screen shot for reference:


Google Authenticator downloads for mobile:

  1. Wiki:


How To-Best Practice
Comment List
Parents Comment Children
No Data
Related Discussions