Oracle BPEL Process Manager has its ‘dehydration’ store where details for BPEL process instances as well as human workflows are recorded. Access to the data in the BPEL PM database is provided through a Java API, that is also used by the BPEL PM Console and Worklist Application. This API facilitates and ensures correct access; we do not need to know any database details for example, we simply ask our questions to the API.
However, there comes a time where the API does no longer satisfy you. Or me. That moment comes pretty soon: I want to see what is in that database for myself. Let’s see how.
The default dehydration store for Oracle BPEL PM – by the way, in this article I am looking at release 10.1.3, currently available as part of the preview for 10.1.3 SOA Suite – is Oracle Lite. I have worked a lot with (proper I would almost say) Oracle Databases and very little with Oracle Lite. So I now need to find out how to access this Oracle Lite database and the BPEL PM data in it. I need to find out what user and password are and what the database url is – host, port etc.
From the Application Server Console, I can find out some information:
It does not tell me the password, but the entire URL is here as well as the username I am looking for. I might guess that the password used is manager, but how can I find out for sure? Well, since I am looking at an entirely local installation, I have easy access to the OC4J directories. In the directory SOASUITE_HOME\j2ee\home\config I find the file data-sources.xml. In this file is the entry corresponding with the definition of the Connection Pool shown in the screenshot:
<connection-pool name="BPELPM_CONNECTION_POOL">
<connection-factory
factory-class="oracle.lite.poljdbc.POLJDBCDriver"
user="system"
password="manager"
url="jdbc:polite4@127.0.0.1:1531:orabpel"/>
</connection-pool>
And indeed, the password is defaulted to manager.
Querying the Dehydration store
Now I know how to get to the Dehydration Store, I can use several tools to actually perform queries. One of these is JDeveloper’s database browsing functionality. In JDeveloper, I create a new Connection: BPEL_OLITE_LOCAL, of type Third Party JDBC driver.
Note that I had to create (in JDeveloper 10.1.3 that is) a new Library (I called it Oracle Lite) with the SOA_HOME\bpel\lib\olite40.jar file in its CLASSPATH in order to get the connection running properly. Perhaps due to lack of knowledge of Oracle Lite I have done something far less simple than is possible here.
At this point I am set up to start browing the contents of the BPEL Dehydration Store:
Is it possible to use *any* JDBC data source as the dehydration store?
For example using TimesTen as the store would pose some interesting performance possibilities..
Good to know…actually the consultant saw my comment and replied with an assurance that they are indeed using redirection to protect the password.
Just because someone has access to the server doesn’t mean that security has been breached. I like to think that we practise security by not assuming that our external firewall are the only line of protection. Everything is protected internally too so even if one server (area) was breached, there are still protection for the other servers/databases.
Well, several points on that remark:
– first of all: I am looking at a default installation on a stand-alone, development machine, so security is one of my least concerns right now
– secondly: the configuration file mentioned in this article is on the application server; if an undesired individual would gain access to that machine, security would already have been breached in a pretty major way
– thirdly, passwords can – and should – be stored encrypted in this file in any serious environment. See Declarative J2EE authentication and authorization with JAAS by Frank Nimphius and Duncan Mills, July , 2005 for more details.
From this article I quote: “This however can be achieved with the password indirection feature in OC4J that allows passwords used in the data-sources.xml to be stored encrypted in the jazn-data.xml file…” and “Password indirection in OC4J
For stronger protection, configure the J2EE data sources to use password indirection in OC4J. An indirect password is made up of a special indirection symbol, which is a hyphen directly followed by a greater than character (->), and a user name. When OC4J encounters an indirect password, it uses its privileged access to retrieve the password associated with the specified user from the OC4J jazn-data.xml file, which is located in the \j2ee\home\config directory.
To use password indirection, the value of the password attribute in the element is replaced by the “->PwdForScott” reference
PwdForScott”
url=”jdbc:oracle:thin:@localhost:1521:orcl”
inactivity-timeout=”30″
/>
The jazn-data.xml file in the \j2ee\home\config directory requires the following additional entry to make the password indirection work.
The database schema password in the jazn-data.xml example provided above is “tiger”. Because the password is specified with a leading “!” character, it gets encrypted after re-starting the OC4J instance. The encrypted password looks similar to “{903}ZECYw/3kJmhVjzXgbZhxFg1/F8mhpsrr”. The LoginModule usage of the data source does not need to be changed for using the password indirection feature.”
So, isn’t having the password in cleartext in the data-sources.xml file a concern? That seems to smack of very poor security design.
We just started using BPEL PM in our organization and I think I will have to take a closer look at how it was installed and configured (Installation/Configuration was done by consultants who are supposely “experts” in BPEL PM).