Hi Aaron, As a workaround, can you use a plaintext password (no wsse:UsernameToken/Password/@Type="...#PasswordDigest" attribute) and put the digest value in the password. Then it will be up to your service authentication code that talks to the LDAP server to handle that as a digest instead of plaintext password.
Best Regards, George -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 11:57 AM To: [email protected] Subject: UsernameToken, Password Digest and LDAP We have a web service using Axis2 and rampart 1.3 and we'd like to use UsernameToken with password digest and authenticate the user against our LDAP server. Here's the problem: we don't have access to the clear text password since it is stored in a digested format in LDAP. We use the same algorithm to hash our passwords as should be used for password digest (Base64 encoded SHA-1 hash) as specified in this document: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-p rofile-1.0.pdf In my callback handler, I'd like to be able to somehow prevent Rampart from re-applying the digest algorithm to the password that I supply to the WSPasswordCallback: public void handle(Callback[] callbacks) throws IOException,UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof WSPasswordCallback) { WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i]; String encodedPassword = this.lookupEncodedLDAPPassword(pwcb.getIdentifer()); pwcb.setPassword(encodedPassword); //NOW PLEASE DON'T RE-APPLY DIGEST ALGORITHM! } } } It would be great if there was an alternative method on WSPasswordCallback like setDigestedPassword so that you could set it to the pre-digested value and then in whatever code tries to match this value with the value sent in the soap headers, it would see that the password property was null, then check the digestedPassword value and use that straight-up. Is there some way I can override this behavior without modifying the source? Have other people not had similar requirements (authentication against LDAP or AD with no access to the clear text password)? Otherwise, I am going to force the client to either send it in clear text (some how using the PasswordText option?) or the client code will have to apply the digest algorithm to the password before invoking the client stub resulting in the password being doubly-digested. The client is some PHP code and it is not clear to me how to have it use the PasswordText option... Any help is appreciated. thanks, aaron ********************************************************************** 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. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **********************************************************************
