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
In the Administration Console, 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” on page 148 .
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” on page 149
.
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:
“Creating Basic or Form-Based Authentication Classes” on page 284
.
“Specifying Common Class Properties” on page 285
Some classes require additional configuration to enable their use for authentication. See the following sections:
“RADIUS Authentication” on page 310
“Mutual SSL (X.509) Authentication” on page 318
“ORed Credential Class” on page 323
“OpenID Authentication” on page 324
“Password Retrieval” on page 325
“Configuring Access Manager for NESCM” on page 327
“Kerberos Authentication” on page 331
“Two-Factor Authentication Using Time-Based One-Time Password (TOTP)” on page 305
“Risk-based Authentication” on page 343
Creating Basic or Form-Based Authentication Classes
1
In the Administration Console, click
Devices > Identity Server > Edit > Local > Classes
.
2
Click
New
to launch the
Create Authentication Class Wizard
.
Configuring Authentication
283
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 “Mutual SSL (X.509) Authentication” on page 318
.
SocialAuthClass:
The authentication class used for implementing authentication through external OAuth providers such as Facebook, GooglePlus, LinkedIn and Twitter. See
“Social
Authentication” on page 299 .
TOTPClass:
The authentication class used for implementing two-factor authentication. See
“Two-Factor Authentication Using Time-Based One-Time Password (TOTP)” on page 305 .
Risk-based Auth Class:
The authentication class used for assessing the risk after authentication. See
“Risk-based Authentication” on page 343
.
Risk-based Pro-Auth Class:
The authentication class used for assessing the risk before authentication. See
“Risk-based Authentication” on page 343
.
ProtectedBasicClass:
BasicClass protected by HTTPS.
ProtectedPasswordClass:
PasswordClass protected by HTTPS (form-based).
ProtectedRadiusClass:
RadiusClass protected by HTTPS. See
“RADIUS Authentication” on page 310
for configuration steps.
KerberosClass:
The authentication class used for using Kerberos for Active Directory and
Identity Server authentication. See
“Kerberos Authentication” on page 331
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
“Configuring Access
Manager for NESCM” on page 327 .
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” on page 323 .
PasswordFetchClass:
The authentication class that allows the Identity Server to retrieve the user’s password when the user has used a non-password class for authentication. For configuration information, see
“Password Retrieval” on page 325
.
PersistentAuthClass:
The authentication class that allows for persistent logins, long authentication sessions, or remember my password functionality. For configuration information, see
“Persistent Authentication” on page 308
.
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 (https://www.netiq.com/documentation/access-managerdeveloper-documentation/) .
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.
284
Configuring Authentication
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” on page 285 for the properties that are used by the basic and password classes.
5
Click
Finish
.
6
Continue with “Configuring Authentication Methods” on page 287 .
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:
“Query Property” on page 286
“JSP Property” on page 286
“MainJSP Property” on page 287
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, the 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.
Configuring Authentication
285
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” on page 193
.
JSP Property
The JSP property allows you to specify a custom login page. This property can be used with the following classes:
PasswordClass
ProtectedPasswordClass
The property name is JSP and the property value is the filename of the login page you customized without the .jsp extension of the file. The property value cannot contain nidp in its name.
For example, if you created a custom file named emaillogin.jsp,you would specify the following values. The values are case sensitive. The property name needs to be entered as all capitals.
Property Name:
JSP
Property Value: emaillogin
If you use two methods to create a contract, this property must be set to the same value on both or set on only one. When it is set on only one method, the value is applied to both. This property needs
to be used with the MainJSP Property . For information about how to create a custom login page, see
“Customizing the Identity Server Login Page” on page 193 .
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 the Identity Server Login
Page” on page 193
.
286
Configuring Authentication
