cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Request for feedback: Refactoring of HTTP client authentication
Date Thu, 23 Dec 2010 03:41:33 GMT

I like it.  Looks fine by me.    The only "concern" I have is with:

> Additionally I would like to remove the feature of setting an
> AuthorizationPolicy on the message. This would allow us to make the
> authsuppliers independent of conduit and message in the future.

as that would likely break a bunch of things.    For one, how do you plan on 
having the JAX-WS username/password properties?   Currently, we map those 
directly onto and AuthorizationPolicy object on the message.  Thus, that 
interaction would need to change as well.

Dan





On Wednesday 22 December 2010 2:39:16 pm Christian Schneider wrote:
> I have now refactored the authentication of the http transport so the
> basic auth is now supported by DefaultBasicAuthSupplier. Spnego is now
> also supported using a SpnegoAuthSupplier.
> 
> As I have changed some of the behaviour I would like to get some
> feedback before committing this.
> Please also see:
> https://issues.apache.org/jira/browse/CXF-3216
> 
> Basic, Digest and Spnego / Kerberos auth can now be configured by simply
> setting the AuthType in the AuthorizationPolicy. The HttpConduit then
> creates a HttpAuthSupplier on the fly if none is configured explicitly.
> Still an AuthoriationPolicy on the message overrides the
> AuthorizationPolicy on the Conduit.
> 
> I have also added a system test for DigestAuthSupplier as I changed the
> code and wanted to make sure it really works against a jetty insstance.
> 
> There are some possible compatibility issues with my patch:
> 
>     * The first thing is that the HttpAuthSupplier is cached so it is
>       created only once. If you later change the Authtype the supplier
>       will stay the same. This can be solved by deleting the
>       authSupplier so it is recreated.
>     * The HttpAuthsupplier now overrides the AuthorizationPolicy on the
>       message. Before the AuthorizationPolicy on the message would
>       override the AuthSupplier. I don?t think anyone really would use this
>     * If the message content is to be cached is now only determined by
>       calling the requiresRequestCaching method on the authsupplier.
>       Before the authSupplier was also asked for
>       premptiveAuthentication. If this did not return null the message
>       was also cached. I think this is not necessary as the authsupplier
>       can still decide if caching is needed.
>     * Currently you can set authType and authorization on the
>       authorizationPolicy. This is then used to directly create the
>       authorization header. This is used by the old spnego interceptor I
>       added recently. I removed this feature as it is only really usable
>       in an interceptor and it can be done better by creating a custom
>       authSupplier
> 
> Additionally I would like to remove the feature of setting an
> AuthorizationPolicy on the message. This would allow us to make the
> authsuppliers independent of conduit and message in the future.
> 
> I also would like to introduce an authSupplier for proxy auth and
> handling of 407 responses so we can support multi phase authentications
> with a proxy.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message