That was a very easy setup since all we had to do is add a couple of system properties in the JBOSS admin console to make this work fine.
But as you may have noticed, we specified the keystore password in clear text (for simplicity sake...and also because I knew I'd be writing this post soon after of course!!) as part of those system properties...and that should raise a couple of alarms for most IT professional...

So this post is to explain how we can remediate this situation using JBOSS built-in Vault feature.

Please note this post is the 3rd out of the following 3 related posts:

JBOSS Vault

In short, this component offers a very nice way to obfuscate/encrypt sensitive text information within JBOSS configuration files. Using this concept, I'm going to show how to encrypt the SoftwareAG webMethods Broker password and how to use it through the Resource Adapter configuration...

First, Since I'm not a big fan of recreating documentation when the original product one is pretty good already, please refer to the well-written JBOSS EAP 6.1 doc to setup the JBOSS Vault for your environment.

If you follow it pretty closely, you should have:
- a keystore file saved somewhere on your file system,
- added in that keystore the various sensitive passwords you want to securely use in the JBOSS configuration, by using the provided JBOSS vault.sh script
- A "VAULT" block in your JBOSS configuration file, similar to the following:

From there, you should be able to add the encrypted strings in most JBOSS configurations without too much problem...using the pattern that should have been given to you during the encrypting process...

For example, here is my sample "encrypted" string for the test password I used with my test instance of webMethods Broker:
${VAULT::broker-ssl::password::OWQyMjZmNjktMTEA5Zi00YzRc0LWFhYWQtZTTU2MzUwMmY1NDNlTElOaRRV9CUkVBS2pib3NzdmF1bHQ=}

Wrong instinct!

Ok now if you're like me, your first reflex is going to be to use this encrypted string in the password system property we added in the previous post...

...
...

But unfortunately, that does not work...at least not with EAP 6 standalone...Seems like it's due to a race condition where the JBOSS Vault is not yet initialized when the system properties are added...hence the system property "com.webmethods.jms.password" ends up still having the encrypted string in its value...as opposed to the decrypted value...

And of course, this is not quite what we need...as the resource adapter is not going to be able to do anything with that encrypted password...

Keep pushing, there's light at the end of the tunnel!

But fear not! There's another simple way to make use of that encrypted password (and I think ultimately a better way...which does not save the clear password in a system property that is readable by anybody...).

The generic jms resource adapter provides 2 properties for username and password (refer to genericjmsra.java.net: user guide), and fortunately for us, we can use the {VAULT} encrypted string for those since the resource-adapters subsystem is initialized after the VAULT subsystem!

So the solution is to remove from the global system properties block those 2 system properties for username and password (com.webmethods.jms.username, com.webmethods.jms.password), and instead add them in the wm Broker Resource Adapter configuration block a follow (using the VAULT encrypted password instead of the clear text one!):

Now, the Resource Adapter component will "magically" get access to the right decrypted password (because the VAULT will have decrypted it first) and provide it (alongside the username) to the JMS new connection method!

Done and happy...onto next challenge!

So with all this in place, you get a secured JBOSS / Resource Adapter configuration file free of any clear text password...and all the while can take advantage of JBOSS Vault auto-decryption to have your application components (and/or resource adapter in this case) use that precious password in the very same way as before...all this without having to add/write one extra line of code!! Sweet!

if you're using the resource adapter construct explained here, you really should not have to retrieve the password in your own code (at least not for JMS interactions). But if you want to decrypt things that were stored in a system property for example, then you can use "org.jboss.security.vault.SecurityVaultUtil" for that purpose.

Hi Febien, Do you have working example to configure security domain for resource adapter? I have tried using

xyz

In Jboss 7.1.1 (JBoss EAP 6.10), by using your first post. however, it has error saying failed to prefill the connection pool (failed with init context), if I change to and when creating jms connection by using connectionFactory.creatConnection(username, password), that works, it seems JBoss ignore the security domain, if you need more details, I can post it to you later. Thanks.