Authentication Schemes

Authentication schemes provide a way to collect credentials and determine the identity of a user. During authentication, Web Agents communicate with the Policy Server to determine the proper credentials that must be retrieved from a user who is requesting resources.
sm1252sp1
Authentication schemes provide a way to collect credentials and determine the identity of a user. During authentication, Web Agents communicate with the Policy Server to determine the proper credentials that must be retrieved from a user who is requesting resources.

Owners of network resources want to verify the identity of users who attempt to access these resources are typically. Identifying a user determines the resources that users can access, and can determine how to personalize the content for that user. Tracking anonymous uniquely is useful so that their history can be used to provide a quality experience when they once again access the network. To identify a user, authentication schemes are used.
The Policy Server supports various authentication schemes. Use simple schemes for low risk network resources and complex schemes for added security for critical network resources.
The Policy Server uses authentication scheme templates, which provide the Policy Server with the information required to process a scheme. Configure authentication scheme templates using the Administrative UI.
Supported Authentication Schemes and Password Policies
Some authentication scheme types support Password Policies. 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. 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.
The following table lists supported authentication scheme types and whether they support Password Policies.
Authentication Scheme Type
Type Supports Password Policies?
Anonymous
No
Basic
Yes
Basic over SSL
Yes
Custom
Yes
HTML Forms
Yes
Impersonation
No
OAuth
No
OpenID
No
RADIUS CHAP/PAP
Yes
RADIUS Server
Yes
SafeWord
No
SafeWord and HTML Forms
No
SecurID
No
SecurID and HTML Forms
No
X.509 Client Certificate
No
X.509 Client Certificate and Basic
Yes
X.509 Client Certificate or Basic
Yes
X.509 Client Certificate and HTML Forms
Yes
X.509 Client Certificate or HTML Forms
Yes
Windows Authentication
Yes
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 or applications.
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 can 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
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.
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 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 that is specified in the Administrative UI. The value in the library is written 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.
Authentication Schemes and Credential Requirements
The following table lists all supported authentication schemes and their credential requirements:
 
Credential Requirements
Authentication Schemes
Directory User Name
Directory Password
Code from Token
X.509 Certificate
User Profile Attributes
Anonymous
 
 
 
 
 
Basic
yes
yes
 
 
 
Basic over SSL
yes
yes
 
 
 
Custom
optional
optional
optional
optional
optional
HTML Forms (over SSL optional)
custom credentials
custom credentials
 
 
optional
Impersonation
yes
 
 
 
optional
NTLM or Windows
yes*
yes*
 
 
 
RADIUS CHAP/PAP
yes
yes
 
 
 
RADIUS Server
yes
yes
 
 
 
SafeWord Server
yes
yes
 
 
 
SafeWord and Forms
yes
yes
 
 
optional
SecurID
yes
 
yes
 
 
SecurID and Forms
yes
 
yes
 
optional
X.509 Client Certificate
 
 
 
yes
 
X.509 Client Certificate and Basic (uses SSL)
yes
yes
 
yes
 
X.509 Client Certificate or Basic (over SSL optional)
yes for Basic
yes for Basic
 
yes for Certificate
 
X.509 Client Certificate and HTML Forms
custom credentials
custom credentials
 
yes
optional
X.509 Client Certificate or HTML Forms
custom credentials for HTML Forms
custom credentials for HTML Forms
 
yes for Certificate
optional for HTML Forms
* For access to a resource with NTLM or Windows, the Policy Server does not prompt the user to enter a user name 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.
CA Single Sign-On
retains leading and trailing spaces in user passwords. Leading and trailing spaces are removed from usernames during authentication.
Multiple Instances of a Single Authentication Scheme Configuration
You can configure multiple instances of most authentication schemes in the Administrative UI. For example, you can create multiple HTML forms-based schemes to process login, forgotten password requests, and logout. If you create multiple instances of a scheme type, set protection levels to reflect your security requirements.