> 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: [email protected]
>> web: www.soreco.ch
>>
>> soreco swiss business software since 1988
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Sergey Beryozkin [mailto:[email protected]]
>> Gesendet: Donnerstag, 19. August 2010 11:04
>> An: [email protected]
>> Betreff: Re: Web Service Authentication with Digest and External LDAP
>>
>> Hi
>>
>> On Thu, Aug 19, 2010 at 9:43 AM, Michael Dänzer
>> <[email protected]>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: [email protected]
>> > web: www.soreco.ch
>> >
>> > soreco swiss business software since 1988
>> >
>> >
>> >
>>
>
>

Reply via email to