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.
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.
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:
Click Devices > Identity Server > Edit > Local > Classes.
Click New to launch the Create Authentication Class Wizard.
Specify a display name, then select a class from the Java class list.
The following classes are recommended only for testing purposes:
BasicClass: Uses basic HTTP authentication.
PasswordClass: Passes the user name and password over HTTP in readable text, and uses a form-based login to collect the name and password.
RadiusClass: RADIUS enables communication between remote access servers and a central server. For a production environment, use ProtectedRadiusClass.
For a production environment, select one of the following protected classes:
X509Class: Certificate-based authentication. See Mutual SSL (X.509) Authentication.
SocialAuthClass: The authentication class used for implementing authentication through external OAuth providers such as Facebook, GooglePlus, LinkedIn and Twitter. See Section 4.4, Social Authentication.
TOTPClass: The authentication class used for implementing two-factor authentication. See Two-Factor Authentication Using Time-Based One-Time Password.
Risk-based Auth Class: The authentication class used for assessing the risk after authentication. See Risk-based Authentication.
Risk-based Pre-Auth Class: The authentication class used for assessing the risk before authentication. See Risk-based Authentication.
ProtectedBasicClass: BasicClass protected by HTTPS.
ProtectedPasswordClass: PasswordClass protected by HTTPS (form-based).
ProtectedRadiusClass: RadiusClass protected by HTTPS. See RADIUS Authentication for configuration steps.
KerberosClass: The authentication class used for using Kerberos for Active Directory and Identity Server authentication. See Kerberos Authentication for configuration steps.
NMASAuthClass: The authentication class used for Novell Modular Authentication Services (NMAS). It uses fingerprint and other technology to authenticate a user. For information about using the NMAS NESCM method, see Configuring Access Manager for NESCM.
NPOrRadiusOrX509Class: The authentication class that allows the creation of a contract from which the user can select an authentication method: name/password, RADIUS, or X.509. For configuration information, see ORed Credential Class.
PasswordFetchClass: The authentication class that allows Identity Server to retrieve the user’s password when the user has used a non-password class for authentication. For configuration information, see Section 4.1.10, Password Retrieval.
PersistentAuthClass: The authentication class that allows for persistent logins, long authentication sessions, or remember my password functionality. For configuration information, see Section 4.1.6, Persistent Authentication.
IDP Select Class: The authentication class that allows the user to authenticate with the desired external IDP and provides an option to remember the user choice. For configuration information, see Configuring IDP Select Class.
Other: Used for third-party authentication classes or if you have written your own Java class. For information about how to write your own class, see Access Manager Developer Resources.
AliasUserPasswordClass: This class supports authentication of a user against user's alias name. This class uses the alias object of the user object and the password of the corresponding user object to authenticate.
Advanced Authentication: The authentication classes that support Advanced Authentication (for example, Email OTP, FIDO U2F). For configuration information, see Section 2.3.9, Configuring Advanced Authentication Server.
IMPORTANT:To enable CSRF check, perform the steps mentioned in LOGIN CSRF CHECK and add a property AntiCSRFCheck=true to the class. You do not need to add this property to Password Class and TOTP Class.
NOTE:You cannot enable CSRF check for Advanced Authentication class and Social Authentication class.
Click Next to configure the properties for each class. Click New, then enter a name and value. The names and values are case-sensitive. See Specifying Common Class Properties for the properties that are used by the basic and password classes.
Click Finish.
Continue with Section 4.1.3, Configuring Authentication Methods.
To use an authentication class, the class must have one or more associated methods.
Both basic and password classes can use Query Property, JASP Property, and MainJSP Property. You can also specify these properties on a method derived from the class.
If you are planning to create multiple methods from the same class, consider the following conditions:
If you want the methods to share the same properties, you can save configuration steps by defining the properties on the class.
If you want the methods to use different values for the properties such as one method specifying one custom login page and another method specifying a different custom login page, then you must specify the properties on the method.
This section includes the following topics:
Typically, Identity Server uses the username to find a user in the user store. You can change this behavior by using the Query property. This property determines the username value for authentication. The default Query string prompts the users for the value of the CN attribute. You can modify this by requesting a different attribute in the LDAP query.
The Query property can be used by the following classes:
BasicClass
PasswordClass
ProtectedBasicClass
ProtectedPasswordClass
For example, to query for the user’s UID attribute to use for the username, you would specify the following query:
Property Name: Query
Property Value: (&(objectclass=person)(uid=%Ecom_User_ID%))
The values are case sensitive. The name of the property must be Query with an initial capital. The %Ecom_User_ID% variable is used in the default login.jsp for the username in the four classes that support the Query property. The variable is replaced with the value the user enters for his or her username, and the LDAP query is sent to the user store to see if the user’s attribute value matches the entered value. You can specify any attribute for the Query that is defined in your user store for the object class of person and that is used to identify the user.
The Query you define for the BasicClass and the ProtectedBasicClass needs to use an attribute that your users define as their username. The PasswordClass and the ProtectedPasswordClass do not have this requirement. They also support the JSP property, which allows you to specify a custom login.jsp and have it prompt for other attributes that can be used for login.
For example, you can define the following Query to prompt the users for their email address rather than their username.
Property Name: Query
Property Value: (&(objectclass=person)(email=%EMail Value%))
The %EMail Value% must match the variable in the custom login page that is filled in when the users enter their credentials. The objectclass value must be a valid object class in the LDAP user store. The email attribute must be a valid attribute of the person class.
When you specify such a Query, you must also modify the login page to prompt the user for the correct information. Instead of prompting the user for a username, the login form must prompt the user for an e-mail address. The JSP Property allows you to specify a custom login page. For information about creating a custom login page, see Customizing the Identity Server Login Page.
The JSP property allows you to specify a custom login page. This property can be used with the following classes:
PasswordClass
ProtectedPasswordClass
The property name is JSP and the property value is the filename of the login page you customized without the .jsp extension of the file. The property value cannot contain nidp in its name.
For example, if you created a custom file named emaillogin.jsp,you would specify the following values. The values are case sensitive. The property name needs to be entered as all capitals.
Property Name: JSP
Property Value: emaillogin
If you use two methods to create a contract, this property must be set to the same value on both or set on only one. When it is set on only one method, the value is applied to both. This property needs to be used with the MainJSP Property. For information about how to create a custom login page, see Customizing the Identity Server Login Page.
When the MainJSP property is set to true, it indicates that you want to use the page specified in the JSP property for the login page. When this property is set to false, which is the default value, the nidp.jsp is used for the login page. If you use two methods to create a contract, this property must be set to the same value on both or set on only one. When it is set on only one method, the value is applied to both.
Property Name: MainJSP
Property Value: true
For more information about a custom login page, see Customizing the Identity Server Login Page.
reCAPTCHA helps you to protect your user login page against spam, malicious registrations, and other forms of attack where bots or malicious software pretend as humans to access your computer. reCAPTCHA can help you secure Access Manager against attacks such as denial-of-service (DoS) and brute-force, which can impact the system performance to a large extent.
reCAPTCHA provides an additional layer of security by requesting users to confirm that they are not a robot. It displays images that users must select based on a matching criteria. If a response succeeds, Access Manager authenticates the user’s authentication credentials. If a response fails, Access Manager does not authenticate the user credentials, and redirects to the login page. Software bots typically cannot scan the images to provide a response.
Access Manager supports only the latest invisible reCAPTCHA. For more information, see Google developer guide for reCAPTCHA.
reCAPTCHA works on both Name/Password – Form and Secure Name/Password – Form authentication.
The following sections provide information about configuring reCAPTCHA:
Ensure that you meet the following prerequisites before configuring the reCAPTCHA:
Active Directory, eDirectory, or both identity sources are configured.
reCAPTCHA supports Active Directory and eDirectory. It does not support other types of identity sources, such as Microsoft SQL Server or Oracle Database type identity sources that use the JDBC identity source connector.
Each identity source is configured with an intrusion detection policy. See Configuring Intrusion Detection for Failed Logins
A Google reCAPTCHA account is available. See Setting Up a reCAPTCHA Account.
Anyone who attempts to use more than a few unsuccessful passwords while trying to log on to the system might be a malicious user. reCAPTCHA cannot prevent attacks by malicious users who can read the image. It cannot differentiate between malicious users and legitimate users. reCAPTCHA cannot prevent coordinated human DoS attacks.
To prevent brute-force or human attacks that bypass the reCAPTCHA protection, enable the user’s identity source to respond to this type of potential attack by disabling the user account for a preset period of time after a specified number of failed login attempts.
The supported identity sources have the following built-in intrusion detection systems:
Active Directory Account Lockout Policy: Active Directory allows you to specify an account lockout policy for users and global security groups in a domain. Set the policy on the domain group policy object from the domain controller.
To configure the Account Lockout Policy settings:
Log in as an Active Directory administrator user to the Windows Server that hosts Active Directory Domain Services (the domain controller).
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.
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.
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:
Log in as the eDirectory administrator user to the eDirectory server management console.
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.
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.
Repeat these steps for each configured eDirectory identity source.
NOTE:By default, the intruder detection is disabled when you create a new container object. Perform the following steps in Administration Console to enable the intruder detection:
Click <username> > Manage Directory Objects > Tree > <container name> > (current level) > General > Intruder Detection.
Select Detect intruders.
Select Lock account after detection.
If you do not select this option, no action is taken when intruder detection is activated.
Click Apply > OK.
After you configure the intrusion detection for the supported identity sources, continue with Setting Up a reCAPTCHA Account.
Before configuring reCAPTCHA, you must set up a reCAPTCHA account.
To set up an account, perform the following steps:
Log in to the Google reCAPTCHA website.
Click Get reCAPTCHA > Sign up Now.
Specify a label and the registered domains.
Select Invisible reCAPTCHA as the type of reCAPTCHA.
Click Register.
Make a note of Site Key and Secret Key for future use.
Continue with Configuring reCAPTCHA.
Click Devices > Identity Server > Servers > Edit > Local > Classes > Name/Password – Form OR Secure Name/Password – Form. Click Properties.
Select Enable reCAPTCHA.
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.
Click OK and update Identity Server.