This section contains the following topics:
Apply CA SiteMinder® Behavior to a Web Application Client
Modify the Session Grace Period
Modify the Session Update Period
Protect Session Cookies from Misuse with Validation Periods and Expired Cookie URLs
Prevent Session Cookie Creation or Updates
Prevent Session Cookie Creation or Updates Based on Method and URI
Store Session Cookies on the Session Store for Improved Security
Validate a Session Cookie Domain
Redirect a User after a Session Time-out
How to Enforce Timeouts across Multiple Realms
Prevent Re-Challenges After Realm Timeouts When Multiple Valid Sessions Exist
How to Link a Client Certificate to a CA SiteMinder® Session (Windows)
How to Link a Client Certificate to a Session (UNIX)
Some web applications use script engines, which execute in the context of a web browser, to request resources and display content. Similar to requests standard web browsers send, the requests originating from the script engine can trigger CA SiteMinder® generated behavior, such as HTTP redirects or challenges.
Unless properly integrated with the web application, this behavior can result in the web application client reaching an indeterminate state.
The web application client response (WebAppClientResponse) ACO parameter lets you:
Note: If you are using the WebAppClientResponse parameter to integrate the session management features ofCA SiteMinder® (such as idle or session timeouts), configure the OverLookSessionFor ACO parameter also.
While the OverLookSessionFor parameters prevent web application client requests from keeping user sessions active indefinitely, the WebAppClientResponse parameter lets you integrate the required CA SiteMinder® functionality to redirect users after a session timeout.
You use the WebAppClientResponse ACO parameter to implement the functionality of the web application client, while maintaining CA SiteMinder® security.
The parameter is comprised of the following default attributes:
Resource=|Method=|Status=|Body=|ContentType=|Charset=
Consider the following factors:
Example: WebAppClientResponse ACO parameter
The example shows the parameter with a valid value for each attribute. A description of each attribute follows the example:
WebAppClientResponse:Resource=/web20/dir/*|Method=GET,POST|Status=200
|Body=C:\location\custombody_1.txt|Content-Type=application/xml|Charset=us-ascii
Specifies the URI to which the web application client is making requests. If the URI of a request matches this value, CA SiteMinder® identifies the request as originating from the web application client. The resource can contain a wildcard (*) for prefix and suffix matching.
Default: No value. If this value is omitted, all resources that the Web Agent is protecting apply to the parameter.
Limit: Regular expressions are not supported.
Example: Resource=/web20/dir/*
Example: Resource=/web20/dir/*.xml
Specifies the HTTP method with which the web application client is making the request. If the HTTP method of a request matches this value, CA SiteMinder® identifies the request as originating from the web application client.
Default: No value. If this value is omitted, the parameter applies all HTTP methods.
Separate multiple methods with a comma (,).
Example: GET, POST
Specifies the HTTP status that CA SiteMinder® must send back to the web application client request.
Default: No value. If this value is omitted, an HTTP status of 200 applies to the parameter.
Specifies the fully qualified name of the file containing the custom body that is to function as the response to the web application client request. This file resides on the Web Agent host system and can:
Default: No value. If this value is omitted, CA SiteMinder® forwards the response to the web application client without a body.
Specifies the MIME type of the data present in the file that contains the response.
Default: No value. If this value is omitted, a MIME type of text/plain applies to the parameter.
If the custom body contains CA SiteMinder® generated responses, the content type of the data must be one of the following types:
Specifies the character set of the data present in the body file.
Default: No value. If this value is omitted, the parameter applies a character set type of us–ascii.
Considering the following factors when setting the WebAppClientResponse parameter:
Applying the web application client response with a web application lets you implement the functionality of the web application client, while maintaining CA SiteMinder® security. Complete the following steps to apply the web application client response:
To configure a web application client response.
Note: Consider the following limitations:
The application owner configures a customized response in the body of a file that resides on the Web Agent host system. When a web application client request triggers CA SiteMinder® functionality, the Web Agent returns the body as a response to the web application client.
Consider the following factors:
If the response is to include a CA SiteMinder® generated behavior:
SiteminderReason=$$Reason$$ SiteminderRedirectURL=$$URL$$
CA SiteMinder® parses the body for these values and inserts the triggered CA SiteMinder® functionality and redirect URL. The following parameters or policy response types define the functions and URLs:
Example: Suppose that a web application client request triggers an idle timeout. CA SiteMinder® replaces the placeholder values with IdleTimeoutURL and the URL specified in the value of the IdleTimeoutURL parameter.
If the custom response includes a CA SiteMinder® reason and redirect URL, configure the web application separately to handle the custom response.
The Web Agent installation wizard installs sample applications in web_agent_home/samples. Extrapolate from the samples for your specific environment and situation.
Specifies the Web Agent installation path.
Web pages usually consist of many resources, all of which are potentially protected by the Web Agent. For each resource associated with a single request, a session cookie is generated. To eliminate the overhead of generating multiple session cookies for a single user request, set the following parameter:
Specifies the number of seconds during which a CA SiteMinder® session (SMSESSION) cookie will not be regenerated. Cookies are not regenerated when all of the following conditions are met:
Default: 30
To modify the session grace period
The session grace period is changed.
Note: Session timeouts are part of configuring a realm, which you do using the Administrative UI. For further instructions on configuring session timeouts, see the Policy Server documentation.
You can specify how often the Web Agent redirects a request to the Cookie Provider to set a new cookie with the following parameter:
Specifies how often (in seconds) a Web Agent redirects a request to the Cookie Provider to set a new cookie. Refreshing the master cookie decreases the possibility that it will expire due to an idle time-out of the CA SiteMinder® session.
Default: 60
To modify the session update period
The session update period is changed.
CA SiteMinder® uses time-based session cookie parameters that can substantially reduce the possibility of a CA SiteMinder® session cookie being compromised by administrators or other users who have access to the following items:
These time-based session cookie parameters add the concept of "born dates" to session cookies. Agents receiving a session cookie as a result of a redirect (URL session cookie) will look for the cookie born date name/value pair and compare this value with the value set for the CookieValidationPeriod configuration parameter. If the value of the born date and the CookieValidationPeriod parameter value exceed the current time, the cookie is rejected.
To protect session cookies from misuse, set the following parameters:
Specifies the time period (in seconds) in which the receiving agent will accept the session cookie. After this time passes, the session cookie will not be accepted. If this field is not used or is set to zero, the session cookie expires when the Idle Timeout and Max Session Timeout values are met.
Default: Empty.
(Optional) Specifies a URL that the agent redirects the user to after any session cookie has expired. If neither the born date nor the CookieValidationPeriod are configured, the agent ignores the settings and processes the cookie as usual (backwards compatibility).
Some Web applications, such as Microsoft Outlook Web Access, make HTTP requests behind the scenes even when a user is not actively using the application. For example, the Web Access application makes HTTP requests even when the user is not actively checking for new email on the server.
These requests may update the SMSESSION cookie so that the session never expires, even though the user has been idle. You can prevent the Web Agent from creating or updating session cookies during these background requests so that sessions expire normally.
Configure the following parameters:
Specifies whether the Web Agent compares the request method of all HTTP requests against the methods listed in this parameter. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
Default: No default
Specifies whether the Web Agent compares the URLs from all HTTP requests against the URLs listed in this parameter. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
Default: No default
Example: Use a relative URL, such as /MyDocuments/index.html. Do not use an absolute URL (http://fqdn.host/MyDocuments/index.html)
Note: If you configure both of the previous parameters, the methods are processed before the URLs.
If enabled, the Web Agent does not create cookies for any of the URLs under the directory that is specified in OverlookSessionForUrls.
Default: No
Values: Yes, No
Example: If you specify /siteminder in OverlookSessionForUrls and if you set OverlookSessionAsPattern to Yes, then cookies are not generated for any /siteminder/* requests.
Some Web applications, such as Microsoft Outlook Web Access, make HTTP requests behind the scenes even when a user is not actively using the application. For example, the Web Access application makes HTTP requests even when the user is not actively checking for new email on the server.
These requests update the SMSESSION cookie so that the session never expires, even though the user has been idle. You can prevent the Web Agent from creating or updating session cookies during these background requests so that sessions expire typically.
To prevent creation or updates based on method and URI
Specifies whether the Web Agent compares the request method of all HTTP requests against the methods listed in this parameter. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Also, cookie providers (if configured) are not updated for that request.
Default: No default
Specifies whether the Web Agent compares the method and the URI from all HTTP requests against the method and URI listed in this parameter. If a match occurs, the Web Agent does not create or update an SMSESSION cookie. Cookie providers (if configured) are not updated for that request.
Default: No default.
Limits: Specify a relative URI
Example: POST, /directory/file prevents updates to the SMSESSION cookie for POST requests to /directory/resource.
Note: Methods are processed before URIs.
Session cookies are stored on the client computer of the end user. You can increase the security of your environment by having CA SiteMinder® create session cookies that are stored in the CA SiteMinder® session store. Storing session cookies in the CA SiteMinder® session store prevents anyone with access to the following items from copying a session cookie from a client computer and then attempting a replay attack:
You can control where CA SiteMinder® stores its session cookies by setting the following parameter:
Specifies whether session cookies are stored on the client computer, or in the CA SiteMinder® session store. When the value of the StoreSessioninServer parameter is yes, a session cookie is created and stored on the session store. Cookie providers and Web Agents access the cookie from the session store.
Cookie providers and Web Agents replace the session cookie in a URL with a GUID that corresponds to the session cookie stored on the session store.
When the value of the StoreSessioninServer parameter is no, the session cookie is passed directly in the URL.
Default: No
Follow these steps:
You can reduce the risk that unauthorized users may hijack and attempt to reuse CA SiteMinder® session cookies by having CA SiteMinder® validate the domain of a session cookie with the following parameter:
Instructs the Web Agent to encrypt and store the intended domain of a session cookie within the session cookie itself. During subsequent requests, the Web Agent compares the intended domain stored within the session cookie against the domain of the requested resource. If the domains do not match, the Web Agent rejects the request.
For example, when the value of this parameter is set to yes, session cookies intended for operations.example.com are rejected when presented at finance.example.com.
In CA SiteMinder® environments using SSO, set this parameter on the Web Agent that creates the encrypted session cookie. For example, suppose your SSO environment has domains named a.example.com and b.example.com. If the Web Agent protecting a.example.com encrypts the session cookie, set the value of the TrackSessionDomain parameter of the associated Web Agent. When the Web Agent protecting b.example.com receives the cookie, it compares the intended domain stored in the cookie against the domain of the requested resource.
Default: No
To have CA SiteMinder® validate the domain of a session cookie, set the value of the TrackSessionDomain parameter to yes.
Session time-outs are set when you configure a realm with the Administrative UI. When a user’s CA SiteMinder® session times out, the Web Agent does one of the following actions:
If a redirect URL is specified, the user is sent to that destination page. If the page is unprotected, the user is granted direct access to that page. If the page is protected, the user is challenged for credentials before being granted access to the page. If no redirection URL has been specified, the Web Agent rechallenges the user for credentials after a session time-out.
You can redirect users whose sessions time out to a URL with a customized web page, which explains why their session has been terminated and how they can reestablish it. For example, you can create a custom web page that displays a message such as, "You have been logged out automatically as a security precaution. Please login again to continue."
If the user is not redirected to another page after a session times out, CA SiteMinder® challenges the user again. This may confuse users because they may not understand why they are being asked to reauthenticate.
To redirect users to different URLs after session time-outs
Specifies the URL where the Web Agent should redirect the user when the idle time-out for the session occurs.
Example: http://example.mycompany.com/sessionidletimeoutpage.html
Note: IdleTimeoutURL should only be used for non-persistent sessions; it has no effect if configured for persistent sessions.
Specifies the URL where the Web Agent should redirect the user when the maximum time-out for the session occurs.
Example: http://example.mycompany.com/maxtimeoutpage.html
Default: No default
If the idle timeout and maximum timeout values for a session (set in the Policy Server) occur at the same time and the IdleTimeoutURL and MaxTimeoutURL parameters are set, the user is redirected to the URL specified in the MaxTimeoutURL parameter when a time-out occurs.
User session timeouts are governed by the realm that the user first logs into. If a user enters a new realm through single sign-on, the time-out values for the new realm are still governed by the session that was established by the initial login at the first realm. If you have different time-out values for different realms, and you want to have each realm use its own time-out values, you can override the time-outs of the original realm.
A user who has already timed out cannot log in to another realm without being rechallenged. For example, if the Idle Timeout in Realm1 is 15 minutes and the Idle Timeout in Realm2 is 30 minutes, a user who accumulates 20 idle minutes in Realm1 will be challenged upon logging in to Realm2.
To override the time-outs of the original realm, configure your Web Agent and realms as described in the following process:
Note: For information about creating responses, see the Policy Server Configuration Guide.
The previous versions of CA SiteMinder® automatically re—challenged users for their credentials when a realm timeout occurred. This challenge occurred even when multiple sessions existed on the Policy Server.
This version offers an option of having the Policy Server examine all of the sessions in its list before challenging the user.
The following parameter controls this option:
Specifies whether the Policy Server challenges users for their credentials after a realm timeout occurs. This challenge occurs because the first session in the Policy Server expires. The Policy Server does not examine the other associated sessions in its list. When the value of this parameter is yes, the Policy Server checks only the first session in the list. Then the user is challenged. When the value of this parameter is no, the Policy server checks all the sessions in its list before challenging users.
Default: No (all sessions are checked upon a realm timeout)
To examine only the first session in the list when a realm timeout occurs, change the value of the compatRealmtimeouts parameter to yes.
|
Copyright © 2013 CA.
All rights reserved.
|
|