Novell Doc: Novell iChain Administration Guide - Authentication Profiles and How They Are Used

8.2 Authentication Profiles and How They Are Used

There are three classes of authentication profiles:

LDAP
RADIUS
Mutual

You cannot have two or more authentication profiles from the same class combined. If two or more authentication profiles are provided in an AND condition, then only one user can be represented from a successful login.

Mutual and RADIUS authentications first try to obtain a username or distinguished name (DN), or some unique information about a user. This data then is used to either search for the specific user or bind to the specific user using an LDAP authentication profile. The end result is that iChain has a full DN.

A user must be found so that OLAC variables can be obtained and ACLCheck can provide access control for the user. Only the ACLCheck authentication profile is used for OLAC and ACLCheck.

The following table provides information about the authentication profiles that are available:

Authentication Class	Sub-class	Description
Mutual	DN	The full DN is stored within the certificate. A potential issue is that the format of the DN might be in reverse order. No formatting is done to the DN.
Mutual	Certificate mapping	Map data in the certificate to a user in an LDAP profile.
RADIUS	Novell RADIUS	The username and token are used to authenticate to the RADIUS server. This can be configured to return the full DN of the user that authenticated. With this DN, a user can be found in an LDAP profile.
RADIUS	Normal	The username and token are used to authenticate to the RADIUS server. The username must be used in some fashion to match to a user in the LDAP profile. This limits the kinds of LDAP profiles that can be used.
LDAP	DN bind with DN input	This configuration lists no LDAP contexts. A full DN is required for input. This profile might not work in conjunction with RADIUS:normal.
LDAP	DN bind with search field	A DN is built from the search field and username values. A bind () is called for all contexts or a specific context with the DN and password. The default search field value is cn.
	Attribute search	A search is performed for equivalence on the defined attribute and the username value. The search is performed for each subtree listed until a match is found. Note that multiple matches are not allowed. The search is performed using the rights of the LDAP username defined in the LDAP profile. After a match is found, a bind () on the DN of the matched user with the input password is called to validate the password.

8.2.1 The Authentication Process With Mutual Authentication

The data is extracted from the certificate and used to locate a user in an LDAP tree. The LDAP tree that is selected comes from an LDAP authentication profile named ldapcert. If this authentication profile is not found, the LDAP server defined in the aclcheck profile is used. The LDAP authentication profile must have a user and password with rights to read and verify the information within the mutual certificate.

When a mutual authentication profile is only used to authenticate a user, a password is not provided. The username is extracted from searches that are performed with the certificate data and the mapping rules. This means that the password field value is empty if passed to a back-end Web server.

8.2.2 The Authentication Process With RADIUS Authentication

Only a username and token value are needed to log in to a RADIUS server. The LDAP tree that is selected comes from an LDAP authentication profile named ldaprad. If this authentication profile is not found, the LDAP server defined in the aclcheck profile is used. The LDAP authentication profile must have a user and password that has rights to read and verify the username provided in the form. With a properly configured Novell RADIUS server, the full DN is returned with a successful login. This full DN represents the user.

The LDAP password is optional. If a password is provided, the input username and LDAP password will be used in a bind () call against the selected LDAP authentication profile. If successful, the user is authenticated. If it is not successful, the user must try again. If the password is not provided, a search is made on the selected LDAP tree to locate the user.

8.2.3 Using LDAP AND Mutual Over HTTP

The user should be prompted for a certificate when a restricted or secure page is hit. The mutual screen is displayed first, followed by the LDAP login screen. Both username values must be the same or the authentication fails.

8.2.4 Using LDAP AND Mutual Over HTTPS

The user should be prompted for a certificate upon initial connection to an accelerator. If required, this could be changed when a restricted or secure page is hit. The LDAP login screen comes up when a restricted or secure page is hit. Both username values must be the same or the authentication will fail.

8.2.5 Using LDAP OR Mutual, RADIUS OR Mutual

This configuration raises issues when the user authenticates with mutual authentication and a password is not defined that can be passed to origin Web servers.

8.2.6 Using RADIUS AND Mutual

This configuration is similar to LDAP AND Mutual with the exception that the LDAP password is optional with a RADIUS profile. If a password is provided, then an LDAP bind takes place. The Mutual authentication can use the ldapcert authentication profile and the RADIUS authentication can use the ldaprad authentication profile.

8.2.7 Using LDAP AND RADIUS

This combination forces the user to input the LDAP password. Only one authentication page needs to be presented to the user. The current RADIUS login page lists the LDAP password as optional. The administrator is responsible for configuring it correctly.

8.2.8 Using LDAP OR RADIUS

This combination should give the user the RADIUS login page. The user can either input the username with the token or the username with the LDAP password (either will work). After a RADIUS authentication, the LDAP profile in the combination is used to locate the user within the tree. If the user is not found, the authentication fails.

8.2.9 Using LDAP AND RADIUS AND Mutual

This combination is similar to RADIUS AND Mutual, where once the user is located, the LDAP profile is used to validate that the user exists instead of the default aclcheck profile. The main difference is that the LDAP password is required and an LDAP bind takes place.

8.2.10 Using LDAP OR RADIUS OR Mutual

This combination is similar to RADIUS OR Mutual, where once the user is located, the LDAP profile is used to validate that the user exists instead of the default aclcheck profile. The main difference is that the LDAP password is required and an LDAP bind takes place.