I am trying to do the same thing. With much help from Ulf I have gotten my web service running and using wss4j's UsernameToken.
Now I have the task of creating a bunch of mock clients that access the web service verifying my work before. This serves another purpose as we will have implemented what we know our customers will probably do.
Easiest implementation is to use java.net.URL to send the request and get the response. Very crude, but it works. That is one way.
More realistically, clients will not be done that way. What I would like to implement is a client that uses code generated by WSDL2Java based on our posted wsdl. This tool worked well and generated code. But how do I set the header username and password. The wss4j site suggests doing this:
Unfortunately the port._setProperty method does not appear to be available. I have looked everywhere, but it is not there. I cannot see how this would work anyway. This is all generated from Axis. Does Axis know how to build a WS Security header? It seems like it would need the wss4j API for that.
Also, I am not too keen on altering the java code generated by WSDL2Java. It could be done. But if I regenerate the code, I have to reedit the generated code by hand. It seems like there should be a way to alter the header from the client. Or am I way off base and there is a better way to do this?
Is there a way to add a WS Security SOAP header to a request in the client. Here is my code:
The squeaky wheel gets the grease. Well, that or replaced...
Joined: Mar 22, 2005
It is possible to encapsulate both the client and server sides of WS-Security authentication in JAX-RPC handlers using WSS4J. That way you don't need to change the Axis-generated code at all, and all authentication-related stuff is kept separately from the WS. It is not well documented how this works with WSS4J, though.
WSS4J comes with a sample called PWCallback, which implements the WSPasswordCallback; you need one of those both on the client and on the server. The username to be used is declared in the client config file, and then the client-side handler sets the password, while the server-side handler verifies it. (It gets slightly trickier if DIGEST authentication is used instead of BASIC, but I'll leave that aside for the moment).
I'll put something together for the FAQ that shows how the various pieces works together. [ January 24, 2006: Message edited by: Ulf Dittmer ]
Thanks. That gave me enough of a hint to figure it out. Here is what I did:
Here is client_deploy.wsdd
Like you said, it looks like it will be a bit more if your is using a password digest. But if your web service is already set up to handle it, I think all you need to do it change the passwordType parameter like this:
Or at least, when I did this, I could see the digest password in the soap. But, since my web service is not set up to handle it, the app choked.