In the previous post (SSL Encryption / Authentication between JBOSS JCA + webMethods Broker) I explained how you can setup a MDB (hosted on JBOSS) to securely connect and consume JMS messages from SoftwareAG webMethods Broker using JCA, SSL encryption and authentication...
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:
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:
- Integrating SoftwareAG webMethods messaging Broker with JBOSS AS 7 through standard JCA
- SSL Encryption / Authentication between JBOSS JCA + WebMethods Broker
- JBOSS Vault to encrypt JMS password for secure JCA configuration
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=}
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...
... ...
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!):
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!... webm-jmsra.rar ...[some jms username] ${VAULT::broker-ssl::password::OWQyRRMjZm9NjktMTA5Zi00Yzc0L7WFhYWQ4tZTU2eeSMsszUwMmwytY1NDNlTElORV9CUkVBS2pib3NzdmF1bHQ=} ...
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!
