Policy Server Guides › Policy Server Configuration Guide › Authentication Schemes › Authentication Schemes Overview

Authentication Schemes Overview

In most cases, when a user attempts to access a network resource, the owner of the network wants to verify the identity of the user. Company employees should be identified to determine which resources they can use. Customers should be identified for personalization of content as they access resources. Even anonymous users should be tracked uniquely, so that their history can be used to provide a quality experience when they once again access the network. To identify a user, CA SiteMinder® employs authentication schemes.

Authentication schemes provide a way to collect credentials and determine the identity of a user. CA SiteMinder® supports a variety of authentication schemes. These schemes range from basic user name/password authentication and HTML forms-based authentication to digital certificate and token authentication. Simple schemes can be used for low risk network resources, while complex schemes may be employed to ensure added security for critical network resources.

Authentication schemes must be configured using the Administrative UI. During authentication, CA SiteMinder® Web Agents communicate with the Policy Server to determine the proper credentials that must be retrieved from a user who is requesting resources.

This chapter discusses general information for working with authentication schemes in the Administrative UI, then provides separate sections that explain how to configure each supported scheme using authentication scheme templates. These templates provide the Policy Server with most of the information it needs to process a scheme. An administrator must complete the configuration of an authentication scheme by supplying implementation specific information, such as server IP addresses, or shared secrets required to initialize a scheme.

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 associated with a policy domain. This user has the same password in each user store. During authentication, if the Policy Server finds that the user is disabled in one user store, then by default, it continues searching for the user in all stores associated with the policy domain. The user fails authentication only if the Policy Server finds the user disabled in all associated user stores. The user is authenticated if it is enabled in any associated user store.

This default Policy Server behavior is configurable. To configure the Policy Server to stop searching when it first finds the user disabled in a user store, add the following registry key and set its value to one: ReturnOnDisabledUser.

To limit Policy Server search to one user store during authentication

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

When a user attempts to access a protected network resource, the Policy Server uses the authentication scheme associated with the resource’s realm to determine how to identify the user. The authentication scheme specifies the credentials that the user must supply for authentication, as well as the method used by the Policy Server to validate the user’s identity.

You can use the Administrative UI to configure authentication schemes 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 via the Web Agent, which prompts the user for a user name and password.

More information:

Configure a Realm

Authentication Scheme Types

The Authentication Schemes supported by CA SiteMinder® 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 based on a user name and password. The user’s identity is stored in a user directory. With a basic authentication scheme, the Policy Server locates a user in a directory based on the user name, then verifies that the password matches the one saved in the user directory (binds the user to the directory). If the user name and password supplied by the user match the data in the user directory, CA SiteMinder® authenticates the user.

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

• Basic (HTTP Basic)
• Basic over SSL

HTML Forms-based Authentication Schemes

CA SiteMinder® supports the use of customized HTML forms to collect authentication information. In a forms-based authentication scheme, a user can be required to enter additional information such as a Social Security Number, organization, account number, etc. 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. CA SiteMinder®, using the Windows Authentication scheme, secures resources by processing user credentials obtained by the Microsoft Integrated Windows Authentication infrastructure.

Previous versions of CA SiteMinder® supported Windows authentication through the NTLM authentication scheme. However, this support was limited to environments with NT Domains or where the Active Directory service is configured to support legacy NT Domains in mixed mode.

The Windows authentication scheme allows CA SiteMinder® to provide access control in deployments with Active Directories running in native mode, as well as Active Directories configured to support NTLM authentication. The Windows Authentication scheme replaces CA SiteMinder®’s previous NTLM authentication scheme. Existing NTLM authentication schemes continue to be supported and can be configured using the new Windows Authentication scheme.

The NTLM authentication scheme can be used for resources that are protected by Web Agents on IIS Web servers, and whose users access resources via Internet Explorer Web browsers. This scheme relies on a properly-configured IIS Web server to acquire and verify a user’s credentials. The Policy Server bases authorization decisions on the user’s identity as asserted by the IIS server.

X.509 Client Certificate Authentication Schemes

CA SiteMinder® supports the use of 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 Administrative UI provides authentication scheme templates for the following 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: In the case of 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 are schemes that use the Policy Server as a proxy or substitute for the server 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.

CA SiteMinder® supports the following proxy authentication schemes:

• 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 stored in a directory, 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.

CA SiteMinder® supports the following digest authentication schemes:

• RADIUS CHAP
• RADIUS PAP

Anonymous Authentication Schemes

