Policy Server Guides › Policy Server Configuration Guide › Authentication Schemes › Authentication Schemes Overview › Supported Authentication Schemes and Password Policies

Supported Authentication Schemes and Password Policies

Some authentication scheme types support Password Policies, while others do not. You can view whether a particular type of authentication scheme supports Password Policies by opening the Authentication Scheme Properties dialog in the Administrative UI. To view a particular authentication scheme type, select it from the drop-down list on the Scheme Common Setup group box and observe the Password Policies Enabled for this Authentication Scheme check box. If the authentication scheme does not support Password Policies, the check box description is dimmed and the check box is unavailable.

To view supported authentication scheme types and whether they support Password Policies without accessing the Administrative UI, see the following table:

Limit Policy Server Search to One User Store during Authentication

A single user can be stored in more than one user directory or database that is associated with a policy domain. This user has the same password in each user store. During the authentication process, the Policy Server can find that a user is disabled in one user store. However, by default, it continues searching for the user in all stores that are associated with the policy domain. The user fails authentication only if the Policy Server finds the user that is disabled in all associated user stores. The user is authenticated if it is enabled in any associated user store.

This default behavior is configurable. Stop the Policy Server from searching directories after it finds the user that is disabled in a user store.

Follow these steps:

1. Add the registry key ReturnOnDisabledUser:

   Windows

   Add the registry key ReturnOnDisabledUser to the following location:

   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion
   \PolicyServer
   

   Solaris

   Add the following lines to the sm.registry file:

   HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Netegrity\SiteMinder\CurrentVersion
   \PolicyServer
   ReturnOnDisabledUser=0x1; REG_DWORD
   

2. Assign ReturnOnDisabledUser the value of one.

Authentication Scheme Processing

To determine the identity of a user, the Policy Server employs the authentication scheme for the realm containing the resource. The authentication scheme specifies the credentials that the user must supply for authentication, and the method that the Policy Server uses to validate the user’s identity.

To configure authentication schemes, use the Administrative UI and assign the schemes to realms. The following diagram illustrates how an authentication scheme is called when a user attempts to access a protected resource.

In the example above, the user requests the protected resource sales.html from the /Sales/ realm. This realm requires Basic authentication. The Policy Server informs the Web Agent that the resource is protected and requests Basic credentials from the user by way of the Web Agent. The Agent prompts the user for a user name and password.

More information:

Configure a Realm

Authentication Scheme Types

The authentication schemes fall into a number of categories. These categories represent the general characteristics of available authentication methods. Details are provided in the sections of this chapter that discuss each specific authentication scheme.

Basic Authentication Schemes

Basic authentication identifies a user by the user name and password. The user’s identity is stored in a user directory. The Policy Server locates a user in a directory that is based on the user name. The Policy Server then verifies that the password matches the one saved in the user directory. If the user name and password that is supplied by the user match the data in the user directory, the user is authenticated.

The Administrative UI provides authentication scheme templates for the following basic schemes:

• Basic (HTTP Basic)
• Basic over SSL

HTML Forms-based Authentication Schemes

Configure customized HTML forms to collect more than basic authentication information. In a forms-based authentication scheme, a user can be required to enter more information such as an, organization or account number. The Policy Server verifies the additional information against user directory attributes before authenticating the user.

Windows Authentication Scheme

Integrated Windows Authentication (IWA) is a proprietary mechanism developed by Microsoft to validate users in pure Windows environments. IWA enforces Single Sign-On by allowing Windows to gather user credentials during the initial interactive desktop login process and subsequently transmitting that information to the security layer. The Policy Server, using the Windows Authentication scheme, secures resources by processing user credentials obtained by the Microsoft Integrated Windows Authentication infrastructure.

X.509 Client Certificate Authentication Schemes

You can configure X.509 V3 client certificates. Digital certificates act as cryptographic proof of a user’s identity. Once a certificate is installed on a client, that certificate can be used to verify the identity of a user who is accessing a resource. Certificate authentication uses SSL communication and can be combined with basic authentication to provide an even higher level of access security.

The following authentication scheme templates are available for certificate-based authentication schemes:

• X.509 Client Certificates
• X.509 Client Certificates and Basic
• X.509 Client Certificates or Basic
• X.509 Client Certificates and HTML Forms
• X.509 Client Certificates or HTML Forms

Note: For certificate-only authentication schemes, the web agent returns HTTP Error 403: Access Denied/Forbidden for any failed authentication or authorization attempt. This is because there is no way for the web agent to challenge the user for a new certificate.

Proxy Authentication Schemes

Proxy authentication schemes use the Policy Server as a proxy or substitute for the server that is required by a third-party authentication product. With a proxy scheme, the Policy Server performs the authentication function of the third-party server using scheme-specific libraries.

The following proxy authentication schemes are available:

• RSA ACE/Server (used with SecurID tokens)
• RSA ACE/Server (used with SecurID tokens) with HTML forms support for resetting passwords
• Secure Computing SafeWord Server
• RADIUS Server

Digest Authentication Schemes

A digest authentication scheme reads an encrypted user attribute string that is stored in a directory. The scheme then compares the string to the encrypted string it receives from the user. If the encrypted strings match, the Policy Server authenticates the user. A digest scheme compares a string encrypted on a client workstation to an encrypted string on a server without using an encrypted transmission.

The following digest authentication schemes are available:

• RADIUS CHAP
• RADIUS PAP

Anonymous Authentication Schemes

An anonymous authentication scheme allows non-registered users access to specific web content. A user tries accessing a resource that is protected by an anonymous authentication scheme. The Policy Server assigns the user a Global User Identification (GUID). This GUID is placed in a persistent cookie on the user’s browser so that the user can access specific resources without being challenged to authenticate.

Custom Authentication Schemes

If the Policy Server does not provide a method of authentication that you want to use, use CA’s APIs to develop a custom authentication scheme.

Note: If you have installed the Software Development Kit, see the API Reference Guide for C or the API Reference Guide for Java for more information about creating custom authentication schemes.

Authentication over SSL

Authentication can be configured to run over a Secure Sockets Layer (SSL) connection.

The following authentication scheme types are configured to use an SSL connection:

• Basic*
• HTML Forms*
• X.509 Client Certificates
• X.509 Client Certificates and Basic
• X.509 Client Certificates or Basic
• X.509 Client Certificate or HTML Forms
• X.509 Client Certificate and HTML Forms

Note: An asterisk denotes that an SSL connection is optional.