Previous Topic: Supported Authentication Schemes and Password PoliciesNext Topic: Authentication Schemes and Credential Requirements


Persisting Authentication Context Data

In addition to storing user data in the session ticket, you can optionally specify that SiteMinder persist the authentication context data in the session store. SiteMinder creates session variables and treats them as if they were session ticket fields that are named after the session variables. The Policy Server can access session variables in the session store, which can affect authentication decisions.

You can configure Responses and Policies to manipulate, store, or send back session context attributes available 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 it 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. This option is available for the Custom scheme, the SAML authentication schemes, and the 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 really intend to use the variables at a later time 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 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.

More information:

Policies

Domains