The GSOAP client also sends decoded nonce value, no BASE64 encoding for sent nonce
Hi, at last i've found a solution, but actually i don't feel comfortable about it.
My observation was that, other client types digest the sent password with decoded or not encoded nonce value, whereas jbossws digests the password with BASE64 encoded nonce, as a result the the client password digest value and server password digest value was not identical although both client and server know the correct values for password, nonce and created. The document on the link given in first post, which determines the username token profile standarts, says that the nonce is hashed using the octet sequence of its decoded value.The other two clients types also implements the standarts as described in the document. I had to consider that the problem was with jbossws side, so i decided to change the source code of jbossws-native.
First i modified the UsernameTokenCallback, i added Base64 decoding to nonce value if it exists. This made my other clients to be authenticated by jboss but this time my jbossws clients were unauthenticated. Then i modified the DefaultNonceGenerator class which implements NonceGenerator, i just removed the Base64 encoding from generated byte array. Now my jbossws clients are also authenticated.
At the end of the day i feel comfortable, because all of my clients can query my webservices in a secure manner. But i am still expecting an answer for the conflict and i don't think that it is a good way to change source codes. Now if any expert claims that there is no problem with jboss side, i am ready to rollback all my changes and let my clients to think about the problem
I don't know in which version it was changed, but it does work for me in JBoss 5.1.0 jdk6
I used to have the same problem when using JBoss 4.2.3.
I use an Axis client with WSS4J to send a PasswordDigest and JBoss correctly decodes the nonce element from the SOAP XML.
Let me correct myself here. After doing more tests, I noticed JBoss 5.1 was ignoring the password I sent. Still investigating
i think that there is something different with the logic of handling the hash on the jboss server side, when i examine the corresponding source code, i see that the BASE64 encoded nonce value is used for creation of hash to match the one sent by client. But the standart document says that; use the "nonce" not the "BASE64 encoded nonce" when creating password digest.
Jbossws clients create the password digest with BASE64 encoded nonce, as a result there is no crash when there is jbossws-server/jbossws-client; because other type of clients do not digest password with BASE64 encoded nonce, they always crash.