2.2 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.

Some classes require additional configuration to enable their use for authentication. See the following sections:

2.2.1 Creating Basic or Form-Based Authentication Classes

  1. In the Administration Console, click Devices > Identity Server > Servers > Edit > Local > Classes.

    Authentication classes

    The following classes are predefined for Access Manager:

    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.

  2. Click New to launch the Create Authentication Class Wizard.

    New authentication class

  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. See Section 3.1, Configuring for RADIUS Authentication for configuration steps.

    For a production environment, select one of the following protected classes:

    ProtectedBasicClass: The BasicClass, protected by HTTPS.

    ProtectedPasswordClass: The PasswordClass, protected by HTTPS (form-based).

    ProtectedRadiusClass: The RadiusClass, protected by HTTPS. See Section 3.1, Configuring for RADIUS 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 3.5, Configuring Access Manager for NESCM.

    KerberosClass: The authentication class used for using Kerberos* for Active Directory and Identity Server authentication. See Section 3.4, Configuring for Kerberos Authentication for configuration steps.

    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 3.3, Creating an ORed Credential Class.

    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.

    To download an authentication class that retrieves the user’s password and injects it into the user’s credentials when the user authenticates using a non-password method such as X509, RADIUS, smart card, or Kerberos, see Access Management Authentication Class Extension to Retrieve Password for Single Sign-on. Such a class allows you to enable single sign-on with Identity Injection and Form Fill policies that require the user’s password.

  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 Section 2.2.2, Specifying Common Class Properties for the properties that are used by the Access Manager installed classes.

  5. Click Finish.

  6. Continue with Section 2.3, Configuring Authentication Methods.

    To use an authentication class, the class must have one or more associated methods.

2.2.2 Specifying Common Class Properties

The following properties can be used by 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.

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 or methods derived from these classes:

  • BasicClass

  • PasswordClass

  • ProtectedBasicClass

  • ProtectedPasswordClass

When you specify a Query property, you must also modify the login page to prompt the user for the correct information. If you want users to enter their email address instead of the username, you need to modify the login form to prompt the user for an email address. If you want to prompt the users for their username and their email address, you need to add the email prompt to the login page. The JSP Property allows you to specify a custom login page. For information on creating a custom login page, see Section 1.3, Customizing the Identity Server Login Page.

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 their 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. This is in addition to 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 of person must be a valid object class in the LDAP user store. The email attribute must be a valid attribute of the person class.

JSP Property

The JSP property allows you to specify a custom login page. This property can be used with the following classes or methods derived from these 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 email_login.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: email_login

If your custom login page is customizing the login.jsp page so that different prompts appear, you do not need to also configure the MainJSP property. However, if your custom login page is a modified version of the nidp.jsp page or has been designed to replace the nidp.jsp page, then you must also configure the MainJSP Property.

If you use two methods to create a contract, the JSP 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.

For information on how to create a custom login page, see Section 1.3, Customizing the Identity Server Login Page.

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 on how to create a custom login page, see Section 1.3, Customizing the Identity Server Login Page.