THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
CXF 2.2 introduced support for using WS-SecurityPolicy to configure WSS4J instead of the custom configuration documented on the WS-Security page. However, all of the "background" material on the WS-Security page still applies and is important to know. WS-SecurityPolicy just provides an easier and more standards based way to configure and control the security requirements. With the security requirements documented in the WSDL as WS-Policy fragments, other tools such as .NET can easily know how to configure themselves to inter-operate with CXF services.
Note: at this point, WS-SecurityPolicy support is ONLY available for "WSDL first" scenarios. The WS-SecurityPolicy fragments can only be pulled from WSDL. In the future, we plan to enable various code first scenarios as well, but at this time, only WSDL first is available.
Policy description
With WS-SecurityPolicy, the binding and/or operation in the wsdl references a WS-Policy fragment that describes the basic security requirements for interacting with that service. The WS-SecurityPolicy specification allows for specifying things like asymmetric/symmetric keys, using transports (https) for encryption, which parts/headers to encrypt or sign, whether to sign then encrypt or encrypt then sign, whether to include timestamps, whether to use derived keys, etc... Basically, it describes what actions are necessary to securely interact with the service described in the WSDL.
However, the WS-SecurityPolicy fragment does not include "everything" that is required for a runtime to be able to able to create the messages. It does not describe things such as locations of key stores, user names and passwords, etc... Those need to be configured in at runtime to augment the WS-SecurityPolicy fragment.
Configuring the extra properties
With CXF 2.2, there are several extra properties that may need to be set to provide the additional bits of information to the runtime:
ws-security.username | The username used for UsernameToken policy assertions |
ws-security.password | The password used for UsernameToken policy assertions |
ws-security.signature.properties | The properties file/object that contains the WSS4J properties for configuring the signature keystore and crypto objects |
ws-security.encryption.properties | The properties file/object that contains the WSS4J properties for configuring the encryption keystore and crypto objects |
ws-security.signature.username | The username or alias for the key in the signature keystore that will be used. If not specified, it uses the the default alias set in the properties file. If that's also not set, and the keystore only contains a single key, that key will be used. |
ws-security.encryption.username | The username or alias for the key in the encryption keystore that will be used. If not specified, it uses the the default alias set in the properties file. If that's also not set, and the keystore only contains a single key, that key will be used. |
ws-security.signature.crypto | Instead of specifying the signature properties, this can point to the full WSS4J Crypto object. This can allow easier "programmatic" configuration of the Crypto information." |
ws-security.encryption.crypto | Instead of specifying the encryption properties, this can point to the full WSS4J Crypto object. This can allow easier "programmatic" configuration of the Crypto information." |
*Note: * for Symmetric bindings that specify a protection token, the ws-security-encryption properties are used.docs coming soon