An Oracle Service Bus(OSB) service account is a container object that can hold a username and password. These credentials can be used by an OSB businessservice object to perform for instance HTTP basic authentication. At my current project we use a fully automated deployment process based on ANT scripting. No manual steps are involved, therefore human errors are avoided. In the OSB source code, the password in the service account is stored as clear text. So the passwords end up in the source code repository (e.g. subversion), which is bad practice. To solve this problem, we can either introduce a manual step during deployment, or use encrypted passwords.

Weblogic encrypted passwords.
In the Weblogic domain directory, all passwords are stored encrypted. Weblogic encrypted passwords are directly supported in the OSB service account. The encryption is domain specific because Weblogic uses the domain salt file (<DOMAIN_HOME>securitySerializedSystemIni.dat). To encrypt a clear text password, the Weblogic encrypt utility can be used:
java -Dweblogic.RootDirectory=C:mydomain
-cp C:mwwlserver_10.3serverlibweblogic.jar mycleartextpassword

In Weblogic 11g, the Advanced Encryption Standard algorithm is used and the resulting encrypted password will start with: {AES}

Note that the encrypted password can be decrypted, when the domain salt file is available. However, we consider the storage of encrypted passwords in subversion acceptable, because access to the domain salt file is restricted on filesystem level.

There is however one issue during the build/export phase: although the manual export of the configuration JAR from Eclipse works fine, the ANT-based scripted export cannot handle encrypted passwords and fails. We work around this issue in this way: during the definition of the the OSB service account, we use the encrypted password prefixed with a character, for instance ‘@’. Because the resulting password does not start with {AES}, the scripted export regards this as a clear text password, and the build/export succeeds. After the scripted export has created the configuration JAR, we use ANT to perform a post-process step: remove the ‘@’ character from the service account source code.

In a previous blog, I discussed similar ANT post-processing for incorporating subversion information into the configuration JAR. The combined ANT script, is shown here:
<target name=”postProcessArchive”>
<echo message=”>>> updating ${configurationJAR}” />
<delete dir=”${dir.tmp}” />
<mkdir dir=”${dir.tmp}” />
<unzip src=”${configurationJAR}” dest=”${dir.tmp}” />

<!– 1. insert POM version –>
<replace file=”${dir.tmp}/${}/_projectdata.LocationData”>
<replacefilter token=”proj:description/”
value=”proj:description>${POM.version}</proj:description” />

<!– 2. handle encrypted password in servicesaccounts –>
<replace dir=”${dir.tmp}” value=”{AES}”>
<include name=”**/*.ServiceAccount”/>

<delete file=”${configurationJAR}” />
<zip destfile=”${configurationJAR}”>
<fileset dir=”${dir.tmp}”>
<include name=”**” />
Using this approach we have a fully automated build/export and deployment process that is also secure. We also tried this approach with OSB service key providers, which also holds a password. Unfortunately OSB service key providers do not support encrypted passwords.