A first look at POST data preservation in OAM 11g R2 PS1

In this post, we have a quick look at POST data preservation, a new feature introduced in the 11g R2 PS1 (or 11.1.2.1) version of Oracle Access Manager. We'll explain the problem that this feature solves and walk through a simple example explaining how to configure and use the feature. This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

The problem we're trying to solve

Whenever an application URL is protected by an OAM Webgate, the Webgate will intercept any request to said URL in order to ensure that a valid OAM session exists. Should the Webgate determine that there is no valid session (for instance, in the case of a session time-out), then the user will be redirected for authentication prior to to URL being served. This process is seamless from the perspective of the application, in most cases, unless the request that necessitates re-authentication contains POST data. Consider the following example:

 Imagine an incredibly simple web application, comprising a single JSP page containing an input form and a servlet to display the values submitted on the form. The screenshots below demonstrate the working of such an application:

As you can see, this really is about the simplest web app it's possible to imagine and I'm sure its construction doesn't need any further detailed discussion.  Now imagine that we apply an OAM protection policy to the application and simulate a session timeout before the form can be submitted.  (I have done this by destroying the session from the OAM Console). Note that the POST data entered on the form is not preserved during the authentication redirect, as shown below:

To clarify what the above diagram depicts, we simulate a session timeout before the "Submit" button on the form can be clicked. The user is thus prompted for re-authentication prior to the HTTP POST to the servlet but during this process, the POST data (i.e the form input values) are lost. This is clearly not ideal from a usability point of view and could potentially negatively impact application functioning as well - were it to happen in the middle of a multi-page transaction, for example.

How to preserve POST data

It turns out that enabling POST data preservation in OAM 11gR2 PS1 can be a very simple exercise. While the documentation (which I strongly encourage reading) does go into a lot of detail regarding a number of different settings and options, the goal here was to do "the simplest thing that works", in order to make a sort of general purpose recommendation that can be refined further as needed.

The usual caveats about varying mileage do apply, of course and in particular, additional configuration may be required if dealing with particularly large POST payloads or when using custom login pages or detached credential collectors.

The configuration below was tested against the standard OAM login page with the OAM server's embedded credential collector (ECC) and an OHS 11g Webgate. All that was required in this case to enable POST data preservation was to set a single user-defined parameter on the Webgate configuration, as shown below.

As is shown above, the parameter

PostDataRestoration=true

was added to the Webgate configuration. Once the regenerated ObAccessClient.xml file was copied to the Webgate configuration directory, it all worked as expected.