SOA11g: Database as a policy store

As more and more customers of SOA 11g move to production, we have been asked often about the recommendations for a PolicyStore for SOA 11g in production. This document addresses the various policy store options, helps evaluate the pros and cons of each of these options and describes the configuration steps required for using the database as a policy store in SOA 11g.

Note: This document is not a replacement for official documentation in this regard. Per official documentation, the policy store is defined as, ‘… the domain policy store is the repository of system and application-specific policies…‘ Further, ‘[i]n a given domain, there is one store that stores all policies that all applications deployed in the domain may use.‘

To reiterate, as of 11g PS4 only one Security/Policy store per domain is supported. And so, ‘all’ products in that domain (say SOA, WebCenter, etc.) will share this single repository.

Policy Store options

Currently the following are the options supported by OPSS (Oracle Platform Security Service) for Policy store:

1. File/XML based system-jazn-data.xml.
   This file based store is installed by default in the <domain home>/config/fmwconfig directory and seeded with the initial SOA application specific roles and policies.  The how-to section of this post (see below) lists steps to move from this file based repository to a database based one.
2. OID (Oracle Internet Directory – an LDAP provider)
3. the Oracle Database as a policy store

Evaluating these options

The file based repository, while convenient and usable for development purposes is ‘not’ recommended by Oracle in production.  According to OPSS documentation, ‘…in domains where several server instances are distributed across multiple machines, it is highly recommended that the OPSS security store be LDAP- or DB-based.‘

In cases where the customer doesn’t have an option but to use this file, the onus is on the customer to provide for high availability of this file.  Further, scalability with using this repository is questionable and under large transaction volumes it is easy to see this file becoming a bottleneck.  And again, for the customer that doesnt have any other options, this file based repository is usable when there are few users (tens) in the system and volume of transactions very little.

In summary, concerns regarding HA, scalability and need for manual synchronization of this file across servers, render the file based repository a non-viable option in production.

This brings us to the viable and recommended production options for this repository namely OID and the database.  Using OID as a policy store has been well documented here.

However, amassing policies in OID is a good option for customers who already use OID. Several of our SOA customers use non-OID LDAP directories and would not like to be tied to OID. In such cases, the Oracle database can be used as a policy store.

Steps to enable the Oracle Database as a policy store

Here are the list of steps to do enable the Oracle Database as a Policy store. Note that as usual it is recommended that the whole domain be backed up before any policy store changes are made, particularly the following files:

• jps-config.xml
• system-jazn-data.xml

As a precaution, you should also back up the boot.properties file for the Administration Server for the domain.

Step 1: Create the OPSS schema or ensure OPSS schema exists

Running RCU as part of SOA install automatically creates the schema and objects OPSS needs.  If RCU has already been run on an installation, check that the schema exists- <your prefix when running RCU>_OPSS is the naming convention for that schema.
One can login to this schema and run desc jps_dn as well.  Section 8.3 of this link is relevant as well.

Step2: Create a datasource for the OPSS schema

Create a Datasource for the OPSS schema using wlst or the weblogic console.
Important: Note that this datasource is to be created with a NON-XA driver and with no global transaction support.

Step 3: Reassociate security store

Now run this wlst script:

• run wlst and connect
• reassociateSecurityStore(domain="your_domain", servertype="DB_ORACLE",datasourcename="your_data_source", jpsroot="cn=jpsTestNode", join="false")

These parameters are elaborated in official FMW Application Security Guide but here is a quick recap:

• domain:refers to the name of the domain that this policy store is enabled for. Note again, that currently only one Policy store per domain is supported
• servertype: is to be set to DB_ORACLE for the Oracle database
• datasource name refers to the JNDI name of the Datasource
• jpsroot:is a logical name only, any name can be used and should be of the format cn=<a node name>
• join: see below

If you are reassociating your first domain and want to migrate policies from say system-jazn-data.xml, use join=”false”. Setting join=”true” doesn’t migrate any policies. It simply reconfigures the domain to look at DB for policies.

Maintaining the database policy store: For more information on ongoing maintenance for the Database Policy store, refer to this link (Section 8.3.2).

And there you are! All done with enabling usage of the Oracle Database as a policy store instead of the default system-jazn-data.xml. (Note: currently a bug prohibits the deletion of the system-jazn-data.xml file.  And so even an empty file named system-jazn-data.xml under <yourdomain>/config/fmwconfig/ will suffice.)

Also, my colleague Andre Correa has written a great article about the whole reassociation business as he calls it – well worth reading!