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 [email protected] http://dankulp.com/blog
