You are viewing a plain text version of this content. The canonical link for it is here.

Posted to rampart-dev@ws.apache.org by aa...@gmail.com on 2008/04/25 19:56:32 UTC

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-profile-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

Re: UsernameToken, Password Digest and LDAP

Posted by Nandana Mihindukulasooriya <na...@gmail.com>.

Hi Aaron,

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.


Yes, this is a known limitation.


> 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-profile-1.0.pdf
>

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.


This is a good suggestion.  WSPasswordCallback is from Apache WSS4J. Please
create a JIRA  [1] for this in WSS4J.


> Is there some way I can override this behavior without modifying the
> source?


IFAIK, answer is no.


> The client is some PHP code and it is not clear to me how to have it use
> the PasswordText option...
>

What is the PHP stack the client is using ?

thanks,
/nandana

[1] - http://issues.apache.org/jira/browse/WSS

RE: UsernameToken, Password Digest and LDAP

Posted by George Stanchev <Gs...@serena.com>.

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: aaronmevans@gmail.com [mailto:aaronmevans@gmail.com] 
Sent: Friday, April 25, 2008 11:57 AM
To: rampart-dev@ws.apache.org
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. 
**********************************************************************