--- On Fri, 4/30/10, Scott Lawrence <[email protected]> wrote:
> > > Will that work with standard SOAP clients?
> They all
> > > accept a cleartext username/password, and provide
> it when
> > > challenged, either with BASIC or Digest depending
> on what
> > > the server asks for. If it asks for Digest,
> yet
> > > expects something different in the response, it
> doesn't seem
> > > like that'll work.
> > >
> > > --Woof!
> >
> > This is wrt XX-8253: as Woof! figured out, there are
> some issues with
> > digest auth in sipx. Checking Acegi ref
> > ( http://www.acegisecurity.org/guide/springsecurity.html#digest
> )
> > looks like digest auth process needs clear text
> passwords in
> > authentication providers, and is not our case.
>
> The acegi implementation of digest may need cleartext
> passwords in the
> provider, but the standard does not. It can be
> implemented such that
> the server needs only H(A1), which is
> BASE64(MD5(user:realm:password)).
>
> JAIN-SIP implements digest... perhaps you could use its
> implementation?
Thanks for the clue, I will take a look at JAIN-SIP digest - however IMO we
should stick with Acegi at least for this release...
Just to detail a little - there are several filters defined for various auth
types (inside security.beans.xml, URLs and auth modes are mapped inside
filterChainProxy bean):
- basicProcessingFilter for Basic auth (instance of
org.acegisecurity.ui.basicauth.BasicProcessingFilter, creates an
UsernamePasswordAuthenticationToken and updates the Security context with) -
can be tested using curl
- authenticationProcessingFilter for Form based auth (instance of
org.acegisecurity.ui.webapp.AuthenticationProcessingFilter, creates an
UsernamePasswordAuthenticationToken and updates the Security context with) -
sipxconfig login page
- digestProcessingFilter for Digest auth (instance of
org.acegisecurity.ui.digestauth.DigestProcessingFilter, creates an
UsernamePasswordAuthenticationToken and updates the Security context with) -
can be tested using Mozilla or Opera browsers, or better - using soapUI
(version 3.5 supports REST requests as well)
Next step in auth process is to perform an additional authentication check
within an user authentication provider - extract the raw password from token,
encode it and compare with the one stored in db. Here is where sipxconfig
digest auth fails since the password is already encoded.
The hack I made - extended digestProcessingFilter to create an
DigestUsernamePasswordAuthenticationToken instead the standard
UsernamePasswordAuthenticationToken one. Then, user authentication provider
checks the token type - if digest token, password will not be encoded one more
time but directly compared with db.
(I've also considered adding an additional user authentication provider that
does not encode password prior to compare with db, but this means that all auth
will fall in this one - could result in user being able to login from
sipxconfig UI by passing encoded password)
I am going to post a patch shortly so anyone interested to take a look at.
Thanks,
George
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
