Web Agent ACO SessionUpdatePeriod and PostPreservation message
search cancel

Web Agent ACO SessionUpdatePeriod and PostPreservation message


Article ID: 54212


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On SITEMINDER CA Single Sign On Agents (SiteMinder)



User are receiving the following message in application:

  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




The interim white page that is displayed will occur when
PostPreservation takes place. With a single domain, PostPreservation
takes place only when the SMSESSION is no longer valid however when
there are multiple domains, PostPreservation also takes place when the
cookie in the primary domain needs to be updated in order to maintain
SSO between multiple domains. The ACO parameter "SessionUpdatePeriod"
dictates the frequency that the web agent in the second domain
redirects to update the SMSESSION cookie in the primary domain.

This has the same default value of SessionGracePeriod. If the request
is of a POST method and the Web Agent needs to go talk to the cookie
provider (caused by the secondary cookie is no longer valid or the
SessionUpdatePeriod is updated), then the Web Agent in the secondary
domain will need to speak with the Web Agent in the primary
domain. This is done via a HTTP 302 redirect and as such, in order to
maintain the data, Siteminder must invoke PostPreservation and this
will result in the white page being displayed to the user. If
PostPreservation is disabled, then the data that the user submitted
will be lost and the user will need to resubmit the data before the
SessionUpdatePeriod is exceeded.

When running multiple domains, the following options are availables :

  1. Disable PostPreservation by setting PreservePostData=no in the
     ACO. This would force the users to have to resubmit their POST
     data each time we redirect to the cookie provider (as dictated by
     the SessionUpdatePeriod / validity of the SMSESSION cookie)

  2. Increase the SessionUpdatePeriod so that the Web Agent doesn't
     redirect to the cookie provider as often. However this situation
     will occur if the SessionUpdatePeriod is exceeded. By choosing
     this option, make sure that the SessionUpdatePeriod doesn't
     exceed any idle/max timeouts otherwise there's the chance that
     sessions in the primary domain are in fact expired.

  3. Use a combination of solutions by increasing the
     SessionUpdatePeriod and to avoid the white page that is presented
     when PostPreservation is in effect, the web agent was enhanced to
     allow a custom page to be displayed instead of the white page
     that is displayed by default.

  4. In v5QMR8 and v6QMR5, a new Web Agent parameter was introduced
     called "LegacyCookieProvider". When this parameter is enabled,
     the Web Agent will not go to the cookie provider in case of a
     POST request even if the cookie needs to be revalidated. (Used
     when a framework Web Agent sends a POST request to a traditional
     Web Agent configured as a cookie provider.)

If the white page is aesthetically not pleasing, this white page can
now be replaced with a specified file.

Modify the Session Grace Period

  Web pages are typically made up 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, define a grace period between each cookie generated.

  The SessionGracePeriod parameter allows a grace period, in seconds,
  between the regeneration of SMSESSION cookies. The default grace
  period is 30 seconds.

  The SessionGracePeriod parameter can be modified by entering a
  higher or lower value. When increasing the amount of time, ensure
  the value is not greater than the session or idle timeout value.

  The SMSESSION cookie will not be regenerated if all of the following
  apply to the request:

    - There is no URL SMSESSION cookie.

    - The difference between the current time and the last access time
      of the received SMSESSION cookie is less than or equal to the

    - At least two grace periods must have elapsed between the current
      time and when the received cookie would have been idle.

Modify the Session Update Period

  The SessionUpdatePeriod parameter dictates how often the Web Agent
  should redirect a request to the Cookie Provider to set a new
  cookie. The default period is 60 seconds. Refreshing the master
  cookie decreases the possibility that it will expire due to an idle
  timeout of the Siteminder session. This setting is only valid when
  the CookieProvider parameter has been defined.

Ignore the Cookie Provider for POST Requests (framework agents only).

  When a framework Web Agent sends a POST request to a traditional Web
  Agent configured as a cookie provider, the redirected request
  becomes a GET instead of a POST and fails. To control whether or not
  a POST request is sent to a cookie provider, use the
  LegacyCookieProvider parameter. This parameter is only valid for
  framework Agents. If this parameter is set to NO, which is the
  default, the framework Agent sends the POST request to the cookie
  provider. If this parameter is set to YES, the framework Agent does
  not send the POST request to the cookie provider.


When using central configuration, add this parameter to the Agent
Configuration Object (ACO).