THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<import resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath*:META-INF/cxf/cxf-extension-*.xml" />
<jaxws:endpoint id="myService"
implementor="com.acme.MyServiceImpl"
address="http://localhost:9001/MyService">
<jaxws:inInterceptors>
<!-- SAAJ Interceptor explicitly needed only for 2.0.x -->
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
<entry key="action" value="...UsernameToken"/>
<entry key="signaturePropFilepasswordType" value="...PasswordDigest"/>
<entry key="usersignaturePropFile" value="..."/>
...
</map>
</constructor-arg>
</bean>
</jaxws:inInterceptors>
</jaxws:endpoint>
|
...
WS-Security supports many ways of specifying tokens. One of these is the UsernameToken header. It is a standard way to communicate a username and password or password digest to another endpoint. Be sure to review the OASIS UsernameToken Profile Specification for important security considerations when using UsernameTokens.
For the server side, you'll want to set up the following properties on your WSS4JInInterceptor:
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
public class ClientPasswordCallback implements CallbackHandler {
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
// set the password for our message.
pc.setPassword("password");
}
}
|
Here is an example of WS-Security implemented using annotations for interceptors (uses UsernameToken).
...