Consuming Web Service (WS-Security enabled) from a client not supporting WS-Security specs
Hi all,
My request is quite simple. I have to consume from an application (consumer) not supporting WS-Security specs a web service following WS-Security specs.
This consumer is proprietary and can't be modified. IMHO, the best way to tackle this issue is creating a web service proxy handling WS-Security stuff (authentication) and exposing the original web service without the WS-Security layer. So, the proxy will be responsible to append credentials on each operation invokation.
Let me know your thoughts about this design and if WSO2 ESB can help me in that way.
Any help would be appreciated,
Regards,
Alexandre
- Login or register to post comments
- Printer friendly version
- 239 reads











Hi, Could you please have a
Hi,
Could you please have a look at the sample 100 of ESB, which does exactly the same
http://wso2.org/project/esb/java/1.6/docs/ESB_Samples.html#Sample100
Thanks,
Ruwan Linton
Hi Ruwan, Thanks for your
Hi Ruwan,
Thanks for your quick reply. I'll give it a try.
Regards,
Alexandre
I followed the sample 100
I followed the sample 100 that is much more complex that I need. I tried to adapt it accordingly to my requirements but I get stuck on a blocking issue.
To refresh your mind, the scenario is quite simple : consumer -> esb -> web service. The ESB is responsible to deal with WS-Security elements (usernameToken and Timestamp).
Proxy Service Conf
<syn:proxy name="MyProxy" transports="https http" startOnLoad="true">
<syn:target>
<syn:inSequence>
<syn:send>
<syn:endpoint>
<syn:address uri="http://localhost:9001/soap/MyService">
<syn:enableAddressing/>
<syn:enableSec policy="policy.my-proxy"/>
</syn:address>
</syn:endpoint>
</syn:send>
</syn:inSequence>
<syn:outSequence>
<syn:send/>
</syn:outSequence>
</syn:target>
<syn:publishWSDL uri="http://localhost:9001/soap/MyService?wsdl"/>
</syn:proxy>
Related Policy File
<wsp:Policy wsu:Id="usernametoken-timestamp" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256/>
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax/>
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
<sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient" />
</wsp:Policy>
</sp:SignedSupportingTokens>
<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:user>xxxx</ramp:user>
<ramp:passwordCallbackClass>xxx.xxxxxxxx.PWHandlerClient</ramp:passwordCallbackClass>
</ramp:RampartConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
The ESB sends the password in plain text whereas the web service expects a digest password type.
Message Sent by the ESB
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-32014774">
<wsse:Username>xxxx</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">xxxx</wsse:Password>
</wsse:UsernameToken>
Message expected by the Web Service
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-12227392">
<wsse:Username>xxxx</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">f5pT0iffQf0P5/5RiOqR7d4aVus=</wsse:Password>
<wsse:Nonce>QHP4sKdYXyhllXyIswS6+w==</wsse:Nonce>
<wsu:Created>2008-03-27T15:04:58.150Z</wsu:Created>
</wsse:UsernameToken>
What is the proper configuration enabling the ESB to send the password in the digest format?
Any pointer to the documentation will be appreciated,
Regards,
Alexandre
Alexandre For Digest
Alexandre
For Digest authentication, please refer : http://www.nabble.com/Re%3A-WS-SecurityPolicy-1.2-support-%28UsernameToken-PasswordDigest%29-p16295189.html
You will need to use the current trunk build of the ESB (or a nightly build) to use this feature right now, or wait for our next release.
asankha
Asankha,That works like a
Asankha,
That works like a charm with the 1.6 release and this policy file.
<wsp:Policy wsu:Id="auth" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
[...]
</sp:TransportBinding>
<sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:HashPassword/>
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
[...]
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
It might be a bug. Note that the TransportBinding refers to the namespace http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 and the SignedSupportingTokens to http://schemas.xmlsoap.org/ws/2005/07/securitypolicy.
But now, I get an exception from the ESB during the processing of the reponse from the targeted web service:
2008-03-28 15:13:43,461 [193.1.2.56-alexandreg6500] [HttpClientWorker-1] ERROR ClientWorker Fault processing response message through Axis2 org.apache.axis2.AxisFault: Missing wsse:Security header in request
at org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.java:92)
at org.apache.axis2.engine.Phase.invoke(Phase.java:292)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132)
at org.apache.synapse.transport.nhttp.ClientWorker.run(ClientWorker.java:193)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.rampart.RampartException: Missing wsse:Security header in request
at org.apache.rampart.RampartEngine.process(RampartEngine.java:106)
at org.apache.rampart.handler.RampartReceiver.invoke(RampartReceiver.java:85)
... 7 more
The response sent by the web service doest not contain any wsse header, I guess this exception is related to this fact. Maybe this police file drives the ESB to expect wsse header from the response.
Any suggestions, because WS-Policy is something new for me?
Regards,
Alexandre
Alexandre >The response sent
Alexandre
>The response sent by the web service doest not contain any wsse header, I guess this exception is related to this fact. Maybe this police file drives the ESB to expect wsse header from the response.
Yes, if the outgoing request engaged Rampart with a specific policy, the ESB expects the response to adhere to the same. Rampart has now been changed to support different policies for outgoing messages and responses, and this will be available with the nightly builds of the ESB, and will make it to the next release
asankha
Asankha, I built wso2esb
Asankha,
I built wso2esb from the trunk (rev15384). Now the question is how do I configure the proxy service and so the underlying rampart component to utilize a specific policy for reponses The admin interface doesn't provide such feature.
Regards,
Alexandre
Hi Alexander, We do not have
Hi Alexander,
We do not have the ability to configure the message level policies from the admin console yet, since this is a newly added feature, you wil need to go to the configuration tab of the ESB and edit the row configuration to add the following xml as a child element to the proxy service;
<policy key="$POLICY_KEY" type="out"/>
This will engage the policy specified by the $POLICY_KEY, for the out going (response) messages.
Thanks,
Ruwan Linton