8.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:

8.2.1 Creating Basic or Form-Based Authentication Classes

  1. In the Administration Console, click Access Manager > 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 8.2.4, Creating a RADIUS Authentication Class 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 8.2.4, Creating a RADIUS Authentication Class for configuration steps.

    NMASAuthClass: The authentication class used for Novell Modular Authentication Service (NMAS™), which uses fingerprint and other technology as a means to authenticate a user. For instructions on using the NMAS NESCM method, see Section 8.10, Configuring Access Manager for NESCM.

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

    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 8.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 8.3, Configuring Authentication Methods.

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

8.2.2 Specifying Common Class Properties

The following properties can be used by multiple classes:

For properties specific to a class, see the following:

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

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 email address. The JSP Property allows you to specify a custom login page. For information on creating a custom login page, see Section 8.7, Creating Custom Login Pages.

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.

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

For information on creating a custom login page, see Section 8.7, Creating Custom Login Pages.

8.2.3 Creating an X.509 Authentication Class

The X.509 authentication class lets you authenticate users using X.509 certification for mutual authentication. It also identifies the user in user-stores, employing various user-mapping mechanisms.

If you have installed your Identity Server as a protected Access Gateway resource, you cannot use the x.509 class for authentication. For more information about this type of configuration, see Protecting an Identity Server with an Access Gateway in the Novell Access Manager 3.0 SP4 Setup Guide.

