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.
In the Administration Console, click> > > > .
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 on how to configure and use this class, see Section 7.2.3, 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 on how to configure and use this class, see Section 7.2.4, Configuring the Trust Levels Class.
To delete a class, select the class, then click.
You cannot delete a class if a method is using it.
For information on 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:
In the Administration Console, click> > > > .
Clickto launch the .
Specify a display name, then select a class from thedrop-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 4.2, Configuring Mutual SSL (X.509) Authentication.
ProtectedBasicClass: The BasicClass, protected by HTTPS.
ProtectedPasswordClass: The PasswordClass, protected by HTTPS (form-based).
ProtectedRadiusClass: The RadiusClass, protected by HTTPS. See Section 4.1, Configuring for RADIUS Authentication for configuration steps.
KerberosClass: The authentication class used for using Kerberos for Active Directory and Identity Server authentication. See Section 5.0, Configuring for 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 4.7, 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 4.3, Creating an ORed Credential Class.
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 Section 4.5, Configuring Password Retrieval.
OpenIDClass: The authentication class that allows you to configure the Identity Server to trust the provider or providers of OpenIDs. For configuration information, see Section 4.4, Configuring for OpenID Authentication.
Other: Used for third-party authentication classes or if you have written your own Java class. For information on how to write your own class, see Novell Access Manager Developer Tools and Examples.
Click Section 3.2.2, Specifying Common Class Properties for the properties that are used by the basic and password classes.to configure the properties for each class. Click , then enter a name and value. The names and values you enter are case sensitive. See
Continue with Section 3.3, Configuring Authentication Methods.
To use an authentication class, the class must have one or more associated methods.
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 should specify the properties on the method.
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:
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 should prompt the user for an e-mail address. The JSP Property allows you to specify a custom login page. For information on creating a custom login page, see Section 2.1, 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:
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 on how to create a custom login page, see Section 2.1, 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 information on how to create a custom login page, see Section 2.1, Customizing the Identity Server Login Page.