This section discusses the following advanced authentication techniques that are currently supported by Access Manager:
This section explains how to use Time-Based One-Time Password (TOTP) as a second authentication factor with Access Manager. TOTP uses a six-digit number (OTP) in addition to first authentication (for example: username, password) to log in to protected services.
The first step is to register the TOTP client with the secret key. This secret key is used for all future login to the website.
Typically, users download and install the TOTP app on their devices. To log in to a website or service that uses two-factor authentication, in addition to the user name and password, the users enter an OTP generated by the TOTP app. Access Manager validates the OTP and authenticates the user.
Two-factor authentication such as TOTP provides additional security for the systems. It works on the principle of granting access based on a knowledge factor (something the user has) and a possession factor (something the user knows). This helps organizations to implement a multi-factor authentication scheme to satisfy regulatory requirements or increase security.
Download and install the TOTP app on your device. This app generates an OTP that is later used for authentication.
TOTP relies on the device time to generate an OTP. So, it is important that the time on your device is accurate.
Log in to Administration Console.
Click Devices > Identity Servers > Edit > Local > Classes > New to add a new class.
Specify a name to identify the class.
Select TOTPClass from the Java Class option. The Java class path is displayed as com.novell.nidp.authentication.local.TOTPAuthenticationClass.
Click Apply. By default, the TOTP class stores the secret key in the Shared Secret store and no further configuration is required.
[Optional] You can also store the secret key in an LDAP attribute, file, or memory. Perform the following steps:
NOTE:File and Memory class implementation are not recommended for production deployment and are only suitable for a single node Identity Server test environment.
LDAP user attribute: This option stores the secret key on an LDAP attribute of the user object in the user store.
Select the Properties tab of the TOTP class configuration. Add a new property to indicate that the secret key must be stored in an LDAP attribute of the user object in the user store.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as USERSTORE.
Add another property to indicate the attribute in which the secret key must be stored.
Specify the Property Name as SECRET_LDAP_ATTRIBUTE_NAME and specify the name of any single-valued attribute. For example, you can specify the Property Value as mobile, costcentre etc.
The secret key is encrypted and stored in the LDAP attribute. If you do not specify any Property Value, the secret key is stored in the carLicense LDAP attribute.
NOTE:Do not use a multi-valued LDAP attribute like email address as the Property Value as the user registration will fail. It is also important to ensure that the LDAP attribute you have specified as the Property Value is a non-operational attribute. For example, it is not recommended to use LDAP Attributes like groupmembership.
File class: The File class writes the secret key to a file on Identity Server file system.
Select the Properties tab of the TOTP class configuration and add a new property to have the user's secret key stored in a file on the file system.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as FILE.
Memory class: The Memory based class writes the secret key into memory. This memory is transient in nature and therefore the secret key value is lost each time Identity Server is restarted.
Select the Properties tab of the TOTP class configuration and add a new property to define the memory-based property where each user’s secret key is stored.
Specify the Property Name as SECRET_STORE_CLASS and Property Value as MEMORY.
Click Devices > Identity Servers > Edit > Local > Methods. Select New to add a new method.
Specify a name to identify the method. Select the TOTP class from the list. This links the TOTP class to the authentication method.
Deselect the Identifies User option. Click Apply to save the changes.
Select the user store from the list of Available user stores and move it to User store.
You can either use an existing authentication contract or create a new authentication contract. For example, you can add the default Name/Password – Form method as the first method and TOTP method as the second method. Click Apply to save the changes.
NOTE:If you use TOTP as a post-authentication method in a federation setup, a JSP file not found message is displayed and federation fails.
Go to Access Manager Identity Server page http(s)://<idp server >:<port>/nidp
Select the contract where TOTP is configured as the second method for two-factor authentication.
Login with the first method.
Click the link beside Please register for two factor authentication to generate a OTP. Make a note of the secret key displayed.
If you have installed the TOTP client on your device, scan the code. You can also manually enter the secret key in the TOTP mobile client.
After the registration is complete on the TOTP client on your mobile, the OTP is displayed.
Go to Access Manager Identity Server page: http(s)://<idp server >:<port>/nidp
Select the contract where TOTP is configured as the second method for two-factor authentication.
Login with the first method.
After successfully authenticating with the username and password, prompt is displayed to enter the TOTP OTP.
Use the TOTP app to generate the OTP and log in by using this OTP.
RADIUS enables communication between remote access servers and a central server. Secure token authentication through RADIUS is possible because Access Manager works with Novell Modular Authentication Service (NMAS) RADIUS software. Access Manager supports both PIN and challenge-and-response methods of token-based authentication. In other words, RADIUS represents token-based authentication methods used to authenticate a user, based on something the user possesses (for example, a token card). Token challenge-response is supported for two-step processes that are necessary to authenticate a user.
Click Devices > Identity Server > Edit > Local > Classes.
Click New.
Specify a display name, then select RadiusClass or ProtectedRadiusClass from the drop-down menu.
Click Next.
Click New to add an IP address for the RADIUS server. You can add additional servers for failover purposes.
Click OK.
Fill in the following fields:
Port: The port of the RADIUS server.
Shared Secret: The RADIUS shared secret.
Reply Time: The total time to wait for a reply in milliseconds
Resend Time: The time to wait in milliseconds between requests.
Server Failure Retry: The time in milliseconds that must elapse before a failed server is retried.
JSP: Specify the name of the login page if you want to use something other than the default page. The filename must be specified without the JSP extension. The default page is used if nothing is specified.
User Look Attribute Name: Specify the LDAP attribute on which the user will be searched in the Radius server. CN is the default attribute.
Require Password: Select to require the user to also specify an LDAP password.
Click Finish.
Create a method for this class.
For instructions, see Section 5.1.3, Configuring Authentication Methods.
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 and you did not enable the Require Password option, 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.
Update Identity Server.
NetIQ Advanced Authentication Access Manager plug-in now comes bundled with Access Manager. Using Advanced Authentication methods, you can configure multi-factor authentication with Access Manager.
The following are supported Advanced Authentication classes:
Dynamic Class: This authenticating class sends a list of chains from which the user can select a chain and authenticate. Only the chains which are enrolled in the Advanced Authentication portal will be available to the user for authentication.
NOTE:Fingerprint and PKI methods can be configured using Dynamic Class only. There are no separate classes for Fingerprint and PKI methods.
Email Class: This authentication class sends an email to user’s registered email address with an OTP that is valid for a specified time. You can use this OTP to authenticate within a certain time frame.
Emergency Password Class: This authentication class authenticates users with a temporary password.
FIDO U2F Class: This authentication class authenticates users with the help of a U2F security key.
IMPORTANT:FIDO U2F will not work if enrollment and authentication are performed on different domain names. With Access Manager and Advanced Authentication, you will certainly have two domain names, one for Identity server and another for Advanced Authentication server. To workaround this you should proxy the Identity server and Advanced Authentication server under the same domain name. Perform the following steps to configure FIDO U2F class:
Create a path-based, multi-homing proxy service with Advanced Authentication server as the web server. Create five paths under the proxy service with the URL paths as follows:
/account, /admin, /api, /auth, and /static
The published DNS name must be identical to the Identity Server domain name.
Create another path-based, multi-homing proxy service with Identity server as the web server and Advanced Authentication server as the parent server. Create a path under the proxy service with the URL path as follows:
/nidp
Configure a protected resource to the proxy services with URL paths as /account/*, /admin/*, /api/*, /auth/* and /static/* and Advanced Authentication server as the web server. You do not need to associate the protected resource with any contract. Configure another protected resource to the proxy service with URL path as /nidp/* and Identity server as the web server.
For more information, see Configuring FIDO U2F class.
Fingerprint Class: This authentication class authenticates using a fingerprint scanner.
HOTP Class: This authentication class is an event-based OTP authentication. There is no time frame for a HOTP.
Password (PIN) Class: This authentication class stores a password in the Advanced Authentication appliance - that is not connected to your corporate directory. This can be a PIN or a simple password.
RADIUS Class: This authentication class forwards user’s authentication request to a third-party Radius server.
Security Question Class: This authentication class allows users to enroll answers to an administrator-defined number of security questions. When you authenticate by using security questions, Advanced Authentication asks you all the security questions or a subset of the security questions.
Smartcard Class: This authentication class allows users to authenticate by using a smart card.
Smartphone Class: This authentication class allows you to authenticate by using a smartphone.
SMS Class: This authentication class sends an SMS to user’s registered mobile number, containing OTP. User can use this OTP to authenticate within a certain time frame.
TOTP Class: This authentication class is a time-based OTP authentication. This method uses a predefined time step, which is set to 30 seconds by default.
Voice Call Class: This authentication class makes a phone call on user’s registered mobile requesting to provide a pre-defined PIN.
In addition to the existing classes, Access Manager also supports the following optional properties (KEY/Value) for authentication methods:
Repository Name: REPONAME. The name of the repository used for Advanced Authentication. This parameter may not be used if the default repository is selected in the Login options policy of Advanced Authentication server appliance.
Configuration File: CONFIGFILE. The name of the configuration file path. This parameter is used only if the configuration file has a different location. The default configuration file location is: /etc/aaplugin/config.xml.
Timeout Value: RECHECKTIMEOUT. The time out parameter that is used to prevent loops. The default value is 300 seconds. The following are minimum recommended values:
Email: 120 seconds
FIDO U2F: 30 seconds
HOTP: 30 seconds
RADIUS: 30 seconds
Security Question: 30 seconds
Smartcard: 30 seconds
Smartphone: 60 seconds
SMS: 30 seconds
TOTP: 30 seconds
Voice Call: 30-60 seconds
Error Info JSP Page: ERRORJSP. The name of the JSP page that stores the error logs. This is for critical errors and failures related to the authentication process. The default file is PluginErrorPage.jsp. The file is located at:
Linux: /opt/novell/nids/lib/webapp/jsp
Windows: $INSTALL_PATH\Tomcat\webapps\nidp\jsp
LDAP Authentication Page: LDAPJSP. The name of the LDAP authentication page. This parameter is used for customization. It allows you to customize the LDAP login page for each method. The default file is LdapAuth.jsp, The file is located at:
Linux: /opt/novell/nids/lib/webapp/jsp
Windows: $INSTALL_PATH\Tomcat\webapps\nidp\jsp
Method Page: METHODJSP: The name of the method page. This parameter is used for customization. It allows you to customize the Method page for each method. The default file is <MethodName>Auth.jsp. The file is located at:
Linux: /opt/novell/nids/lib/webapp/jsp
Windows: $INSTALL_PATH\Tomcat\webapps\nidp\jsp
LDAP Password Sync Page: LDAPSYNCJSP. The name of the LDAP password synchronization page. The default file is LDAPSyncPage.jsp. The file is located at:
Linux: /opt/novell/nids/lib/webapp/jsp
Windows: $INSTALL_PATH\Tomcat\webapps\nidp\jsp
Max Password Length: PWDMAXLENGTH. This parameter restricts the maximum length of a password. The default value is 100 characters. This parameter can be used only for YubiKey tokens (FIDO U2F class)
Advanced Authentication Enrollment URL: ENROLLURL. This parameter contains the URL of the Advanced Authentication Self-Service Portal. The default value is https://<NetIQAdvancedAuthenticationFramework_server_address>:<server_port>/account.
DEBUG: This parameter gathers additional information from a log file. It adds data from the server requests and server responses to the log file. To enable debug logging, set the value to 1.
LOGFILE: This parameter contains the path of the plug-in log file. It allows you to save the log file in a different location. For example, specify the file path /tmp/NAMAAplugin.log in the value field.
The following list includes prerequisites required for using NetIQ Advanced Authentication:
NOTE:The following list is applicable only on a fresh installation of Access Manager 4.3. If you upgrade Access Manager to 4.3, you can skip the first two points.
You must first configure Advanced Authentication Server 5.3 or above. To configure the server, see Advanced Authentication Server Appliance Deployment.
After configuring the server, end users must enroll to Advanced Authentication Self-Service portal. To enroll, see Authentication Methods Enrollment.
Specify the server details. See Section 3.5.9, Specifying Advanced Authentication Server Details.
To configure Advanced Authentication, perform the following steps:
Click Devices > Identity Servers > Edit > Local > Classes.
Select New and specify a name to identify the class.
Select a class under Advanced Authentication from the Java Class drop-down list.
Click Next > OK > Finish.
Create a method for this class. You can create a method by using one of the following options:
Identifies User: Adds only a desired Advanced Authentication method from the available list. Selects Identifies User.
For example: If the Email contract is configured to use only the Email method, you must configure both Password & Email (two-factor) and Email (one-factor) chains in the Chains section (the two-factor chain must be higher than an appropriate one-factor chain). Enable them in the Access Manager event of the Advanced Authentication Administrative Portal.
Identifies User: Adds any standard method as a first-factor from the available list and a desired Advanced Authentication method as the second-factor.
For example: If Email contract is configured to use as a combination of a standard method and an Email method, you must configure and enable only Email (one-factor) chain.
For more information, see Section 5.1.3, Configuring Authentication Methods.
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 and you did not select Require Password, 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.
Update Identity Server.