In one of my projects I faced the challenge of invoking, from within my SOA Suite 11g composite, a webservice that was secured with HTTP basic authentication. I decided to use the owsm policy oracle/wss_http_token_client_policy. Because I didn't want the username and password of the referenced webservice to be visible in the audit trail, I also decided to use the Credential Store Framework. There are some excellent blog posts describing exactly how to do this, for instance
here and
here. I happily implemented this solution and after some basic testing deployed my composite on our test environment. Unfortunately, all was not well and good. It turned out that in some situations the referenced webservice required a different set of credentials, depending on the value of an element in the payload of the message. Now I faced a real challenge! Perhaps because of my poor googling skills, the world wide web didn't provide me with a solution. But this blog post wouldn't have seen the light of day if I hadn't been able to crack it. Here is how it goes.
In the composite.xml, after defining a referenced webservice, applying the owsm policy and overriding the csf-key, this is how it looks in the binding section of the referenced service:
<wsp:PolicyReference URI="oracle/wss_http_token_client_policy"
orawsp:category="security" orawsp:status="enabled"/>
<property name="csf-key">my-csf-key</property>
The trick is to override this csf-key property in the Invoke activity in the BPEL process. I couldn't do this from within the graphic design mode in JDeveloper, so I changed the source code manually:
<invoke ...>
<bpelx:toProperty name="csf-key" variable="myOtherCsfKeyVariable"/>
</invoke>
As you can see, in the BPEL Invoke activity, it is possible to set this property using a variable. The value of this variable can be derived from the message payload in combination with for instance a Domain Value Map lookup.
