Previous Topic: Forms AuthenticationNext Topic: How to Configure Application Request Routing (ARR) for HTML Forms Authentication


How to Configure a CA SiteMinder® Agent to Support HTML Forms Authentication

To configure CA SiteMinder® to validate user identities using HTML Forms authentication, the policy administrator and agent owner must both perform configuration processes. This scenario describes the process that an agent owner must perform when a policy administrator informs you that HTML Forms authentication support is required on one or more agents.

Note: For more information about how the policy administrator configures HTML Forms authentication, see the companion scenario: Configure HTML Forms Authentication.

Master process for configuring Policy Server and agents for HTML Forms authentication

  1. Configure basic FCC authentication
  2. Map URLs for FCC redirects on Domino web servers
  3. Configure POST preservation
  4. Configure advanced FCC settings
  5. Tune the performance of the FCC
Configure Basic FCC Operation

Perform some basic configuration procedures to configure the Forms Credential Collector (FCC) component of any agent that secures resources that are protected by an HTML Forms authentication scheme.

  1. Configure a MIME type mapping for the FCC if you are using an IIS web server or a Domino web server.

    Note: The agent configuration wizard automatically sets up the proper MIME types that CA SiteMinder® credential collectors use for the following types of web servers:

  2. Map your agent identities and web servers for use by FCCs.
  3. Configure the following additional settings, as required:
Configure a MIME Type Mapping for the FCC on IIS and Domino Web Servers

On IIS and Domino web servers, specify the FCCExt agent configuration parameter to configure a MIME type mapping for the FCC in your Web Agent configuration. The MIME type mapping is represented as a file extension. We recommend using the default value.

FCCExt

Specifies a MIME type mapping for the FCC.

Default: .fcc

Limits: A valid file extension.

Example: .myfcc

Note: If you do not want to use the default extension or the default is already in use, enter the extensions that you want instead. For example, if you set FCCExt to .myfcc for the FCC, and rename the FCC template to use this extension (such as login.myfcc), the agent recognizes URLs ending in .myfcc as HTML Forms authentication requests.

Enable FCCs and SCCs to Use Agent Names as Fully Qualified Host Names

To enable the forms and SSL credential collectors to use the fully qualified host name of the target URL as an Agent name, define the AgentNamesAreFQHostNames configuration parameter.

For example, if the AgentNamesAreFQHostNames parameter is set to Yes, the www.nete.com portion of the following URL string serves as the Web Agent name:

url?A=1&Target=http://www.nete.com/index.html

The credential collector uses this parameter in the following situations:

If the AgentNamesAreFQHostNames parameter is set to No, the credential collector uses the value of the DefaultAgentName parameter as the name of the target Web Agent.

Configure the FCC to Use a Single Resource Target

To configure the FCC to direct users to a single resource, hard-code the target in the login.fcc template file.

Follow these steps:

  1. Open the login.fcc file, which is located in agent_home/Samples.
  2. Add @target=target_resource to the FCC.
  3. Add the following entry:

    @smagentname=agent_name_protecting_resource

    For example: @smagentname=mywebagent

  4. Set the EncryptAgentName parameter to no. This parameter is required because no method exists to encrypt the agent name after you hard code it in the file.
  5. Set the EncryptAgentName to no for any other agent using this FCC.

Note: For more information, see the Policy Server documentation.

Use a Relative Target for Credential Collector Redirects

Optionally, instruct an agent to use a relative URI instead of a fully qualified URL when directing requests to a credential collector and target resource. Using a relative URI prevents credential collectors on other systems with Web Agents from processing requests.

Note: This setting applies to all credential collectors except the cookie credential collector (CCC). The CCC must use a fully-qualified domain name for this parameter. OnAuthAccept responses will not work properly with a CCC if a relative URI is used.

Typically, a fully qualified URL is appended to the credential collector URL. For example:

url?A=1&Target=http://www.nete.com/index.html.

To use only a relative URI, set the TargetAsRelativeURI parameter to yes. If set to yes, the target parameter that is appended to the credential collector URL is a relative target, such as url?A=1&Target=/index.html. In turn, when the credential collector redirects back to the Web Agent protecting the target resource, it is a relative redirect. Also, the Web Agent rejects any target that does not begin with a forward slash (/).

The default value for this parameter is no, so a fully qualified URL is always used.

Define Valid Target Domains

To configure CA SiteMinder® Agents to help protect your resources from phishing attempts that could redirect users to a hostile website, set the following configuration parameter:

ValidTargetDomain

Specifies the domains to which a credential collector is allowed to redirect users. If the domain in the URL does not match the domains set in this parameter, the redirect is denied.

Default: No.

All advanced authentication schemes, including forms credential collectors (FCCs) support this parameter.

The ValidTargetDomain parameter identifies the valid domains for the target during processing. Before the user is redirected, the agent compares the values in the redirect URL against the domains in this parameter. Without this parameter, the agent redirects the user to targets in any domain.

