SOAP Web Service Security

Demonstrates how to apply varying levels of security to a SOAP Web service.

A web service exposes private-network data to the outside world and the data travels through four to seven separate protocol layers. See: TCP/IP or OSI. This introduces potential security vulnerabilities. Implementing security at a higher layer on the protocol stack — the application layer, for instance — generally provides better protection than an implementation at the lower transport layer, which provides only HTTPS security.

To implement application-layer security, enable WS-security (a CXF configuration) on your web service. WS-security defines a new SOAP header that is capable of carrying various security tokens that systems use to identify a Web service caller's identity and privileges.

Example

The example application applies different security measures to five of the six variations of a SOAP service it exposes except for the sixth layer, which is not secure. Each variation accepts end user salutation requests via a web browser, then responds with a personalized greeting. For instance, when a user submits the name, “Joan”, to one of the six variations, she receives a response that reads, Hello Joan. The following are the six variations in the WS-Security example application, and the security Mule applies to each:

• UnsecureServiceFlow - none - Processes all requests.
• UsernameTokenServiceFlow - UsernameToken - Processes requests with a valid username and password.
• UsernameTokenSignedServiceFlow - UsernameToken + signature - Processes requests with a valid username and password, and a valid digital signature.
• UsernameTokenEncryptionServiceFlow - UsernameToken + encryption - Processes encrypted requests with a valid username and password.
• SamlTokenServiceFlow - SAML2 - Processes requests in conjunction with an identity provider to verify message security.
• SignedSamlTokenServiceFlow - SAML2 + signature - Processes requests with valid digital signature in conjunction with an identity provider to verify message security.

This application also includes several variations of a client-side web service to ensure a functional example. These service-clients enable end users to submit salutation requests to the server-side Web service.

Set Up and Run the Example

You can create template applications straight out of the box in Anypoint Studio or Mule standalone (Mule without Studio). You can tweak the configurations of these use case-based templates to create your own customized applications in Mule.

Follow the procedure below to create, then run the WS-Security example application.

1. Create, then run the example application in Anypoint Studio or standalone.
2. Open your web browser.
3. In the address bar, type localhost:63080/client?clientType=unsecure&name=Joan
4. Press Enter to elicit a response from the WS-Security application.
5. Adjust the URL to change the name from Joan to your name, then press enter to elicit a new response from the application.
6. Adjust the clientType parameter from unsecure to any of the following five types (note that each type is case-sensitive):
7. usernameToken
8. usernameTokenSigned
9. usernameTokenEncrypted
10. samlToken
11. samlTokenSigned
12. Press Enter to elicit a new response from the application.

Regardless of the clientType you use to submit a request, Mule returns the same response. The type of security Mule uses to process the message is not reflected in the content of message, so even though Mule processes each request in a different way, the content of the response remains unchanged.

Documentation

Read full documentation in GitHub