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
below.
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
SessionGracePeriod.
- 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.
Note:
When using central configuration, add this parameter to the Agent
Configuration Object (ACO).