2.2 Understanding the Authentication Class

2.2.1 Authentication Class Components

Identity Server is the central authentication and identity access point for all services performed by Access Manager. Identity Server supports numerous ways for users to authenticate. These include name/password, RADIUS token-based authentication, and X.509 digital certificates.

For more information about Identity Server and its relation to other Access Manager components, see Creating Authentication Classes in the NetIQ Access Manager 5.0 Administration Guide.

The configuration and interaction of the following entities defines how authentication takes place within Identity Server:

  • User Stores: The LDAP directory that stores the user credentials. Access Manager can be configured to use the following directories: eDirectory™, Active Directory*, or Sun One*. Users set up their user stores when creating Identity Server configuration.

  • Authentication Classes: The code (a Java class) that implements a particular authentication type (name/password, RADIUS, and X.509) or means of obtaining credentials. This is what you create with this API.

  • Authentication Methods: Pairs an authentication class with one or more user stores, primarily to identify authenticated users. Authentication methods also can be designed to identify entities other than end users.

  • Authentication Contracts: The basic unit of authentication within Identity Server. Contracts are identified by a unique uniform resource identifier (URI) that can be used by Access Gateways and agents to protect resources. Contracts are comprised of one or more authentication methods used to uniquely identify a user.

Figure 2-1 Local Authentication Components

2.2.2 How the Authentication Class Operates

Figure 2-2 illustrates an example of how an authentication class is used to authenticate to an Identity Server. It uses a single user store located on an LDAP server to verify name and password credentials.

Figure 2-2 How the Authentication Class Handles a User Request.

  1. A user initializes an authentication request from a browser.

  2. The request causes the default authentication class to execute. This class defines what credentials are required for authentication, and it returns a response prompting the user for the required credentials (that is, username, password, x509 certificate, etc.). The user enters the credentials.

  3. The class obtains the credentials, then passes them to the user store for verification and validation.

  4. If credentials are valid, the user store returns the user’s DN (or other information specified by the method) and allows user access. If the information is not valid, access is denied.

The authentication API also enables you to implement more complex authentication using X.509 certificates, data generated by token devices, biometric data, or other data you specify. In such instances, you must specify the outside resources that contain the credential stores that are configured to validate the required user credentials.