You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Michael Dänzer <Mi...@ivyteam.ch> on 2010/08/19 10:43:32 UTC
Web Service Authentication with Digest and External LDAP
Hi All
We need to authenticate calls to our web services that send the password either as plain text (WSS-Password Type: PasswordText) or as a digest (WSS Password Type: PasswordDigest). In addition, I need to authenticate by LDAP to an active directory.
The plain text thing works, either with WSS4JInInterceptor and a custom password callback handler or by subclassing AbstractUsernameTokenAuthenticatingInterceptor and overwriting the createSubject() method in there. So far so good.
The digest thing on the other hand I am not able to get running. WSS4JInInterceptor cannot be used because it requires getting the plain text password from the AD, which is not possible. So, I tried AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds like it is intended to be used for my specific use case). But as soon as the password is digested, my overwritten createSubject () method is never called and therefore the authentication fails.
As far as I seem there are two calls to that method. One is restricted to the plain text password case (DelegatingCallbackHandler.handle()), the other to the CustomUsernameTokenProcessor. So, do I miss some configuration setting so that the custom processor is used? Or is there even a bug!
Kind regards
Michael Dänzer
MSc UZH, Software Entwickler
Ivyteam AG
Alpenstrasse 9
CH-6403 Zug
Zentrale:+41 (0) 58 666 34 34
e-mail: michael.daenzer@soreco.ch
web: www.soreco.ch
soreco swiss business software since 1988
Re: AW: Web Service Authentication with Digest and External LDAP
Posted by lives <li...@gmail.com>.
Hi,
Thanks Sergey for the explanation.
what i understand is that the Subject that is created will not have the raw
password , but the password digest.
This cannot be decrypted .So how can the authentication be done against an
LDAP or DB ?
Thanks for your reply
lives
--
View this message in context: http://cxf.547215.n5.nabble.com/Web-Service-Authentication-with-Digest-and-External-LDAP-tp2640606p2803345.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: AW: Web Service Authentication with Digest and External LDAP
Posted by lives <li...@gmail.com>.
Hi,
Thanks Sergey for the explanation.
what i understand is that the Subject that is created will not have the raw
password , but the password digest.
This cannot be decrypted .So how can the authentication be done against an
LDAP or DB ?
Thanks for your reply
lives
--
View this message in context: http://cxf.547215.n5.nabble.com/Web-Service-Authentication-with-Digest-and-External-LDAP-tp2640606p2803330.html
Sent from the cxf-user mailing list archive at Nabble.com.
AW: Web Service Authentication with Digest and External LDAP
Posted by Michael Dänzer <Mi...@ivyteam.ch>.
Hi Sergey
Thanks a lot, that did it.
Kind regards
Michael Dänzer
MSc UZH, Software Entwickler
Ivyteam AG
Alpenstrasse 9
CH-6403 Zug
Zentrale:+41 (0) 58 666 34 34
e-mail: michael.daenzer@soreco.ch
web: www.soreco.ch
soreco swiss business software since 1988
-----Ursprüngliche Nachricht-----
Von: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Gesendet: Donnerstag, 19. August 2010 11:50
An: users@cxf.apache.org
Betreff: Re: Web Service Authentication with Digest and External LDAP
> The above initialization code should fix it - if not I'm not sure - I
definitely have a test with digest passwords
> working, but the workaround test I posted in the previous message is still
used there
Meant the "workaround code"
>
> let me know how it goes
>
> Sergey
>
>
> Kind regards
>
>> Michael Dänzer
>> MSc UZH, Software Entwickler
>>
>> Ivyteam AG
>> Alpenstrasse 9
>> CH-6403 Zug
>>
>> Zentrale:+41 (0) 58 666 34 34
>> e-mail: michael.daenzer@soreco.ch
>> web: www.soreco.ch
>>
>> soreco swiss business software since 1988
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Gesendet: Donnerstag, 19. August 2010 11:04
>> An: users@cxf.apache.org
>> Betreff: Re: Web Service Authentication with Digest and External LDAP
>>
>> Hi
>>
>> On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
>> <Mi...@ivyteam.ch>wrote:
>>
>> > Hi All
>> >
>> > We need to authenticate calls to our web services that send the password
>> > either as plain text (WSS-Password Type: PasswordText) or as a digest
>> (WSS
>> > Password Type: PasswordDigest). In addition, I need to authenticate by
>> LDAP
>> > to an active directory.
>> >
>> > The plain text thing works, either with WSS4JInInterceptor and a custom
>> > password callback handler or by subclassing
>> > AbstractUsernameTokenAuthenticatingInterceptor and overwriting the
>> > createSubject() method in there. So far so good.
>> >
>> > The digest thing on the other hand I am not able to get running.
>> > WSS4JInInterceptor cannot be used because it requires getting the plain
>> text
>> > password from the AD, which is not possible. So, I tried
>> > AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds
>> like it
>> > is intended to be used for my specific use case). But as soon as the
>> > password is digested, my overwritten createSubject () method is never
>> called
>> > and therefore the authentication fails.
>> >
>> > As far as I seem there are two calls to that method. One is restricted
>> to
>> > the plain text password case (DelegatingCallbackHandler.handle()), the
>> other
>> > to the CustomUsernameTokenProcessor. So, do I miss some configuration
>> > setting so that the custom processor is used? Or is there even a bug!
>> >
>> >
>>
>> There was indeed a bug in 2.2.9 to do with digest passwords causing issues
>> when AbstractUsernameTokenAuthenticatingInterceptor was used. This is
>> fixed
>> in 2.2.10.
>> If you can not upgrade then the following workaround should do the trick.
>> Add the following to the subclass :
>>
>> public class SomeInterceptor extends
>> AbstractUsernameTokenAuthenticatingInterceptor {
>>
>> private boolean supportDigestPasswords;
>>
>> // this code is a temporarily workaround;
>> AbstractUsernameTokenAuthenticatingInterceptor
>> // has a bug to do with handling digests; RequestData assumes
>> PasswordDigest by default
>> @Override
>> public void setSupportDigestPasswords(boolean support)
>> {
>> this.supportDigestPasswords = support;
>> super.setSupportDigestPasswords(support);
>> }
>>
>> // TODO : this code is a temporarily workaround;
>> AbstractUsernameTokenAuthenticatingInterceptor
>> // has a bug to do with handling digests; RequestData assumes
>> PasswordDigest by default
>> @Override
>> protected CallbackHandler getCallback(RequestData reqData, int doAction)
>> throws WSSecurityException
>> {
>>
>> if (supportDigestPasswords)
>> {
>> return new CallbackHandler()
>> {
>> @Override
>> public void handle(Callback[] callbacks) throws IOException,
>> UnsupportedCallbackException
>> {
>> // dummy handler
>> }
>> };
>> }
>> else
>> {
>> return super.getCallback(reqData, doAction);
>> }
>> }
>>
>> ...
>> }
>>
>> This should help and the above code would not be needed with CXF 2.2.10
>> being used.
>>
>> Alternativley, you can try adding a policy to WSDL and extend the other
>> interceptor, see
>>
>>
>> http://cxf.547215.n5.nabble.com/Username-token-with-HashPassword-td2473163.html#a2473176
>>
>> This latter option would not require the above workaround
>>
>> hope it helps, Sergey
>>
>>
>> Kind regards
>> > Michael Dänzer
>> > MSc UZH, Software Entwickler
>> >
>> > Ivyteam AG
>> > Alpenstrasse 9
>> > CH-6403 Zug
>> >
>> > Zentrale:+41 (0) 58 666 34 34
>> > e-mail: michael.daenzer@soreco.ch
>> > web: www.soreco.ch
>> >
>> > soreco swiss business software since 1988
>> >
>> >
>> >
>>
>
>
Re: Web Service Authentication with Digest and External LDAP
Posted by Sergey Beryozkin <sb...@gmail.com>.
> The above initialization code should fix it - if not I'm not sure - I
definitely have a test with digest passwords
> working, but the workaround test I posted in the previous message is still
used there
Meant the "workaround code"
>
> let me know how it goes
>
> Sergey
>
>
> Kind regards
>
>> Michael Dänzer
>> MSc UZH, Software Entwickler
>>
>> Ivyteam AG
>> Alpenstrasse 9
>> CH-6403 Zug
>>
>> Zentrale:+41 (0) 58 666 34 34
>> e-mail: michael.daenzer@soreco.ch
>> web: www.soreco.ch
>>
>> soreco swiss business software since 1988
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Gesendet: Donnerstag, 19. August 2010 11:04
>> An: users@cxf.apache.org
>> Betreff: Re: Web Service Authentication with Digest and External LDAP
>>
>> Hi
>>
>> On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
>> <Mi...@ivyteam.ch>wrote:
>>
>> > Hi All
>> >
>> > We need to authenticate calls to our web services that send the password
>> > either as plain text (WSS-Password Type: PasswordText) or as a digest
>> (WSS
>> > Password Type: PasswordDigest). In addition, I need to authenticate by
>> LDAP
>> > to an active directory.
>> >
>> > The plain text thing works, either with WSS4JInInterceptor and a custom
>> > password callback handler or by subclassing
>> > AbstractUsernameTokenAuthenticatingInterceptor and overwriting the
>> > createSubject() method in there. So far so good.
>> >
>> > The digest thing on the other hand I am not able to get running.
>> > WSS4JInInterceptor cannot be used because it requires getting the plain
>> text
>> > password from the AD, which is not possible. So, I tried
>> > AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds
>> like it
>> > is intended to be used for my specific use case). But as soon as the
>> > password is digested, my overwritten createSubject () method is never
>> called
>> > and therefore the authentication fails.
>> >
>> > As far as I seem there are two calls to that method. One is restricted
>> to
>> > the plain text password case (DelegatingCallbackHandler.handle()), the
>> other
>> > to the CustomUsernameTokenProcessor. So, do I miss some configuration
>> > setting so that the custom processor is used? Or is there even a bug!
>> >
>> >
>>
>> There was indeed a bug in 2.2.9 to do with digest passwords causing issues
>> when AbstractUsernameTokenAuthenticatingInterceptor was used. This is
>> fixed
>> in 2.2.10.
>> If you can not upgrade then the following workaround should do the trick.
>> Add the following to the subclass :
>>
>> public class SomeInterceptor extends
>> AbstractUsernameTokenAuthenticatingInterceptor {
>>
>> private boolean supportDigestPasswords;
>>
>> // this code is a temporarily workaround;
>> AbstractUsernameTokenAuthenticatingInterceptor
>> // has a bug to do with handling digests; RequestData assumes
>> PasswordDigest by default
>> @Override
>> public void setSupportDigestPasswords(boolean support)
>> {
>> this.supportDigestPasswords = support;
>> super.setSupportDigestPasswords(support);
>> }
>>
>> // TODO : this code is a temporarily workaround;
>> AbstractUsernameTokenAuthenticatingInterceptor
>> // has a bug to do with handling digests; RequestData assumes
>> PasswordDigest by default
>> @Override
>> protected CallbackHandler getCallback(RequestData reqData, int doAction)
>> throws WSSecurityException
>> {
>>
>> if (supportDigestPasswords)
>> {
>> return new CallbackHandler()
>> {
>> @Override
>> public void handle(Callback[] callbacks) throws IOException,
>> UnsupportedCallbackException
>> {
>> // dummy handler
>> }
>> };
>> }
>> else
>> {
>> return super.getCallback(reqData, doAction);
>> }
>> }
>>
>> ...
>> }
>>
>> This should help and the above code would not be needed with CXF 2.2.10
>> being used.
>>
>> Alternativley, you can try adding a policy to WSDL and extend the other
>> interceptor, see
>>
>>
>> http://cxf.547215.n5.nabble.com/Username-token-with-HashPassword-td2473163.html#a2473176
>>
>> This latter option would not require the above workaround
>>
>> hope it helps, Sergey
>>
>>
>> Kind regards
>> > Michael Dänzer
>> > MSc UZH, Software Entwickler
>> >
>> > Ivyteam AG
>> > Alpenstrasse 9
>> > CH-6403 Zug
>> >
>> > Zentrale:+41 (0) 58 666 34 34
>> > e-mail: michael.daenzer@soreco.ch
>> > web: www.soreco.ch
>> >
>> > soreco swiss business software since 1988
>> >
>> >
>> >
>>
>
>
Re: Web Service Authentication with Digest and External LDAP
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Thu, Aug 19, 2010 at 10:26 AM, Michael Dänzer <Michael.Daenzer@ivyteam.ch
> wrote:
> Hello
>
> Thanks for the fast answer, I updated to CXF 2.2.10, but still have the
> same issue (as well adding your code to the 2.2.9 code did not help). I
> still do not get called in the createSubject method!
>
> What I do is the following (everything is done programmatically as we
> create ws implementations and deploy the web services dynamically):
>
> Map<String,Object> inProps= new HashMap<String,Object>();
> inProps.put(WSHandlerConstants.ACTION,
> WSHandlerConstants.USERNAME_TOKEN);
> inProps.put(WSHandlerConstants.PASSWORD_TYPE,
> WSConstants.PW_DIGEST);
> server.getEndpoint().getInInterceptors().add(new
> MyActiveDirectoyInterceptor(inProps));
> server.start();
>
>
in my own test I do not add a PASSWORD_TYPE property; I also set a
'supportDigestPasswords' property on the interceptor (not using a map, but
setSupportDigestPasswords). 'supportDigestPasswords' property is not really
needed, I introduced it originally to optimize a bit the way the abstract
interceptor works but may be it can be deprecated - use it just for now... :
Map<String,Object> inProps= new HashMap<String,Object>();
inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
MyActiveDirectoyInterceptor in = new MyActiveDirectoyInterceptor(inProps);
inProps.setSupportDigestPasswords(true);
server.getEndpoint().getInInterceptors().add(in);
server.start();
And the interceptor subclass:
>
> import java.util.Map;
> import javax.security.auth.Subject;
> import org.apache.cxf.common.security.SimplePrincipal;
> import
> org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor;
>
> public class MyActiveDirectoyInterceptor extends
> AbstractUsernameTokenAuthenticatingInterceptor
> {
> public MyActiveDirectoyInterceptor(Map<String, Object> properties)
> {
> super(properties);
> }
>
> @Override
> protected Subject createSubject(String name, String password,
> boolean isDigest, String nonce, String created)
> throws SecurityException
> {
> Subject subject = new Subject();
> subject.getPrincipals().add(new SimplePrincipal(name));
> return subject;
> }
> }
>
> Did I forget something?
>
>
The above initialization code should fix it - if not I'm not sure - I
definitely have a test with digest passwords working, but the workaround
test I posted in the previous message is still used there
let me know how it goes
Sergey
Kind regards
> Michael Dänzer
> MSc UZH, Software Entwickler
>
> Ivyteam AG
> Alpenstrasse 9
> CH-6403 Zug
>
> Zentrale:+41 (0) 58 666 34 34
> e-mail: michael.daenzer@soreco.ch
> web: www.soreco.ch
>
> soreco swiss business software since 1988
>
>
> -----Ursprüngliche Nachricht-----
> Von: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Gesendet: Donnerstag, 19. August 2010 11:04
> An: users@cxf.apache.org
> Betreff: Re: Web Service Authentication with Digest and External LDAP
>
> Hi
>
> On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
> <Mi...@ivyteam.ch>wrote:
>
> > Hi All
> >
> > We need to authenticate calls to our web services that send the password
> > either as plain text (WSS-Password Type: PasswordText) or as a digest
> (WSS
> > Password Type: PasswordDigest). In addition, I need to authenticate by
> LDAP
> > to an active directory.
> >
> > The plain text thing works, either with WSS4JInInterceptor and a custom
> > password callback handler or by subclassing
> > AbstractUsernameTokenAuthenticatingInterceptor and overwriting the
> > createSubject() method in there. So far so good.
> >
> > The digest thing on the other hand I am not able to get running.
> > WSS4JInInterceptor cannot be used because it requires getting the plain
> text
> > password from the AD, which is not possible. So, I tried
> > AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds like
> it
> > is intended to be used for my specific use case). But as soon as the
> > password is digested, my overwritten createSubject () method is never
> called
> > and therefore the authentication fails.
> >
> > As far as I seem there are two calls to that method. One is restricted to
> > the plain text password case (DelegatingCallbackHandler.handle()), the
> other
> > to the CustomUsernameTokenProcessor. So, do I miss some configuration
> > setting so that the custom processor is used? Or is there even a bug!
> >
> >
>
> There was indeed a bug in 2.2.9 to do with digest passwords causing issues
> when AbstractUsernameTokenAuthenticatingInterceptor was used. This is fixed
> in 2.2.10.
> If you can not upgrade then the following workaround should do the trick.
> Add the following to the subclass :
>
> public class SomeInterceptor extends
> AbstractUsernameTokenAuthenticatingInterceptor {
>
> private boolean supportDigestPasswords;
>
> // this code is a temporarily workaround;
> AbstractUsernameTokenAuthenticatingInterceptor
> // has a bug to do with handling digests; RequestData assumes
> PasswordDigest by default
> @Override
> public void setSupportDigestPasswords(boolean support)
> {
> this.supportDigestPasswords = support;
> super.setSupportDigestPasswords(support);
> }
>
> // TODO : this code is a temporarily workaround;
> AbstractUsernameTokenAuthenticatingInterceptor
> // has a bug to do with handling digests; RequestData assumes
> PasswordDigest by default
> @Override
> protected CallbackHandler getCallback(RequestData reqData, int doAction)
> throws WSSecurityException
> {
>
> if (supportDigestPasswords)
> {
> return new CallbackHandler()
> {
> @Override
> public void handle(Callback[] callbacks) throws IOException,
> UnsupportedCallbackException
> {
> // dummy handler
> }
> };
> }
> else
> {
> return super.getCallback(reqData, doAction);
> }
> }
>
> ...
> }
>
> This should help and the above code would not be needed with CXF 2.2.10
> being used.
>
> Alternativley, you can try adding a policy to WSDL and extend the other
> interceptor, see
>
>
> http://cxf.547215.n5.nabble.com/Username-token-with-HashPassword-td2473163.html#a2473176
>
> This latter option would not require the above workaround
>
> hope it helps, Sergey
>
>
> Kind regards
> > Michael Dänzer
> > MSc UZH, Software Entwickler
> >
> > Ivyteam AG
> > Alpenstrasse 9
> > CH-6403 Zug
> >
> > Zentrale:+41 (0) 58 666 34 34
> > e-mail: michael.daenzer@soreco.ch
> > web: www.soreco.ch
> >
> > soreco swiss business software since 1988
> >
> >
> >
>
AW: Web Service Authentication with Digest and External LDAP
Posted by Michael Dänzer <Mi...@ivyteam.ch>.
Hello
Thanks for the fast answer, I updated to CXF 2.2.10, but still have the same issue (as well adding your code to the 2.2.9 code did not help). I still do not get called in the createSubject method!
What I do is the following (everything is done programmatically as we create ws implementations and deploy the web services dynamically):
Map<String,Object> inProps= new HashMap<String,Object>();
inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
inProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_DIGEST);
server.getEndpoint().getInInterceptors().add(new MyActiveDirectoyInterceptor(inProps));
server.start();
And the interceptor subclass:
import java.util.Map;
import javax.security.auth.Subject;
import org.apache.cxf.common.security.SimplePrincipal;
import org.apache.cxf.ws.security.wss4j.AbstractUsernameTokenAuthenticatingInterceptor;
public class MyActiveDirectoyInterceptor extends AbstractUsernameTokenAuthenticatingInterceptor
{
public MyActiveDirectoyInterceptor(Map<String, Object> properties)
{
super(properties);
}
@Override
protected Subject createSubject(String name, String password, boolean isDigest, String nonce, String created)
throws SecurityException
{
Subject subject = new Subject();
subject.getPrincipals().add(new SimplePrincipal(name));
return subject;
}
}
Did I forget something?
Kind regards
Michael Dänzer
MSc UZH, Software Entwickler
Ivyteam AG
Alpenstrasse 9
CH-6403 Zug
Zentrale:+41 (0) 58 666 34 34
e-mail: michael.daenzer@soreco.ch
web: www.soreco.ch
soreco swiss business software since 1988
-----Ursprüngliche Nachricht-----
Von: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Gesendet: Donnerstag, 19. August 2010 11:04
An: users@cxf.apache.org
Betreff: Re: Web Service Authentication with Digest and External LDAP
Hi
On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
<Mi...@ivyteam.ch>wrote:
> Hi All
>
> We need to authenticate calls to our web services that send the password
> either as plain text (WSS-Password Type: PasswordText) or as a digest (WSS
> Password Type: PasswordDigest). In addition, I need to authenticate by LDAP
> to an active directory.
>
> The plain text thing works, either with WSS4JInInterceptor and a custom
> password callback handler or by subclassing
> AbstractUsernameTokenAuthenticatingInterceptor and overwriting the
> createSubject() method in there. So far so good.
>
> The digest thing on the other hand I am not able to get running.
> WSS4JInInterceptor cannot be used because it requires getting the plain text
> password from the AD, which is not possible. So, I tried
> AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds like it
> is intended to be used for my specific use case). But as soon as the
> password is digested, my overwritten createSubject () method is never called
> and therefore the authentication fails.
>
> As far as I seem there are two calls to that method. One is restricted to
> the plain text password case (DelegatingCallbackHandler.handle()), the other
> to the CustomUsernameTokenProcessor. So, do I miss some configuration
> setting so that the custom processor is used? Or is there even a bug!
>
>
There was indeed a bug in 2.2.9 to do with digest passwords causing issues
when AbstractUsernameTokenAuthenticatingInterceptor was used. This is fixed
in 2.2.10.
If you can not upgrade then the following workaround should do the trick.
Add the following to the subclass :
public class SomeInterceptor extends
AbstractUsernameTokenAuthenticatingInterceptor {
private boolean supportDigestPasswords;
// this code is a temporarily workaround;
AbstractUsernameTokenAuthenticatingInterceptor
// has a bug to do with handling digests; RequestData assumes
PasswordDigest by default
@Override
public void setSupportDigestPasswords(boolean support)
{
this.supportDigestPasswords = support;
super.setSupportDigestPasswords(support);
}
// TODO : this code is a temporarily workaround;
AbstractUsernameTokenAuthenticatingInterceptor
// has a bug to do with handling digests; RequestData assumes
PasswordDigest by default
@Override
protected CallbackHandler getCallback(RequestData reqData, int doAction)
throws WSSecurityException
{
if (supportDigestPasswords)
{
return new CallbackHandler()
{
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException
{
// dummy handler
}
};
}
else
{
return super.getCallback(reqData, doAction);
}
}
...
}
This should help and the above code would not be needed with CXF 2.2.10
being used.
Alternativley, you can try adding a policy to WSDL and extend the other
interceptor, see
http://cxf.547215.n5.nabble.com/Username-token-with-HashPassword-td2473163.html#a2473176
This latter option would not require the above workaround
hope it helps, Sergey
Kind regards
> Michael Dänzer
> MSc UZH, Software Entwickler
>
> Ivyteam AG
> Alpenstrasse 9
> CH-6403 Zug
>
> Zentrale:+41 (0) 58 666 34 34
> e-mail: michael.daenzer@soreco.ch
> web: www.soreco.ch
>
> soreco swiss business software since 1988
>
>
>
Re: Web Service Authentication with Digest and External LDAP
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
<Mi...@ivyteam.ch>wrote:
> Hi All
>
> We need to authenticate calls to our web services that send the password
> either as plain text (WSS-Password Type: PasswordText) or as a digest (WSS
> Password Type: PasswordDigest). In addition, I need to authenticate by LDAP
> to an active directory.
>
> The plain text thing works, either with WSS4JInInterceptor and a custom
> password callback handler or by subclassing
> AbstractUsernameTokenAuthenticatingInterceptor and overwriting the
> createSubject() method in there. So far so good.
>
> The digest thing on the other hand I am not able to get running.
> WSS4JInInterceptor cannot be used because it requires getting the plain text
> password from the AD, which is not possible. So, I tried
> AbstractUsernameTokenAuthenticatingInterceptor (whose javadoc sounds like it
> is intended to be used for my specific use case). But as soon as the
> password is digested, my overwritten createSubject () method is never called
> and therefore the authentication fails.
>
> As far as I seem there are two calls to that method. One is restricted to
> the plain text password case (DelegatingCallbackHandler.handle()), the other
> to the CustomUsernameTokenProcessor. So, do I miss some configuration
> setting so that the custom processor is used? Or is there even a bug!
>
>
There was indeed a bug in 2.2.9 to do with digest passwords causing issues
when AbstractUsernameTokenAuthenticatingInterceptor was used. This is fixed
in 2.2.10.
If you can not upgrade then the following workaround should do the trick.
Add the following to the subclass :
public class SomeInterceptor extends
AbstractUsernameTokenAuthenticatingInterceptor {
private boolean supportDigestPasswords;
// this code is a temporarily workaround;
AbstractUsernameTokenAuthenticatingInterceptor
// has a bug to do with handling digests; RequestData assumes
PasswordDigest by default
@Override
public void setSupportDigestPasswords(boolean support)
{
this.supportDigestPasswords = support;
super.setSupportDigestPasswords(support);
}
// TODO : this code is a temporarily workaround;
AbstractUsernameTokenAuthenticatingInterceptor
// has a bug to do with handling digests; RequestData assumes
PasswordDigest by default
@Override
protected CallbackHandler getCallback(RequestData reqData, int doAction)
throws WSSecurityException
{
if (supportDigestPasswords)
{
return new CallbackHandler()
{
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException
{
// dummy handler
}
};
}
else
{
return super.getCallback(reqData, doAction);
}
}
...
}
This should help and the above code would not be needed with CXF 2.2.10
being used.
Alternativley, you can try adding a policy to WSDL and extend the other
interceptor, see
http://cxf.547215.n5.nabble.com/Username-token-with-HashPassword-td2473163.html#a2473176
This latter option would not require the above workaround
hope it helps, Sergey
Kind regards
> Michael Dänzer
> MSc UZH, Software Entwickler
>
> Ivyteam AG
> Alpenstrasse 9
> CH-6403 Zug
>
> Zentrale:+41 (0) 58 666 34 34
> e-mail: michael.daenzer@soreco.ch
> web: www.soreco.ch
>
> soreco swiss business software since 1988
>
>
>