Novell Documentation: Volera Excelerator 2.3 - Matching Authentication Profiles to Your Requirements

Matching Authentication Profiles to Your Requirements

Chances are good that your network already requires authentication of those seeking access to network services through a database of some kind (LDAP-compliant, RADIUS, Novell Directory Services, or NTLM). Excelerator 2.x lets you extend your authentication infrastructure to include access to proxy services.

The following sections provide information to help you match Excelerator's authentication profile types with your network requirements.

Understanding How Profiles Work

Each profile type has different authentication mechanisms as indicated in Table 7:

Table 7.

Profile Type	Summary of Authentication Mechanisms
Mutual (certificate-based)	To gain access to a proxy service, browsers must present information to the cache device for a certificate that has been signed by the Certificate Authority (CA) assigned to the profile. This method is much less secure if the profile is used alone and uses a well known trusted root.
LDAP	To gain access to a proxy service, users must enter the information required by the profile, normally a valid username and password. The exchange of the username and password between the browser and the cache device is encrypted. The exchange of information between the cache device and the LDAP server can be encrypted or non-encrypted depending on whether the LDAP server's Trusted Root has been imported to the cache device. IMPORTANT: NDS Single-sign-on functionality is available if the LDAP-compatible database is NDS. The service is configurable only from the command line.
RADIUS	To gain access to a proxy service, users must enter their RADIUS username and password. The exchanges of username and password information between the browser, cache device, and RADIUS server are all encrypted. Single-sign-on functionality is configurable only from the command line.
NDS	To gain access to a proxy service, users must enter their Novell Directory Services username and password. All exchanges of username and password information between the browser, cache device, and NDS server are encrypted. IMPORTANT: NDS Single-sign-on functionality is configurable only from the command line.
Basic	To gain access to a proxy service, users must enter the information required by the profile on which the Basic profile is based (LDAP, RADIUS, or NDS). The exchange of username and password information between the browser and the cache device is lightly encrypted. The exchange between the cache device and the directory or database is the same as the profile on which the basic profile is based.
NTLM	To gain access to a proxy service, user must enter their NTLM username and password. All exchanges of user credentials are encrypted. Only Global NTLM users can authenticate using this service.

A Summary of Authentication Method Pros and Cons

Excelerator 2.3 provides support for various authentication sources as summarized in Table 8:

Table 8.

Profile Type	Pros	Cons
Mutual (certificate-based)	The browser must have a certificate signed by the Certificate Authority of the profile's Trusted Root. This protects against spoofing by unauthorized persons. Authentication to the service lasts for the entire session (there is no timeout). A username and password are not required. Combining a Mutual profile with an LDAP, RADIUS, or NDS profile creates the most secure authentication method.	Management of certificates on browsers can be support-intensive If the workstation is not secure or is stolen, unauthorized persons can access the service. This method is much less secure if the profile is used alone and is using a well known trusted root.
LDAP	LDAP is a widely used directory service protocol. This method works with Secure LDAP servers. This implementation supports context-less login. This implementation supports group access.	LDAP trees might be viewable by unauthorized persons.
RADIUS	RADIUS dial-in servers are widely used. The username and password are automatically encrypted.	RADIUS requires maintenance of various access control lists.
NDS	If users are currently managed using NDS, this is easy to set up. This method supports context-less login. NDS groups are supported on NetWare 5 and NetWare 6 servers through an LDAP group implementation.	eDirectory (NDS) is required. eDirectory (NDS) groups are not natively supported.
Basic	This works with streaming media services and other applications that don't support SSL. This is a good solution for those who don't need username and password encryption. This method doesn't involve cookies.	The username and password are more easily decrypted than with other methods.
NTLM	This method takes advantage of Microsoft NT's security scheme. If users are currently managed using NT Domains, this is easy to set up. If the user has previously logged into the Domain, authentication is transparent. This method doesn't involve cookies.	The Domain Controller with the username and password must be on the same IP subnet as the cache device.

Combining Authentication Profiles

Depending on the profile types you are using, you might be able to assign two authentication profiles to a service for added security and/or flexibility. Only the specific profile combinations indicated in Table 9 are allowed.

Table 9.

Profile Type	Can Combine with
Mutual (certificate-based)	One of the following: LDAP RADIUS NDS
LDAP	Mutual
RADIUS	Mutual
NDS	Mutual
Basic	Cannot be paired with other authentication profiles.
NTLM	Cannot be paired with other authentication profiles.

