Page History

...

<jaxws:inInterceptors>
    <bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
        <constructor-arg>
            <map>
                <entry key="action" value="Signature Timestamp"/>
                <entry key="signaturePropFile" value="..."/>
                <entry key="passwordCallbackClass"value="..."/>
           </map>
        </constructor-arg>
    </bean>
    <bean class="org.apache.cxf.ws.security.wss4j.DefaultCryptoCoverageChecker"/>
</jaxws:inInterceptors>

As of CXF 2.5.11, 2.6.8 and 2.7.5, it is possible to only check that a received message meets cryptographic requirements via the CryptoCoverageChecker if it is not a fault. This is useful in the scenario where a client is using the CryptoCoverageChecker interceptor to verify security requirements from a service response. In this scenario, you may want to get the original service Fault rather than have the CryptoCoverageChecker throw an exception if a Fault message from the service isn't secured. To enable this behaviour, then set the "checkFaults" boolean property on CryptoCoverageChecker to "false".

Custom Processors

As of CXF 2.0.10 and 2.1.4, you can specify custom WSS4J Processor configurations on the WSS4JInInterceptor. To activate this configuration option, one provides a non-WSS4J defined property, wss4j.processor.map, to the WSS4JInInterceptor as shown in the following Spring example. The same configuration can be achieved through the API as well. The key value is an XML qualified name of the WS-Security header element to process with the given processor implementation. The entry values can be a String representing a class name of the processor to instantiate, an Object implementing Processor, or null to disable processing of the given WS-Security header element.

...