Is there a standard approach to building a policy on accessing an external web service, hiding the WS security aspects for the internal client application?

[Sebastian van Voorn]

A provider exposes a #webservice which (of course) has #ws-security included on it. I want to build a #policy to give acces to an internal clientapplication, but without the fuzz of the WS-Security.

What approach should I use to build this #policy?

I could imagine that I import the #wsdl from that external webservice (publish webservice). 

And then I build a new policy which applies WS-Security and requests the WebSservice policy.

Is this logical?

[greg munger]

Yes. I am still working on this problem as well, this is what our great support person (Flora Huang) told me.

1. Create a soap policy from the wsdl

2. Create another rest policy that calls the soap policy on localhost

3. Add the ws security stuff to the soap policy

4. Perhaps lock down the soap policy by only accepting a localhost source

 

I'm still having trouble with the signature but the rest seems to be working.

[Stephen Hughes]

Good afternoon,

 

To confirm your logic that you have the client hit a service on the gateway, gateway applies the WS-Security decoration, gateway send request to the back end webservice. This is definitely a normal workflow and can be done by

1) configuring a SOAP service using the WSDL from the backend

2) modifying the service properties to allow for HTTP Method GET and PUT on the HTTP/FTP tab and "Allow requests intended for operations not supported by this WSDL. This will provide you with the ability to make the inbound requests SOAP or REST.

3) Either construct the message that you are looking to send to the back end in the policy or take the request coming inbound to the service and add the decoration in the policy.

 

Sincerely,

 

Stephen Hughes

Director, CA Support