AND and OR Relationships Between Profiles

When you configure a service to use two authentication profiles, you must specify whether the profiles have an AND relationship (the user must pass both profiles' criteria to access the service) or an OR relationship (the user must pass only one profile's criteria to access the service).

Combining Mutual (Certificate-Based) Profiles with Other Profiles

As indicated in Table 9, you can combine Mutual profile types with LDAP, RADIUS, or NDS profiles.

If the service is configured so that the profiles have an AND relationship, the information in the user certificate used for the Mutual profile must exactly match the information in the directory or database for the associated profile. Table 10 summarizes this requirement:

Table 10.

Certificate Information	Must Match LDAP Context	Must Match RADIUS Information	Must Match NDS Context
Country: USA	c=USA	ignored	c=USA
Organization: Company Name, Inc.	o=Company Name, Inc.	ignored	o=Company Name, Inc.
Department: Sales	ou=Sales	ignored	ou=Sales
Name: John Doe	cn=John Doe (Netscape iPlanet uses uid=John Doe)	A valid username in the user list	cn=John Doe

If the fields shown in Table 10 don't match exactly, the user receives a 403 error indicating that the contents of the certificate doesn't match the username and password. For example, if the Country information in Table 10's certificate were United States of America (or even U.S.A.) the user would receive the 403 error.

Combining Authentication Profiles for Same-Domain Accelerators

If you combine authentication profiles for Web server accelerators that service origin Web servers in the same DNS domain, users of the accelerator services could receive username authentication mismatch errors.

To avoid this, check your configuration against the explanation in Table 11. If your configuration matches all the points in the table, follow the suggestions provided.

Table 11.

If	You Must
You have created multiple Web Server Accelerators for Web servers that are on the same DNS domain. For example: server1.foo.com, server2.foo.com, etc. And you have created multiple username/password profiles to assign to the accelerators And two or more of the username/password profiles are of the same type (LDAP, NDS, or RADIUS) For example, you might have profiles named LDAP1, LDAP2, etc. And you want to combine the username/password profiles with mutual (certificate-based) profiles	Create a separate mutual authentication profile to pair with each of the username/password profiles that are of the same type (LDAP, NDS, or RADIUS). For example, you might name the mutual profiles CERT1, CERT2, etc. Assign the username/password profiles and the mutual profiles to the accelerator services in matching pairs. For example, you would assign CERT1 with LDAP1, CERT2 with LDAP2, etc.

You Must

You have created multiple Web Server Accelerators for Web servers that are on the same DNS domain.
For example: server1.foo.com, server2.foo.com, etc.
And you have created multiple username/password profiles to assign to the accelerators
And two or more of the username/password profiles are of the same type (LDAP, NDS, or RADIUS)
For example, you might have profiles named LDAP1, LDAP2, etc.
And you want to combine the username/password profiles with mutual (certificate-based) profiles

Create a separate mutual authentication profile to pair with each of the username/password profiles that are of the same type (LDAP, NDS, or RADIUS).

For example, you might name the mutual profiles CERT1, CERT2, etc.
Assign the username/password profiles and the mutual profiles to the accelerator services in matching pairs.

For example, you would assign CERT1 with LDAP1, CERT2 with LDAP2, etc.

NOTE: The mutual authentication profiles can each use the same trusted root if desired.

Understanding How Authentication Cookies Are Used

If you are concerned that some authentication methods use cookies, you should understand the following two points about Excelerator cookie functionality.

Authentication cookies are session-based, meaning that they expire either when the session ends or when an inactivity timeout occurs.
Because unique authentication cookies are sent to each browser, there is no risk of global service access in NAT IP installations. In other words, each NAT client must authenticate to use the service.

The usage of cookies by authentication profiles is summarized in Table 12:

Table 12.

Profile Type	Cookies Used	Cookie Effective Until
Mutual (certificate-based)	Yes	Current session ends
LDAP	Yes	Specified inactivity timeout occurs
RADIUS	Yes	Specified inactivity timeout occurs
NDS	Yes	Specified inactivity timeout occurs
Basic	Yes, if assigned to a transparent service No, if assigned to a forward or Web acceleration service	Specified inactivity timeout occurs (transparent only)
NTLM	No