The ValidTargetDomain parameter can include multiple values, one for each valid domain.

For local Web Agent configurations, specify an entry, one entry per line, for each domain, for example:

validtargetdomain=".xyzcompany.com"
validtargetdomain=".abccompany.com"
Define Valid Federation Target Domains

If CA SiteMinder® is acting as a legacy federation SP, you can configure the Identity Provider Discovery (IPD) profile for SAML 2.0 transactions. IPD lets a user select which IdP generates an assertion for an authentication request.

During the discovery process, you can prevent a user from being redirected to a malicious website. Configure the Web Agent to validate the domain of the IdP that satisfies the authentication request.

To enable the validation process, set the value of the following parameter:

ValidFedTargetDomain

(Federation only–SAML 2.0). Lists all valid domains for your federated environment when implementing Identity Provider Discovery.

When the CA SiteMinder® Identity Provider Discovery (IPD) Service receives a request, it examines the IPDTarget query parameter in the request. This query parameter lists a URL where the Discovery Service must redirect to after it processes the request. For an IdP, the IPDTarget is the SAML 2.0 Single Sign-on service. For an SP, the target is the requesting application that wants to use the common domain cookie.

Federation Web Services compares the domain of the IPDTarget URL to the list of domains specified for the ValidFedTargetDomain parameter. If the URL domain matches one of the configured domains in the ValidFedTargetDomain, the IPD Service redirects the user to the designated URL in the IPDTarget parameter. This redirect is to a URL at the SP.

If there is no domain match, the IPD Service denies the user request and they receive a 403 Forbidden in the browser. Additionally, errors are reported in the FWS trace log and the affwebservices log. These messages indicate that the domain of the IPDTarget is not defined as a valid federation target domain.

If you do not configure the ValidFedTargetDomain setting, no validation is done and the user is redirected to the target URL.

Limits: Valid domains within the federated network

Default: No default

Specify a valid domain in the ValidFedTargetDomain parameter. This setting is a multivalue parameter, so you can enter multiple domains.

If you are modifying a local configuration file, list the domains separately, for example:

validfedtargetdomain=".examplesite.com"

validfedtargetdomain=".abccompany.com"

For more information about the Identity Provider Discovery profile, see the Federation Security Services Guide.

Map URLs for FCC Redirects with a Domino Web Agent

To protect Domino view (.nsf) resources with a forms authentication scheme, map the URLs before they are redirected to the forms credential collector.

Follow these steps:

  1. Set the value of the DominoNormalizeUrls parameter to yes.
  2. Set the value of the DominoMapUrlForRedirect parameter to yes.

    Domino URLS are mapped before redirection to the FCC.

Configure POST Preservation

CA SiteMinder® automatically preserves the data that a user posts to an FCC form. This preservation mechanism prevents the data on the form from loss if a timeout or other interruption occurs during the POST operation.

If you are using a combination of traditional and framework agents in your environment, the following additional configuration steps are required:

If you do not want to use POST preservation, you can disable it.

POST preservation is not supported in the following situations:

Enable Post Preservation between Framework and Traditional Agents

Framework Agents handle POST preservation data differently than Traditional Agents do. If your CA SiteMinder® environment uses a combination of Framework and Traditional agents, and resources hosted by one type of Agent are protected by Forms Credential Collectors (FCCs) hosted on the other type of agent, you must specify the proper template file with the following parameter:

PostPreservationFile

Enables the transfer of POST preservation data between Traditional and Framework Agents by specifying the path to one of the following POST-preservation-template files:

Default: No default

Example: web_agent_home/samples/forms/fw2tr.pptemplate

To enable post preservation between Framework and Traditional agents

  1. Determine which resources are protected by FCCs running on a different type of Agent.
    1. Create a list of Traditional Agents hosting resources that are protected by FCCs running on Framework Agents.
    2. Create a list of Framework Agents hosting resources that are protected by FCCs running on Traditional Agents.
  2. For any traditional Agents hosting resources (those you listed previously in step 1a), set the value of the PostPreservationFile parameter to the path of the tr2fw.pptemplate file.
  3. For any Framework Agents hosting resources (those you listed previously in step 1b), set the value of the PostPreservationFile parameter to the path of the fw2tr.pptemplate file.
  4. For all of your Framework Web Agents that communicate with Traditional Agents, set the value of the following parameter to yes:
    LegacyPostPreservationEncoding

    Specifies whether the Web Agent encodes any POST preservation data in a way that is compatible with the older, Traditional, Web Agents, or with the newer, Framework Web Agents. When the value of this parameter is set to yes, the encoding is compatible with the Traditional Web Agents. When the value of this parameter is set to no, the encoding is compatible only with the Framework Web Agents.

    Default: No

  5. Restart the web servers hosting your resources.

    POST preservation is between Framework and Traditional agents is enabled.

Customize the POST Preservation Page

