WS-Security Gateway
Sample Number |
204 |
Level |
|
Description |
This sample demonstrates the usage of UltraESB as a WS-Security gateway |
Use Case
I want the UltraESB to act as a high performance WS-Security gateway, providing a secure interface to the clients for non secure services, and a non secure plain interface to the secure service allowing a plain client to access the secure services. The UltraESB should be able to either add or verify and remove security as signed and/or encrypted messages with time-stamp validation.
The proxy service should be able to serve a WSDL with the WS-Security policies. If the request message is secure proxy service should make sure the response to be secured too, and if the proxy service is used to add ws-security, it should make sure that the security from the back-end service to be removed before forwarding back to the client.
As shown in the above diagram, instead of directly talking to the back-end service, UltraESB acts as the proxy for all the requests going to the back-end server, and the UltraESB terminates security. UltraESB talks to the back-end server with pure request messages and gets the pure response which will be secure again before sending back to the client, providing a secure interface to the non secure service.
Sample Configuration
The UltraESB includes a new WS-Security library that is designed to support high performance WS-Security processing. The configuration should define an instance of the WSSecurityManager bean, which could be initialized with an identity keystore and a trust keystore, or just a single keystore where all credentials are saved. In the example, we will use a standard keystore used for WS-Security testing, and thus used the second alternative for initialization.
Security manager and authentication manager configuration
1<bean id="wssecMgr" class="org.adroitlogic.soapbox.WSSecurityManager">
2 <constructor-arg value="samples/conf/keys/ws-sec-keystore.jks"/>
3 <constructor-arg value="password"/>
4 <constructor-arg>
5 <map>
6 <entry key="alice" value="password"/>
7 <entry key="bob" value="password"/>
8 </map>
9 </constructor-arg>
10 <property name="userDetailsService" ref="plain-user-service"/>
11</bean>
12
13<!-- Usernames/Password is asankha/adroitlogic -->
14<s:authentication-manager alias="authenticationManager">
15 <s:authentication-provider>
16 <s:user-service id="plain-user-service">
17 <s:user name="asankha" password="adroitlogic" authorities="ROLE_USER, ROLE_MANAGER"/>
18 </s:user-service>
19 </s:authentication-provider>
20</s:authentication-manager>It expects a Map of passwords against the alias for the credentials, and these passwords can be encrypted in the configuration file using the UltraESB security support. See the Securing Configurations document on how to secure the UltraESB configuration fragments.
The proxy service invokes the WS Security Manager to verify and secure messages as shown below. The UsernameToken authentication maybe verified, and the verified username and user roles accessed during mediation as shown in the example below.
Secure proxy service configuration
1<u:proxy id="ws-sec-proxy">
2 <u:transport id="http-8280">
3 <u:property name="ultra.http.wsdl_url" value="file:samples/resources/SimpleStockQuoteService.wsdl"/>
4 </u:transport>
5 <u:target>
6 <u:inSequence>
7 <u:java><![CDATA[
8 try {
9 org.adroitlogic.soapbox.api.WSSecurityManager wssecMgr = mediation.getWSSecurityManager();
10 wssecMgr.verifyUsernameTokenAuthentication(msg);
11 wssecMgr.verifyTimestampedEncryptedAndSignedMessage(msg, true);
12
13 System.out.println("Validated User : " + msg.getMessageProperty(MessageSecurityContext.USER_NAME));
14 System.out.println("Validated Roles : " + msg.getMessageProperty(MessageSecurityContext.USER_ROLES));
15 } catch (Exception e) {
16 mediation.getSOAPSupport().setPayloadToSOAP11Fault(msg, null, "Security validation failed", null);
17 mediation.sendResponse(msg, 500);
18 }
19 ]]></u:java>
20 </u:inSequence>
21 <u:inDestination>
22 <u:address>http ://localhost:9000/service/SimpleStockQuoteService</u:address>
23 </u:inDestination>
24 <u:outSequence>
25 <u:java><![CDATA[
26 mediation.getWSSecurityManager().timestampSignAndEncryptMessage(msg, "bob", "alice");
27 ]]></u:java>
28 </u:outSequence>
29 <u:outDestination>
30 <u:address type="response"/>
31 </u:outDestination>
32 </u:target>
33</u:proxy>In the same manner you could implement the reverse behaviour to add ws-security to the messages passing through as follows;
Proxy service configuration for adding security
1<u:proxy id="add-ws-sec-proxy">
2 <u:transport id="http-8280">
3 <u:property name="ultra.http.wsdl_url" value="file:samples/resources/SimpleStockQuoteService.wsdl"/>
4 </u:transport>
5 <u:target>
6 <u:inSequence>
7 <u:java><![CDATA[
8 mediation.getWSSecurityManager().timestampSignAndEncryptMessage(msg, "bob", "alice");
9 mediation.getWSSecurityManager().addUsernameTokenAuthentication(msg, "asankha", "adroitlogic", false, true, false);
10 ]]></u:java>
11 </u:inSequence>
12 <u:inDestination>
13 <u:address>http ://localhost:8280/service/ws-sec-proxy</u:address>
14 </u:inDestination>
15 <u:outSequence>
16 <u:java><![CDATA[
17 mediation.getWSSecurityManager().verifyTimestampedEncryptedAndSignedMessage(msg, true);
18 ]]></u:java>
19 </u:outSequence>
20 <u:outDestination>
21 <u:address type="response"/>
22 </u:outDestination>
23 </u:target>
24</u:proxy>Note that in the proxy service "ws-sec-proxy" in the previous configuration, it verifies the security in the incoming message and secures the response in the outgoing mediation while the proxy service "add-ws-sec-proxy" secures the incoming message and verifies the security in the response message.
In Action
To run this sample, start the sample configuration number 204 from the command line as follows;
Running the sample
$ cd /opt/ultraesb-2.6.1/bin $ ./ultraesb.sh -sample 204
Now start the SOA Toolbox and fire up a sample Jetty server on port 9000 which deploys the "SimpleStockQuoteService". If you look at the above 2 proxy service configurations they are integrated to test both these scenarios in one invocation, as the plain request from the client will be directed to the add-ws-sec-proxy, which will secure the messages going through and forwards it to the ws-sec-proxy which accepts secure messages, verifies the security and forwards the message to the sample back end service as a plain request.
On the response path, the response from the back-end service will first be received by the ws-sec-proxy which will add security to the response from the back-end service, before forwarding the response back to the add-ws-sec-proxy, which will validate security on the response and delivers the response back to the caller (in our case the SOA Toolbox) as a plain response.
To test this, use the SOA Toolbox HTTP/S client to send a request of type Preset "1" to the URL http://localhost:8280/service/add-ws-sec-proxy. The request is timestamped, signed, encrypted by the add-ws-sec-proxy and WS-Secured request is forwarded to the ws-sec-proxy after adding the authentication. You will get the WS-Secured response back again as shown below. The response is a validated message and does not contain WS-Security.
Response received by the SOA Toolbox
HTTP/1.0 200 OK Date: Sat, 11 Feb 2012 16:32:24 GMT Content-Type: text/xml; charset=utf-8 Server: UltraESB/2.6.1 Content-Length: 883 Connection: close <?xml version="1.0" encoding="UTF-8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body wsu:Id="id-7119982054616-2050911753" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <ns2:getQuoteResponse xmlns:ns2="http://soap.services.samples/"> <return> <change>4.137768101702345</change> <earnings>13.74425833360641</earnings> <high>158.42219474331438</high> <last>154.38079679132596</last> <lastTradeTimestamp>Sat Feb 11 22:02:24 IST 2012</lastTradeTimestamp> <low>-151.40805109517225</low> <marketCap>-9952534.436709067</marketCap> <name>ADRT Company</name> <open>159.4988280098651</open> <peRatio>25.220799240369182</peRatio> <percentageChange>-2.731543339260604</percentageChange> <prevClose>-151.4809610460872</prevClose> <symbol>ADRT</symbol> <volume>6365</volume> </return> </ns2:getQuoteResponse> </S:Body> </S:Envelope>
Using the TCPDump utility of the SOA ToolBox, one can verify that the request forwarded to the SimpleStockQuoteService - has the WS-Security header removed after the successful validation. Sending a message that has been altered will result in a security violation fault being returned.
Related Samples
Sample Number |
Sample Title |
103 |
|
110 |
HTTP Basic, Digest, NTLM Authentication and AWS S3 Authentication |
In this topic
In this topic