Post data preservation and restoration functions apply to both credential collectors (ECC or DCC).
This section provides the following topics:
POST data preservation and restoration functions come into play when an application has a form wherein the user has entered a credential (or other data) but the session has expired, an idle session timeout has occurred, or the token validity period has ended by the time the user submits the form. If this scenario occurs, the user is presented with a fresh login form (depending on the authentication scheme) unless POST data is preserved and restored.
Administrators can configure the Resource Webgate to perform POST data preservation when the expired user and newly authenticated user are the same. Table 22-31 describes Resource Webgate support and behavior for post data.
Note:
Authentication POST data preservation and restoration is not supported when Access Manager performs authentication through custom agents.
Table 22-31 Resource Webgate Support of POST Data Preservation and Restoration
| Resource Webgate | Description |
|---|---|
|
Supports Authentication Schemes |
LDAP, Basic, Sessionless Basic, X509, WNA |
|
Supports form encoding |
with text/html, text/plain, multipart/form-data, and application/x-www-form-urlencoded type data posted by the application form. |
|
Preserves |
The encoding type of the data posted by the original application form, except the input field of file type. |
|
Ensures |
The downstream application sees the same post data that was posted by the original application form. |
|
Constrains |
The overall size of the inbound request data or the inbound front channel message. There shall be a configuration parameter to override the code default value. This shall be per application. |
|
Maintains application data confidentiality and integrity |
Neither the Resource Webgate nor credential collector will interpret, nor log, application post data. If, after expiration and during re-authentication, the user authenticates with different credentials, then the post data of the previous user is cleared by the Resource Webgate and not restored. However, Webgate will post to the downstream application URL that was posted by the original application form. |
|
Ignores Preservation if ... Logs a Message when ... Performs Standard Authentication if ... Shows an Error when ... |
Post data is larger than the configured or hard-coded limit, preservation is ignored. Post data is skipped because it is bigger than the allowed limit, a message is logged. Post data size is larger than the hard-coded limit (or the configured value), the standard authentication flow is used. Together, if both front channel message data and application post data are large an error occurs. |
Credential Collector Support for POST Data Handling
ECC and DCC
Compatible with earlier 11g Webgates
Supports post data preservation for Form based authentication scheme with the default login form provided out of the box.
Preserves application post data during authentication processing by:
Challenging the user
Re-challenging the user if invalid credentials are provided
Does not interpret application post data.
Constrains the overall size of inbound front-channel messages using a configuration parameter to override the default value, per application.
Logs a warning when post data is skipped because it is larger than the allowed limit.
Does not preserve application post data when:
Authentication policy is configured with Success or Failure authentication URLs
Password management (password expiration and so on) is involved
Access Manager is used for performing authentication through custom agents.
ECC Only
The embedded credential collector does not support POST data handling with the external login page.
DCC Only
POST data is preserved through the HTTP header, and the amount of POST data that can be handled to 8192 characters.
POST data restoration with a Form-based Authentication Scheme requires the challenge parameter TempStateMode=form.
DCC does not support custom login pages.
DCC does not support POST data restoration during password management operations (password expiration, for instance) when the URL_ACTION in the password policy plug-in is set to anything other than FORWARD.
Authentication Schemes such as WNA, Basic and X509 are supporting POST Data Handling.
FORM challenge method, supported with the out of the box login page.
WNA
Basic
Basic+Sessionless
X509
OIF, OIM, OAAM integrations using TAP
Table 22-32 summarizes complete configuration requirements for authentication POST data handling. All requirements described in Table 22-32 are supported end to end with the specified authentication schemes.
Table 22-32 Parameters Required for Authentication POST Data Handling
| Parameter | Description |
|---|---|
|
MaxPostDataBytes |
Configure this Authentication Scheme challenge parameter for POST-data preservation used by the DCC only to limit the maximum size of the POST data that can be posted as on the login form. DCC compares the value of the content-length header with the limit set. Default: unlimited This Authentication Scheme challenge parameter requires a positive integer value that restricts the maximum number of bytes of POST data that is submitted as user credentials and sent to the OAM Server. |
|
MaxPreservedPostDataBytes |
Configure this Authentication Scheme challenge parameter (or user-defined Webgate parameter) for authentication POST-data preservation. Default: 8192 bytes Note: Preference is given first to the Authentication Scheme containing this parameter; second to the Webgate providing this user-defined parameter. Otherwise, default behavior is 8192 bytes. This parameter defines the maximum length of POST data that Webgate can preserve. If the size of inbound raw user POST data (or encrypted post data after processing), crosses this limit, POST data is dropped and the existing authentication flow continues. The event is logged as usual. See Also: "Configuring Authentication POST Data Handling" |
|
TempStateMode=form DCC Only |
With the DCC, a Form-based Authentication Scheme requires the challenge parameter TempStateMode=form for POST data restoration For Form authentication scheme, if this parameter is not defined, the value will be "form". See Also: "Configuring Authentication POST Data Handling" |
|
ChallengeRedirectMaxMessageBytes |
Configure this user-defined Webgate parameter to limit the size of the message data received as obrareq.cgi and obrar.cgi. Message data is comprised of query string length (if present) or POST data length (if POST data is present). If message size exceeds this limit, the message is not processed and the existing message is shown in the browser. The event is logged as usual. Default: 8192 bytes Notes: obrareq.cgi is the authentication request in the form of a query string redirected from Webgate to the credential collector (OAM Server or DCC). obrar.cgi is the authentication response string redirected from the credential collector (OAM Server or DCC) to Webgate. See Also: "Configuring Authentication POST Data Handling" |
|
PostDataRestoration |
Configure this user-defined Webgate parameter to initiate authentication POST-data preservation for the resource Webgate. This parameter requires a value of Default: When set to See Also: "Configuring Authentication POST Data Handling" |
|
serverRequestCacheType ECC Only |
Configure this OAM parameter to define the mechanism used to remember the request context by the embedded credential collector (ECC). This OAM Server parameter in $DOMAIN_HOME Default: COOKIE FORM is the required value for POST data preservation, Long URL handling and Form-based authentication schemes. See Also: |
Assuming the usual form data entered by users is about several kilobytes, putting a limit on data comsumption from the incoming request is a general requirement. The data transferred in the front channel protocol (either request or response) must also go through the size check.
Considering these situations:
Limit the size of data passed to the OAM Server on the back channel using the maxpostdatabytes authentication challenge parameter
In cases where the DCC is used, the maxpostdatabytes authentication challenge parameter performs this check on the overall POST data.
Limit the size of the POST data from the end user application using MaxPreservedPostDataBytes authentication scheme challenge parameter.
The MaxPreservedPostDataBytes authentication scheme challenge parameter handles this. Additionally, this can be set as a user-defined Webgate parameter.
Limit size of the front channel payload on obrar.cgi or obrareq.cgi with a Webgate user-defined parameter ChallengeRedirectMaxMessageBytes.
Be sure to read all POST data topics in this section before attempting this procedure. There is no need to make any explicit change in your authentication scheme.
Configure the Authentication Scheme:
Use the Oracle Access Management Console to create or find the desired scheme (Authentication POST Data Handling).
On the Authentication Scheme page, modify values for POST data handling.
This example uses the embedded credential collector (Table 22-20) and values for POST data handling (Table 22-23):
| Authentication Scheme Challenge Parameters for Post Data with ECC | Authentication Scheme Challenge Parameters for Post Data with DCC |
|---|---|
|
|
Click Apply to submit the changes.
ECC: Configure serverRequestCacheType, the OAM parameter in oam-config.xml, if using ECC.
Stop the managed server.
Stop the administration server.
Open oam-config.xml and modify the value of serverRequestCacheType.
Save the file.
Restart the administration server.
Restart the managed server.
Configure Webgate Parameters for POST data handling:
From the System Configuration tab, Access Manager section, create or find the desired OAM Agent registration.
On the agent registration page, submit values for POST data handling (Table 22-23):
| User-Defined Webgate Post Data Parameters with ECC | User-Defined Webgate Post Data Parameters with DCC |
|---|---|
|
|
Click Apply to submit the changes.