An anonymous authentication scheme allows non-registered users to access specific Web content. When a user accesses a resource that has anonymous authentication, CA SiteMinder® assigns the user a Global User Identification (GUID). CA SiteMinder® places this GUID 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 CA SiteMinder® does not provide a method of authentication that you want to use, you can 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.

Open Standard Web-based Schemes

CA SiteMinder® supports two open source standards for use across the Web:

• OpenID
• OAuth

OpenID and OAuth are different. OpenID use one login to access multiple sites. OAuth uses one site to permit access to data on another site. Both of these standards rely on decentralized providers to accomplish the goal of accessing resources securely.

Authentication over SSL

Authentication can be configured to run over a Secure Sockets Layer (SSL) connection. SSL is a method of establishing an encrypted connection between a client and a server using digital certificates to initiate the connection, and to establish a proof of identity.

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.

Persisting Authentication Context Data

The Policy Server can persist authentication context data in the session store. Storing data in the session store is an optional feature of some authentication schemes. The session store is another repository in addition to the session ticket for storing user data.

The Policy Server creates session variables and treats them as session ticket fields that are named after the session variables. The Policy Server can access session variables in the session store and impact authentication decisions.

You can configure responses and policies to manipulate, store, or send back session context attributes from the persisted authentication data. The information is retrieved from the session store and sent to the web agent. The web agent can store the data again, or provide the data to the authorization engine for evaluation. In addition, you can configure your own session variables and can use them for authorization.

To save the authentication context information, select the Persist Authentication Session Variables check box in the Scheme Setup section of the authentication scheme configuration. This option is available for the following schemes:

• Custom schemes
• SAML authentication schemes
• OpenID authentication scheme
• OAuth authentication scheme
• X.509 certificate schemes

Important! Persisting authentication data in the session store creates a degradation in the authentication time. Only select this option when you intend to use the variables later for authentication decisions. Otherwise, you can possibly experience a significant performance impact with no benefit.

Protection Levels

Authentication schemes require a protection level. This level ranges from zero to 1000. A higher number indicates that the scheme provides higher level of protection. When users authenticate successfully against a scheme, they can access any resource with a protection level equal to or below the current authentication scheme. Users still require authorization for a resource to gain access to it.

Note: Anonymous authentication schemes always have a protection level of zero. Custom schemes have a protection level between zero and 1000. All other authentication schemes have a protection level between1 and1000.

For example, a set of resources is available to all network users, you can assign a Basic (user name and password) authentication scheme. For revenue information that is available only to corporate executives, you can assign an X.509 client certificate scheme with a higher protection level. A user who has already authenticated with a user name and password can authenticate a second time with a digital certificate to access the revenue information.

Sometimes the predefined protection level of the authentication scheme can be inadequate. For example, in a federation scenario, the asserting party can possibly require a different protection level to accommodate the relying party. In such cases, the administrator can specify that a protection value in the authentication scheme library overrides the protection level specified in the UI. In this case, SiteMinder writes the value in the library to the user session ticket. Select the Allow Protection Override check box in the Scheme Common Setup section of the Create Authentication Scheme dialog for Custom and SAML authentication schemes.

More information:

Policies

Domains

Authentication Schemes and Credential Requirements

The following table lists all supported authentication schemes and their credential requirements:

*For NTLM or Windows, when trying to access a resource, CA SiteMinder® does not prompt the user to enter a username and password. This scheme relies on a properly-configured IIS Web server to acquire and verify a user’s credentials. The Policy Server bases authorization decisions on the user’s identity as asserted by the IIS server.

Set Up an Authentication Scheme Object in the Policy Server User Interface

To setup a new authentication scheme in the Administrative UI, components should be configured in the following order:

1. Web Server (only for certificate, SSL, and HTML forms-based schemes)
2. Policy Server (including Certificate Mapping for X.509 certificate schemes)

More information:

Certificate Mapping for X.509 Client Authentication Schemes

Web Server

In order for a CA SiteMinder® Web Agent to support any SSL-based Authentication Scheme, a Web Server must be configured to support SSL.

Note: More information on Web server configuration exists in the Policy Server Installation Guide for instructions on Web server configuration.

Policy Server

After you configure your Web servers to support authentication schemes, configure the Policy Server to support the schemes.

More information:

Authentication Schemes Overview

Multiple Instances of a Single Authentication Scheme Configuration

You can configure multiple instances of most authentication schemes in the Administrative UI. For example, you might create multiple HTML forms-based schemes to process login, forgotten password requests, logout, etc. If you create multiple instances of a scheme type, be sure to set protection levels to reflect your security requirements.