<definitions xmlns="http://ws.apache.org/ns/synapse"> <localEntry key="sec_policy" src="file:repository/samples/resources/policy/policy_3.xml"/> <proxy name="StockQuoteProxy"> <target> <inSequence> <header name="wsse:Security" action="remove" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/> <send> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService"/> </endpoint> </send> </inSequence> <outSequence> <send/> </outSequence> </target> <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/> <policy key="sec_policy"/> <enableSec/> </proxy> </definitions>
Objective: Using WS-Security signing and encryption with proxy services through WS-Policy
Prerequisites:
You may also need to download and install the unlimited strength policy files
for your JDK before using Apache Rampart (e.g. see
http://java.sun.com/javase/downloads/index_jdk5.jsp)
Start the Synapse configuration numbered 200: i.e. wso2esb-samples -sn 200
Start the Axis2 server and deploy the SimpleStockQuoteService if not already
done
The proxy service expects to receive a signed and encrypted message as specified by the security policy. Please see Apache Rampart and Axis2 documentation on the format of the policy file. The element 'engageSec' specifies that Apache Rampart should be engaged on this proxy service. Hence if Rampart rejects any request messages that does not conform to the specified policy, those messages will never reach the 'inSequence' to be processed. Since the proxy service is forwarding the received request to the simple stock quote service that does not use WS-Security, we are instructing ESB to remove the wsse:Security header from the outgoing message. To execute the client, send a stock quote request to the proxy service, and sign and encrypt the request by specifying the client side security policy as follows:
ant stockquote -Dtrpurl=http://localhost:8280/services/StockQuoteProxy -Dpolicy=./../../repository/samples/resources/policy/client_policy_3.xml
By following through the debug logs or TCPMon output, you could see that the request received by the proxy service was signed and encrypted. Also, looking up the WSDL of the proxy service by requesting the URLhttp://localhost:8280/services/StockQuoteProxy?wsdl reveals the security policy attachment to the supplied base WSDL. When sending the message to the backend service, you could verify that the security headers were removed, and that the response received does not use WS-Security, but that the response being forwarded back to the client is signed and encrypted as expected by the client.
<definitions xmlns="http://ws.apache.org/ns/synapse"> <proxy name="StockQuoteProxy"> <target> <inSequence> <header name="wsrm:SequenceAcknowledgement" action="remove" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"/> <header name="wsrm:Sequence" action="remove" xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm"/> <send> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService"/> </endpoint> </send> </inSequence> <outSequence> <send/> </outSequence> </target> <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/> <enableRM/> </proxy> </definitions>
Objective: Demonstrate the reliable message exchange between the client and ESB using WS-ReliableMessaging (WS-RM)
Prerequisites:
Deploy the SimpleStockQuoteService in the sample Axis2 server and start it on port 9000.
Start ESB with the sample configuration number 201 (i.e. wso2esb-samples -sn 201).
In the above configuration, a proxy service is created with WS-RM enabled using the <enableRM/> tag. Therefore, this proxy service is capable of communicating with a WS-RM client. It also removes the WS-RM headers in the In Sequence before the message is sent to the back end server. This is required as the reliable messaging is applicable only between the client and ESB. Now start the client with WS-RM as follows:
ant stockquote -Dsymbol=IBM -Dmode=quote -Daddurl=http://localhost:8280/services/StockQuoteProxy -Dwsrm=true
In this case, client sends WS-RM enabled request to ESB where ESB sends normal request to the server. This can be observed by examining the wire level messages between the client and ESB. These messages would be similar to the wire level messages shown in sample 101. Each message would perform a similar function to the messages discussed in sample 53.
<definitions xmlns="http://ws.apache.org/ns/synapse"> <proxy name="StockQuoteProxy"> <target> <inSequence> <header name="wsrm:SequenceAcknowledgement" action="remove" xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702"/> <header name="wsrm:Sequence" action="remove" xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702"/> <header name="wsrm:AckRequested" action="remove" xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702"/> <send> <endpoint> <address uri="http://localhost:9000/services/SimpleStockQuoteService"/> </endpoint> </send> </inSequence> <outSequence> <send/> </outSequence> </target> <publishWSDL uri="file:repository/samples/resources/proxy/sample_proxy_1.wsdl"/> <enableRM/> </proxy> </definitions>
Objective: Demonstrate the reliable message exchange between the client and ESB using WS-ReliableMessaging (WS-RM)
Prerequisites:
Deploy the SimpleStockQuoteService in the sample Axis2 server and start it on port 9000.
Start ESB with the sample configuration number 202 (i.e. wso2esb-samples -sn 202).
In the above configuration, a proxy service is created with WS-RM enabled using the <enableRM/> tag. Therefore, this proxy service is capable of communicating with a WS-RM client. It also removes the WS-RM 1.1 headers in the In Sequence before the message is sent to the back end server. This is required as the reliable messaging is applicable only between the client and ESB. Now start the client with WS-RM as follows:
ant stockquote -Dsymbol=IBM -Dmode=quote -Daddurl=http://localhost:8280/services/StockQuoteProxy -Dwsrm11=true
In this case, client sends WS-RM enabled request to ESB where ESB sends normal request to the server. This can be observed by examining the wire level messages between the client and ESB. These messages would be similar to the wire level messages shown in sample 102. Each message would perform a similar function to the messages discussed in sample 53.