In 3.3.0 the ws-config syntax has been changed to:

WS-Security Usability Improvement

Motivation

Currently enabling WS-Security in CXF requires too much configuration and internal CXF knowledge from the user that could be avoided.

In order to enable WS-Security you need to configure the CXF WSS4J interceptors and inject them into Mule's CXF message processors, like this:

Usability improvement proposal

The proposal is to abstract the user of the CXF internals to enable WS-Security. The only requirement is that the user configures the properties with the desired values according to his needs.

'ws-security' Element

The user would be able to configure the WS-Security through a new 'ws-security' element that could be configured globally or as a child of the CXF message processor.

The syntax of the new element is the following:

or

Where the 'mule-security-manager' child element allows the user to integrate the WS-Security with the Mule Spring Security Manager. The 'securityManager-ref' is optional, by default it references the mule security manager defined within the flow.

The <cxf:ws-config> element holds the WS configuration properties, the keys and values must map to the text strings in WSS4J's WSHandlerConstants and WSConstants classes.

And the 'ws-custom-validator' allows to configure custom Validators in CXF to override the default validators used to validate a received security token.

Validators are a new feature in WSS4J 1.6, that introduces the concept of a Validator, for validating credentials that have been processed by a Processor instance. To know more about the introduction of Validators check WSS4J 1.6 Introducing Validators.

The 'ref' attribute is a reference to a bean that corresponds to an implementation of a Validator interface.

The options for the 'ws-custom-validator' childs are:

• username-token-validator: Override UsernameToken validation.
• saml1-token-validator: Override SAML1 token validation.
• saml2-token-validator: Override SAML2 token validation.
• timestamp-token-validator: Override Timestamp validation.
• signature-token-validator: Override trust verification on a signature.
• bst-token-validator: Override BinarySecurityToken validation.

Note:

The 'mule-security-manager' validates the credentials and overrides the UsernameToken validation. If a custom UsernameToken validator is configured, the mule-security-manager validator takes precedence and the custom one is ignored.

Example

To show how this element will improve the usability, we'll take the first configuration showing the old way to enable WS-Security and do it with the proposed 'ws-security' element:

And that's it, no need to know the interceptor in charge of enabling the WS-Security in CXF or configuring beans to set the configuration properties.

Alternatively, if we want to reuse a configuration, we can configure the element globally and then reference it from within our CXF message processor. For example:

And then reference the configuration that we want as child of the CXF message processor:

To know more about WS-Security in CXF check here

Impact in Studio

As discussed with the Studio team, this new element will require some changes in the configuration of the CXF message processor. A new Security Tab could be added to allow the user to enable WS-Security.

Working on the mock ups with the Studio team.

Documentation

See: Enabling WS-Security