A Challenging Access Policy #Oracle #OAM #IdM

I have a client that I am supporting that has developed a Java application that is to be protected by an Oracle Access Manager (OAM) policy.  It’s a pretty simple scenario … a few URL resources to be protected and a few should be accessible by anyone (anonymous access).  OAM supports this out of the box so I wasn’t really suspecting any issues.  There were no problems until the developer told me that they were testing and found that they were getting prompted for authentication when hitting submit on his form, that is supposed to be “world” readable.  This was strange to me because I had created a Policy Rule that was protecting the URL in the form action.  I checked the URL again (I just hit cancel on the login prompt and copied the URL from the address bar on the browser).  The URL looks like this:

http://app.acme.com/app1/app1InvSecQA.do;jsessionid=5e223425626362633534533d0491cbec15fa725abdd41fcc3e72342352596c4303ad6fe1

After doing some research I found that the “;” in the URL is not recognized as a delimiter and thus OAM sees “app1InvSecQA.do;jsessionid…” as a completely different resource then “app1InvSecQA.do” – which is the resource that I was protecting in my policy.  I found this document from Oracle which describes a solution:

http://download.oracle.com/docs/cd/E15523_01/core.1111/e10043/osso.htm

10.2.10.18 URL Rewriting and JSESSIONID

In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.

To avoid issues of a mismatch with Oracle Access Manager, you can create a policy for matching the URL with JSESSIONID. For this example, suppose the protected URL is:

/myapp/login

You can create a policy within the appropriate policy domain to match the URL with JSESSIONID.

To avoid issues matching a re-written URL

  1. Go to the Policy Manager and log in. For example:
  2. http://Webserver:port/access/oblix

    where Webserver refers to computer that hosts the Policy Manager Web server; port refers to the HTTP port number of the Web server instance; /access/oblix connects to the Access System.

  3. Click Policy Manager., click My Policy Domains, and click the link to the desired policy domain.
  4. Click the Policies tab, and then click Add.

    Fill in and save General details:

    Name: JSESSIONID Matching Policy

    Resource operation(s): Select all applicable HTTP operations

    Resource: Select the context root (create it if needed). For example: /myapp

    URL Pattern: login

Click Save.

I am still working on this issue … so, no solution yet, but I don’t give up, so I will be sure to update this post with the solution once I find it.

This did not resolve the issue.  I have also tried several variations of the Oracle solution including wildcards … all to no avail.

Update:

This resolved the issue:

You should be able to resolve this issue by following these steps.
1. Download and apply the one off patch for
Bug.6938829 (80) NEED SUPPORT TO DISABLE URL REWRITING FOR JSF APPS
OR
install the 10.1.3.5.0 patchset. This is the recommended method as it is best to be on the latest patchset.
8626084 PLACEHOLDER BUG TO UPLOAD AS 10.1.3.5 PATCH-SET ON ARU
2. Install the patch or patchset according to the instructions included.
3. The application may need to be configured with an option in the orion-web.xml file,
<session-tracking url-rewriting=”false”/>
The session-tracking section may already exist, if it does the url-rewriting parameter would be added to the existing parameters.
This file is often included in the deployment file under the WEB-INF directory of the WAR file prior to deployment and is in the ORACLE_HOME/j2ee/<instance>/application-deployments/<appname>/<modulename> after deployment.
More details can be found here,
Oracle® Containers for J2EE Servlet Developer’s Guide
10g (10.1.3.1.0)
Part Number B28959-01
http://download.oracle.com/docs/cd/B32110_01/web.1013/b28959/xmlfiles.htm#sthref514
<session-tracking>
4. Restart OC4J after applying the patch and / or modifying the application orion-web.xml file.

1 thought on “A Challenging Access Policy #Oracle #OAM #IdM”

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top