Policy Server Guides › Policy Server Configuration Guide › Strong Authentication › Set Up Back-end Processing

Set Up Back-end Processing

To use the Credentials Selector, the following components are required for back-end processing:

• Authentication schemes for each choice of login credentials.
• Policy domain that contains the back-end components.
• Realms that use each authentication scheme.
• Rules for each realm.
• Policies that set an authentication context and that authorize resource access.

Set Up Authentication Schemes for Back-End Processing

Set up several authentication schemes for back-end processing, one for each choice of credentials made available to the user. These schemes enable a user to choose the type of credentials they provide to access a protected resource.

There is one authentication scheme for each type of credential:

• An HTML Form authentication scheme
• An X.509 Client Cert authentication scheme
• An X.509 Client Cert And Form authentication scheme
• A SecurID HTML Form authentication scheme
• A SafeWord HTML Form authentication scheme
• A Windows authentication scheme

Note: The Basic authentication scheme is a default scheme set up as part of the Policy Server installation.

Set Up a Policy Domain for Back-End Processing

Configure a policy domain to represent the Credentials Selector back-end processing. In this solution, the policy domain is named BackendAuth.

Configure Realms for the Back-end Policy Domain

Define one realm for each configured back-end authentication scheme. Each realm needs a resource filter that is defined as follows:

/auth/redirect.asp?authtype=type&target=

type

Can be one of the following values:

form username/password authentication

cert certificate authentication

certform cert-and-form authentication

securid SecurID authentication

safeword SafeWord authentication

windows Windows authentication

Note: These are the types that are chosen for the purposes of this use case. You are not restricted to these specific values, but the types must correspond to the authtype values in the selectlogin.fcc file, or any other FCC file that is based on the selectlogin.fcc template. Also, the realm resource filter must match the redirect target in the FCC file.

The following pane lists the realms.

The Web Agents protecting the realms can but do not need to be the same. This solution uses a single Web Agent; however, if multiple Web Agents are used, they must satisfy specific requirements.

The following requirements are necessary for agents that are protecting realms as part of the Credentials Selector functionality:

• Single sign-on must be configured between all Web Agents protecting realms. This means that they are in the same cookie domain or they use the same cookie provider.
• The value of the @smagentname directive in the FCC file must match the expected value for at least one of the Web Agents protecting the originally requested resource.

  The expected value is the value of the AgentName parameter or the DefaultAgentName parameter, if the AgentName parameter is not assigned a value. If the EncryptAgentName parameter in the agent configuration is set to yes, the value must be encrypted.

  One way of setting the @smagentname directive is by configuring each Web Agent with the same naming properties. They can even share an Agent Configuration Object. Another method is to configure the @smagentname directive programmatically in the FCC file, if the name is not encrypted.

  Important! If the @smagentname directive is misconfigured, you can see a “No realm received in request” error message in the Policy Server log.

• The FCCForceIsProtected parameter must be set to yes to ensure that a second IsProtected call is made for the new target that the selectlogin.fcc file generates. Set the IgnoreQueryData parameter to No to prevent the agent from ignoring the URL query parameters.

Create Rules for the Back-end Policy Domain

In each realm that you configure for the BackendAuth policy domain, configure the following two rules:

• An OnAuthAccept rule
• A Web Agent action rule (for the purposes of this example, use a GET action rule)

Configure an asterisk (*) as the value for the Resource field for both rules.

For example, for the Form realm in the BackendAuth policy domain, the rules would be:

OnAuthAccept

Resource: /auth/redirect.asp?authtype=form&target=*

Action: OnAuthAccept

GetRule

Resource: /auth/redirect.asp?authtype=form&target=*

Action: Get

Configure AuthContext Responses for the Back-end Policy Domain

Configure an AuthContext response for each authentication scheme in the BackendAuth domain. Each of these responses contains an AuthContext response attribute, which is evaluated only on an OnAuthAccept event. Its value is added to the CA SiteMinder® session ticket as the value of the SM_AUTHENTICATIONCONTEXT user attribute. The value is not, however, returned to the client as a user response.

For this example, the list of responses are as follows:

Note: The response attribute value is truncated to 80 bytes in length.

To configure an AuthContext response attribute, select the WebAgent-OnAuthAccept-Session-AuthContext response attribute type.

The following illustration shows the creation of an AuthContext response attribute using the WebAgent-OnAuthAccept-Session-AuthContext attribute type.

As the illustration shows, the AuthContext response attribute type is static. When legacy federation is in use, you can specify a static attribute to define a constant or literal value for better encapsulation. Constant values include strings.

CA SiteMinder® variables and active expressions add more flexibility to configuring AuthContext response attributes. They can also contain the authentication timestamp, a hash value, or both of a SAML assertion.

The following group box shows one of the resulting responses that are configured for this solution. This is the attribute for the Form response.

Configure Policies for Back-end Credential Selection

Configure two policies for the BackendAuth domain in this example:

• One for setting the user authentication context
• One for Web Agent actions

The following illustration shows the two policies.

Create an Authentication Context Policy

The AuthContext policy sets the authentication context in the CA SiteMinder® session ticket, which is used for authentication and validation. In this policy, the OnAuthAccept rules from each realm are paired with the corresponding responses to permit access to protected resources. For example, the OnAuthAccept Rule for the Form realm is paired with the Form response and the OnAuthAccept rule for the SafeWord realm is paired with the SafeWord response.

User authentication and user validation are OnAuthAccept events so the authentication context in the session ticket can be overwritten after each validation. The ability to update the authentication context attribute can be useful in some circumstances, for example, if the value of that attribute includes a counter. However, in this solution using the Credentials Selector, the AuthContext policy is configured to fire only if the authentication context is empty to ensure that the session ticket is not overwritten. The credentials that the user chooses are thus remembered.

Protect the authentication context from being overwritten by writing an active expression in the AuthContext policy to retrieve the SM_AUTHENTICATIONCONTEXT attribute from the session ticket.

When legacy federation is in use, you can create a user context variable called AuthContext and can use it in the AuthContext policy to define an active expression that retrieves the SM_AUTHENTICATIONCONTEXT attribute from the session ticket.

Define an active expression using the AuthContext variable in the AuthContext policy:

Create a Protection Policy

Authorizing an authenticated user for a requested resource requires a second policy in the BackendAuth domain. This policy protects the resources and is in addition to the authentication context policy in this domain.

Configure the protection policy to authorize the authenticated user for the redirection target, which is a GET action on the redirect.asp file. Name the policy GetPolicy.

The GetPolicy would contain the associated rules: