Skip to content
CA Single Sign-On - 12.6.01
Documentation powered by DocOps

Secure a Federated Environment

Last update September 2, 2016

Several mechanisms help secure transactions between federated partners. The following mechanisms are explained in this topic:

Enforcing the One Time Use of an Assertion

Reusing an assertion beyond its validity results in authentication decisions from out-of-date identity information. To prevent reuse, the Policy Server can generate an assertion for one-time use, in compliance with the SAML 1.x and 2.0 specifications. The assertion contains elements that tell the relying party not to retain the assertion for future transactions, preventing problems from reusing an assertion.

If CA Single Sign-On is acting as the asserting party (Producer/IdP), you can configure the one time use of an assertion. For a SAML 1.x producer, you can select the Set DoNotCache Condition setting. For a SAML 2.0 IdP, you can select the Set OneTimeUse Condition setting. Both of these configuration settings enable CA Single Sign-On to insert the proper elements in an assertion that indicate the one-time use condition.

Do not confuse the one time use of an assertion with the single use policy for SAML 1.x and 2.0 HTTP-POST single sign-on. CA Single Sign-On uses the single use policy when acting as the relying party, and it is only for POST transactions. The one time use feature is for HTTP-Artifact and HTTP-POST.

Securing Connections Across the Federated Environment

Identity information that is sent between federated partners or a partner and an application is best protected when communication takes place over a secure connection.

Securing the Connection Between the Relying Party and the Target Application

Secure data transmission from the relying party to the client-site target application. Using a secure connection as the communication channel makes your environment less vulnerable to security attacks.

For example, an assertion can contain attributes that the relying party extracts and sends to the client application. The relying party can pass these attributes to the application using HTTP header variables or cookies. Attributes stored in headers or cookies can be overwritten at the client side, allowing a malicious user to impersonate other users. Using an SSL connection protects an environment from this type of security breach.

As a best practice, protect against this vulnerability by setting the UseSecureCookies parameter in the appropriate Agent Configuration Object (ACO). The UseSecureCookies parameter instructs Federation Web Services to generate cookies that are marked with the "secure" flag. This flag indicates that the cookie is sent only over an SSL communication channel.

Note: The ACO to modify differs depending on the setup of your federation environment. If you deploy Federation Web Services on the same system as the Web Agent is installed, edit the ACO for the Web Agent. If you deploy Federation Web Services on a different system than the Web Agent, edit the unique ACO you created for Federation Web Services.

Securing the Initial Authentication at the CA Single Sign-On Asserting Party

The initial authentication of a user at a CA Single Sign-On asserting party presents a potential vulnerability. When a user first authenticates to establish a user session at the asserting party, a session ID cookie is written to the browser. If the cookie is sent over a non-SSL connection, an attacker can obtain the cookie and can steal sensitive user information. The attacker can then use the information, for impersonation or identity theft.

As a best practice, protect against this vulnerability by setting the Web Agent parameter UseSecureCookies, which you can modify in the Agent Configuration Object. The UseSecureCookies parameter instructs the Web Agent to generate cookies that are marked with the "secure" flag. This flag indicates that the browser passes the cookie only over an SSL connection, which increases security. In general, establishing SSL connections for all URLs is recommended.

Protecting a Federated Network Against Cross-Site Scripting

A Cross Site Scripting (XSS) attack can occur when an application displays input text from a browser. The application can possibly have failed to test for characters that can form an executable script. The display of these characters can lead to an unwanted script being executed on the browser.

CA Single Sign-On provides several JSPs for use with federation functionality. These JSPs check characters in a request to be sure that unsafe information in the output stream is not displayed in the browser.

When CA Single Sign-On receives a request, the following JSPs scan the decoded values for cross-site scripting characters:

  • idpdiscovery.jsp
    Used at the relying party for Identity Provider Discovery.
  • linkaccount.jsp
    Used at the relying party for dynamic account linking.
  • sample_application.jsp
    Used at the IDP to initiate single sign-on. You can use this sample application to direct the user first to the SSO Service and then to the custom web application. Typically, you use your own application.
  • signoutconfirmurl.jsp
    Used at the Account Partner for WS-Federation signout.
  • unsolicited_application.jsp
    Used for IdP-initiated single sign-on when the user is sent directly to the web application and not initially to the SSO Service.

The pages scan the request for the following characters:

Character Description
< left-angle bracket
> right-angle bracket
single quotation mark
double quotation mark
% percent sign
; semi-colon
( open (left) parenthesis
) closed (right) parenthesis
& ampersand
+ plus sign

Each JSP contains a variable that defines the characters to scan. Modify these JSPs to expand the character set.

Safeguard Cookie Information with the HTTP-Only Attribute

To help protect against cross-site scripting attacks, you can protect the contents of cookies that Federation Web Services generates. To enable this protection, set the following Agent Configuration Object (ACO) parameter:

UseHTTPOnlyCookies

This parameter instructs Federation Web Services to set the HTTP-only attribute on the cookies it creates. When a cookie with this attribute is returned to the browser, the contents of the cookie cannot be read by a script, even a script from the web site which originally set the cookie. This helps prevent any sensitive information in the cookie from being sent to an unauthorized third party through a script.

Default: No

To safeguard the information in cookies, set the value of the UseHTTPOnlyCookies parameter to yes.

Note: The ACO to modify differs depending on the setup of your federation environment. If you deploy Federation Web Services on the same system as the Web Agent is installed, edit the ACO for the Web Agent. If you deploy Federation Web Services on a different system than the Web Agent, edit the unique ACO you created for Federation Web Services.
Was this helpful?

Please log in to post comments.