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.

OVD 11g ForkJoin Plugin “FullOuterJoin” explanation #oracle #idm #ovd

I tried to implement the ForkJoin plugin today, for the first time.  The documentation is pretty good but not clear about one specific parameter (which happened to be the one that I needed).   When you add the plugin and then select to add a parameter, screenshot, one of the options is FullOuterJoin. According to the documentation is a setting under the JoinPolicy.  The implementation is a little different, as you can see if you click on the screenshot.  I wasn’t sure what to put here,  so I checked with Oracle and was told this:

“… that referenced Full Outer Join as being set to either true or false. ”  and “… they believe that setting Full Outer Join to true would mean full outer join is performed, set to false would mean left outer join, and to have standard join we would simply not install the plug-in.”

I was able to confirm that by setting FullOuterJoin to true does indeed allow entries from both (in my case) adapters to be returned.  The only caveat to this is that entries that should be joined … are no longer joining.  So, still trying to figure that part out.

Update (02/05/2010):

I heard back from OVD Dev as follows:

The documentation for plug-in configuration parameters has to be read as:
Names mentioned in bold are parameters that a plug-in supports.
Under each parameter name, description and semantics of all possible values are explained.

First, for Fork Join plug-in, SecondaryOnlyAttributes, PrimaryAndSecondaryAttributes & JoinPolicy are the only parameters supported. ‘FullOuterJoin’ is not a parameter, but one of the possible values for ‘JoinPolicy’ parameter. The other values are ‘StandardJoin’ & ‘LeftOuterJoin’. Please note that there are no spaces in parameter values.

Second, ODSM displays the list of parameters supported by a plug-in from the plugin manifest file. Since ForkJoin plugin manifest file incorrectly has “FullOuterJoin” as the parameter name instead of “JoinPolicy”, the incorrect parameter name is displayed in ODSM.

As ODSM would not allow specifying any other parameter to the plug-in configuration than what is listed in the plug-in manifest, the workaround, for now, is to please make a backup copy and then edit the <$ORACLE_INSTANCE>/config/OVD/<ComponentName>/adapters.os_xml file as follows, then re-start OVD server:

Change following line from:
<param name=”FullOuterJoin” value=”true”/>

To:
<param name=”JoinPolicy” value=”FullOuterJoin”/>

Third, since the value for “JoinPolicy” is not specified in the plug-in configuration, ForkJoin plug-in assumes “LeftOuterJoin” as the default and hence users that are only in secondary adapter (AD2) were not returned.”