Perfect!  Thanks for your help, Werner.


Using PasswordText passwords in the header does indeed allow me to use getPassword in the Callback handler to get the cleartext password.  Is there a reason why this cannot be done with PasswordDigest? – This seems like an odd/arbitrary limitation.





From: Dittmann, Werner []
Sent: 10 October 2005 16:55
To: Stephen Sweet;
Subject: AW: Integrating WSS4J with a JBoss security realm




if your customer knows its plain test password (I assume so), then

you may use UsernameToken with plain text password and

encrypt the whole UsernameToken (there is an example in

the interops, scenario #2 afaik). To do so you need only to

distribute one certifcate holding the server's public key.


If you use plain text password you can then do the authentication

in the callback too (that's a special case, you may have a look

in the comments of the provided example classes).


Of course you need to hash the provided clear text password

and copare it with the stored server password as you described.


Would this help?




-----Ursprüngliche Nachricht-----
Von: Stephen Sweet []
Gesendet: Montag, 10. Oktober 2005 17:32
Betreff: Integrating WSS4J with a JBoss security realm


I’m about to build a web app and corresponding web service to expose some search functionality. The app is to be built in JBoss/Tomcat. I’ve not yet decided whether the service itself will be a Session EJB or a simple POJO class, but I think my questions apply to either case. (I’m actually erring on the side of POJOs for simplicity, and I can’t see a strong argument for EJBs given the relatively simple and atomic searches that the WS will carry out).

I’ve built a test service that is a simple POJO, and generated the relevant WS interfaces for this using Axis. I’ve then secured this using the PasswordDigest method in WSS4J. I’ve implemented the code in the service to interrogate the MessageContext and determine the Username/Principal of the user who was authenticated within the PWCallback handler.

I’m now stuck on the following:

1. In order for the PWCallback handler to authenticate the client submitting the WS request, it appears that you must have access to the *plain text* password of the user on the server. In my case, I want to hold the hashed user passwords in a database, so ideally I want the PWCallback to *provide* me with the clear text password, as submitted by the client, so I can hash it and check it against my DB. This seems to be impossible. The only solution I can think of is that we give out the hashed version of the passwords to the clients and tell them to submit that as their password in each request – so that I can fetch the same string from the DB and set it via the setPassword() method in the PWCallback handler.  This seems wrong – am I missing something?

2. Is there any way to integrate with a JBoss realm, such that authentication is automatically handled in the same way as web page logins, and some kind of context is set-up that I can then determine the Principal from?  Is this only possible if the service is implemented as an EJB – so the request context is available within the service method?

3. As most of our WS requests will come from a small number of clients, It would be good if we could maintain some kind of session – if only for the SSL connection, but ideally for the user session. I know this isn’t really WSS4J related, but any thoughts would be hugely appreciated!

Many thanks in advance for any advice,




This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender.
This footnote also confirms that this email message has been swept by
Ironmail for the presence of computer viruses.