When a timeout or other interruption occurs during a POST operation, the POST preservation page is displayed. In most cases, the POST preservation page appears for less than a second. However, the Post Preservation page can be displayed for as long as 5 seconds when the amount of form data being posted is large.

By default, the POST preservation page displays the following text:

This page is used to hold your data while you are being authorized for your request. You will be forwarded to continue the authorization process. If this does not happen automatically, please click the Continue button below.

The POST preservation page also displays a Continue button that allows the user to repost the data to the application.

To customize the POST preservation page, create a POST preservation template file.

The general structure of the default page is as follows:

<HTML><HEAD><TITLE></TITLE></HEAD><BODY onLoad="document.AUTOSUBMIT.submit();">
This page is used to hold your data while you are being authorized for your request.<BR><BR>
You will be forwarded to continue the authorization process. If this does not happen automatically, please click the Continue button below.
<FORM NAME="AUTOSUBMIT" METHOD="POST" ACTION="$$smpostlocation$$">
<$$smpostdata$$>
<INPUT TYPE="SUBMIT" VALUE="Continue">
</FORM></BODY></HTML>

The POST preservation template must include the following two elements which the Web Agent expands when rendering the POST preservation page:

$$smpostlocation$$

Expanded to the credential collector URL during the first phase of POST preservation. Expanded to the protected resource URL during the second phase of POST preservation.

$$smpostdata$$

Expanded to contain HTML which results in the correct form data being posted to either location respective to the phase of POST preservation.

Do not remove or alter these elements.

However, you can change other elements. For example, to remove the Continue button, remove the <INPUT> element that defines that button:

<INPUT TYPE="SUBMIT" VALUE="Continue">

Two sample POST preservation template files, fw2tr.pptemplate and tr2fw.pptemplate, are included in the following location:

To configure the Web Agent to use your POST preservation template file, define the PostPreservationFile agent configuration parameter to specify the path of the template file.
For example:

PostPreservationFile="/app/netegrity/webagent/samples_default/forms/nosubmitbutton.pptemplate" 
Disable POST Preservation

If you do not need to use POST preservation, you may disable it with the following parameter:

PreservePostData

Specifies whether the Web Agent preserves POST data when redirecting requests. When the user is challenged for advanced authentication, such as forms or certificate authentication, the post data is preserved during the authentication phase.

Default: Yes

To disable POST preservation, set the value of the PreservePostData parameter to no.

Configure Advanced FCC Settings

You can configure any of the following advanced credential collector settings to suit your needs:

Specify Redirect URL Protocols with Lowercase Characters

If you protect legacy applications that do not confirm to RFC 2396 with a forms-based authentication scheme, and you need the protocol portions of URLs to be lowercase, then set the following parameter:

LowerCaseProtocolSpecifier

Specifies whether the scheme (protocol) portion of a redirect URL uses only lowercase characters. This configuration parameter accommodates legacy applications that do not confirm to RFC 2396. This RFC states that applications must handle the protocol portion of a URL in both uppercase and lowercase. Change this parameter in any of the following situations:

Default: No (uppercase characters are used HTTP, HTTPS).

Example: Yes (lowercase characters are used http, https).

To specify lowercase protocols for the URLs in your environment, set the value of the LowerCaseProtocolSpecifier parameter to yes.

Encrypt Query String Parameters in Redirection URLs

The following parameter enables the Web Agent to encrypt all CA SiteMinder® query parameters in a redirect URL:

SecureURLs

Specifies whether the Web Agent encrypts the CA SiteMinder® query parameters in a redirect URL. You can use this setting to provide additional security for requested resources protected by an advanced authentication scheme, Password Services, or when a request invokes the Cookie Provider.

Important! The Web Agent only encrypts data sent between CA SiteMinder® components. The data sent for redirects to non-CA SiteMinder® applications is not encrypted.

The following CA SiteMinder® credential collectors and applications support the SecureUrls functionality:

Default: No

Follow these steps:

  1. Set the value of the SecureURLs parameter to yes.
  2. To encrypt query string parameters in redirection URLs within a single sign-on environment, ensure that all Web Agents in the single sign-on environment have the SecureURL parameter set to the same value.
  3. If you are using custom FCCs, add the smquerydata directive with the other FCC directives (such as TARGET) to the custom FCC.

    Query string parameters are encrypted in CA SiteMinder® redirection URLs.

FCC Directive for Encoding Query Strings of Redirect URLs

You can encrypt the query strings of redirect URLs for credential collectors. The credential collectors provide the keys that are used to encrypt the query data.

For forms authentication schemes, the query string directive, smquerydata, is part of the FCC template. The agent serving the FCC uses this directive to send the encrypted query data to the target agent when the FCC is posted.

The following directive is used:

<INPUT type='hidden' name='smquerydata' value='$$smquerydata$$>

Note: If you are using custom FCCs, add the smquerydata directive with other FCC directives, such as TARGET to the custom FCC.

CA SiteMinder® 12.52 agents with the SecureUrls parameter enabled can operate only with credential collectors served from other agents that support this functionality.