-
1. Re: password hash values do not match
ykurttr Apr 12, 2010 8:15 AM (in response to ykurttr)The GSOAP client also sends decoded nonce value, no BASE64 encoding for sent nonce
-
2. Re: password hash values do not match
ykurttr Apr 15, 2010 9:36 AM (in response to ykurttr)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
-
3. Re: password hash values do not match
romanojb Apr 28, 2010 10:22 PM (in response to ykurttr)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.
Romano
-
4. Re: password hash values do not match
romanojb May 1, 2010 12:04 PM (in response to romanojb)Let me correct myself here. After doing more tests, I noticed JBoss 5.1 was ignoring the password I sent. Still investigating
-
5. Re: password hash values do not match
ykurttr May 3, 2010 1:45 AM (in response to romanojb)hi romano,
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.
-
6. Re: password hash values do not match
romanojb May 3, 2010 3:34 PM (in response to ykurttr)I created this bug:
https://jira.jboss.org/jira/browse/JBWS-3014
Maybe you can also add comments in there