WARNING:There is a potential security vulnerability with X.509 certificates if your users do not close their browsers at the end of their sessions. For more information, see Section 1.5.3, Potential X.509 Certificate Vulnerability.

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

  2. Click New.

  3. Specify a display name, then choose X509Class from the drop-down menu.

  4. Click Next.

    Specifying X.509 validations

  5. Configure the validation options:

    Validations: The validation type. Trust validation occurs if the certificate chain is verified in the NIDP Trust Store. In addition to usual certificate validations, the Identity Server supports CRL (certificate revocation list) and OCSP (Online Certificate Status Protocol) validations for each authentication request.

    Access Manager caches CRLs, so the revoked status of a newly revoked certificate is not picked up until the next cache refresh. For higher security requirements, use OCSP validation with CRL validation. You can select None, CRL, OCSP, OCSP-CRL, or CRL-OCSP validation. In a production environment, for highest security, select either OCSP-CRL or CRL-OCSP validation. The default setting is to check OCSP first, then CRL.

    CRL Validation: Checks the CRL. If you enable CRL validations, the CRL distribution point extension is read out of the user’s X.509 certificate. The CRL distribution point contains URL where the complete CRL can be found, as published by the certificate authority. The system performs sanity checks on the CRL itself and then checks to see if the user certificate is in the revoked list. The system can get the CRL over HTTP and LDAP. If you are not expecting the distribution point in user certificates, you can specify a value in the LDAP URL to get the CRL.

    Access Manager supports two schemes for a URL: http:// and ldap://.

    The CRL is cached until Tomcat is restarted.

    OCSP Validation: If OCSP validation is enabled, the Authority Info Access point (AIA) is read out of the user certificate, which contains the URL for the OCSP responder. A signed OCSP request for the user certificate is sent to OCSP responder. A signed OCSP response is received from the responder which has the revoked status for the user certificate. Alternately, if you are not expecting AIA in user certificate, you can specify a value in the OCSP responder URL field. The value you enter here overrides any OCSP responder URLs in a certificate.

    Access Manager supports two schemes for a URL: http:// and ldap://.

    Disable Root CA Revocation Check: Disables whether to check if a certificate authority has been revoked. This option checks the CRL and OCSP for the trusted root certificate in the chain. You can enable or disable this option for X.509 user authentication performance.

  6. Configure the trust stores:

    NIDP Trust Store: This trust store must contain the trusted root certificate of the Certificate Authorities that signed your user certificates. Click this link to add certificates to the trust store.

    OCSP Trust Store: This trust store must contain the signing certificate of the OCSP servers you want to trust. Click this link to add certificates to the trust store. You must add the signing certificate, not the trusted root certificate, for this feature to work.

  7. Click Next.

  8. Configure attribute mappings.

    Specifying attribute mappings for X.509

    Use this page to specify attribute mappings for the X.509 authentication class. Subject name is the default map.

    Show certificate errors: Displays an error page when a certificate error occurs. This option is disabled by default. When troubleshooting mutual authentication, you should enable this option. It is a good way to gather additional information.

    Auto Provision X509: Enables automatic provisioning of users using X.509 authentication. This option allows you to activate X.509 for increased security, while using a less secure way of authentication, such as username/password. Extra security measures can even include manual intervention to activate X.509 authentication by adding an extra attribute that is checked during authentication.

    An example of using this option is when a user authenticates with an X.509 certificate, a lookup is performed for a matching SASallowableSubjectNames with the name of the user certificate. When no match is found, and Auto Provision X509 is enabled, the user is presented with a custom error page specifying to click a button provide additional credentials, such as a username and password, or to start an optional Identity Manager workflow. If the authentication is successful, then the user’s SASallowableSubjectNames attribute is filled in with the certificate name of the user certificate.

    When Auto Provision X509 is enabled, and the attribute that is used for subject name mapping is changed from the default sasAllowableSubjectNames, ensure that the LDAP attribute that is used can store string values with a length as long as the longest client certificate subject name. For example, if you use the LDAP attribute title (which has an upper bound of 64 characters) the Auto Provision X509 fails the provisioning part of the authentication, if the client certificate subject name is longer 64 characters. The authentication works if a valid name and password is given. However, provisioning fails.

    Attributes: The list of attributes currently used for matching. If multiple attributes are added to the list, the user must match only one of the attributes. As soon as a match occurs, the other attributes are skipped. Use the Up and Down arrows to arrange the order in which the system processes the attributes.

    Available attributes: The available X.509 attributes. To use an attribute, select it and move it to the Attributes field. When the attribute is moved to the Attributes list, you can modify the mapping name in the Attribute Mappings section. The mapped name must match an attribute in your LDAP user store.

    Directory name: Searches for the Directory Address in the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

    Email: Searches for the email attribute in the client certificate and tries to match it with a value in the LDAP mail attribute.

    Serial number and issuer name: Lets you match a user’s certificate by using the serial number and issuer name. The issuer name and the serial number must be put into the same LDAP attribute of the user, and the name of this attribute must be listed in the Attribute Mappings section.

    When using a Case Ignore String attribute, both the issuer name and the serial number must be in the same attribute separated by a dollar sign ($) character. The issuer name must be in front of the $ character, with the serial number following the $ character. Do not use any spaces in front of or behind the $ character. (For example, O=CURLY, OU=Organization CA$21C0562C5C.)

    The issuer name can be from root to leaf or from leaf to root. The issuer name must be comma-delimited with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

    The serial number cannot begin with a zero (0) or with a hexadecimal notation (0x). If the serial number is 0x0BAC05, the value of the serial number in the attribute must be BAC05. The certificate number is displayed in Internet Explorer with a space after every fourth digit. However, you should enter the certificate number without using spaces.

    The LDAP attribute can be any Case Ignore List or Case Ignore String attribute of the user. If you are configuring your own attribute, ensure that the attribute is added to the Person class. When using a Case Ignore List attribute, both the issuer name and the serial number must be in the same list. The issuer name needs to be the first item in the list, with the serial number being the second and last item in the list.

    Subject name: Searches for the Subject name of the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches the Subject name of the client certificate. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.)

  9. Click Finish.

  10. Continue with Section 8.3, Configuring Authentication Methods.

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

8.2.4 Creating a RADIUS Authentication Class

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 that can run on an existing NetWare® server. 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.

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

  2. Click New.

  3. Specify a display name, then select RadiusClass or ProtectedRadiusClass from the drop-down menu.

  4. Click Next.

    Creating a Radius authentication class (step 2)

  5. Click New to add an IP address for the RADIUS server. You can add additional servers for failover purposes.

  6. Click OK.

  7. 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: The Java Server Page for the Java program executed by the Web server. Specify the name of the Java Server Page if you want to use something other than the provided JSP. The default page is used if nothing is specified.

    • Require Password: Specifies whether to require a JSP password.

  8. Click Finish.

  9. Continue with Section 8.3, Configuring Authentication Methods.

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