Improved callback for calling Backend Services from WSO2ESB

In my previous posts, we talked about securing BE service with WSO2ESB. But, there are some issues with way that we have configured when it comes to production developments. In this blog post, we are trying to overcome from them.

OK, let see what has happened with previous blog posts.

1. This post;  we discussed how ESB can call a BE service with sign/encrypt

We configured keystore details (alias, password) in the policy file……… Does this scale ? How to secure password in policy file ?

Keystores are kept in file system……..  How we can configure keystores for ESB tenants? How we can replicate them in ESB cluster nodes?

Private key password is provided using callback which password has been hard-code. How we can keep private key password?

2. This post , we discussed, how ESB can call to a BE service with user name token.

User’ password is configured in synapse configuration…….. Is this secure ? we need to configure passwords in secure manner.

3. This post , we discussed, how ESB can call to a BE service with Basic Authentication headers.

User’ password is configured in synapse configuration…….. Is this secure ? we need to configure passwords in secure manner.

Let see how we can solve above issues. There are some nice features in ESB, that would help to do that.

Feature  : Secure vault feature. We can store passwords in the vault as an encrypted value and decrypted value can be retrieved in the mediation path (in synapse configuration or inside a custom mediator). Therefore each tenant can store passwords or secret information separately and secure manner.  More detail can be found here.

Feature  : Key store management feature. We can upload keystores using management console. They would be stored in registry (database) and we can use them for encryption/signing. Each tenant can have different keystores and they would not be shared across tenants. This feature would allow to manage keystores from single place within the tenant.

With aid of above two features, New callback component has been developed for calling the BE services that have been secured with WS-Security. This callback would be much easier to use.

This component would be contain with three modules.

1. Class mediator :  This helps to configure user name, keystore and alias parameters which would help to build the rampart configuration. Also this mediator would initialize password callback handler that help to retrieve decrypted password from secure vault

2. Rampart Config callback handler : Normally in most of WS-Security scenario, we configure the rampart configuration as a policy assertion in the ws-security policy. All key store details, alias name and even user name are configured there. With Rampart config callback handler, we are going to build the that configuration dynamically.

3. Password callback handler : This is a typical password callback class. But different is that this callback would retrieve the decrypted password from secure vault in ESB.

You can find the source of the callback component from here. It contains very simple code and you can even modify it easily according to your requirements.  You can build the component using maven 3.0.X. However build OSGI bundle can be found in target directory.

Lets Configure Callback Component

Let see how we can configure this callback component in ESB. I am just going through high level setup as assume that you already know about WSO2ESB

Step 1. You need to deploy this component (OSGI bundle which is intarget directory) in to <ESB_HOME>/repository/components/dropins directory and restart the ESB

Step 2. This component can be added into ESB message path as a custom mediator.  Developing of custom mediator can be found from here

You need provide the class name as

org.soasecurity.wssecurity.secure.callback.mediator.ESBCallbackMediator

This class would contains following four properties.

1. userName : If BE is secured with user name token scenario, you can enter the user name that is used to build the user name token.

2. keystore : If BE is secured with sign/encrypt scenario, you can enter the keystore name that is used for sign and encryption. This keystore must be upload to the ESB server. Please make sure to use the same keystore name which can be seen in keystore management UI.

3. privateKeyAlias : This is the alias of the private key that is used in the sign/decrypt the messages. This Alias must be contained in the keystore that you have configured before.

4. encryptionKeyAlias (publicKeyAlias) : This is the alias of the public key (encryption user) that is used encrypt the message (or verify sign). This Alias must be contained in the keystore that you have configured before. You can easily upload public certificates in to the keystore using keystore management UI.

If BE is secured with sign or encrypt scenario, you only need to configure following properties.

If BE is secured with user name token scenario, you only need to configure userName property

Step 3. You can store the password of user name in the secure vault. Make sure to provide the user name as the Value key

 

 

Step 4. You need to add following rampart assertion in to the endpoint policy file. This assertion only defines the rampart Config callback handler . This must be configured in all BE policies. We do not need to do any other rampart configuration in to the policies.

<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:rampartConfigCallbackClass>org.soasecurity.wssecurity.secure.callback.handler.ESBConfigCallbackHandler</ramp:rampartConfigCallbackClass>
</ramp:RampartConfig>

 

Now you are free to use this call back component.