cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Http Authentication Policy
Date Sat, 10 Mar 2007 15:49:40 GMT

> -----Original Message-----
> From: Polar Humenn [mailto:phumenn@iona.com] 
> Sent: 09 March 2007 19:37
> To: cxf-dev@incubator.apache.org
> Subject: Re: Http Authentication Policy
> 
> The AuthenticationPolicy object is only useful for preemptive 
> supply of user-pass information.

Yes, as things currently stand, the AuthorizationPolicy is 'only useful
for preemptive supply of user-pass information'.

However with some minor extensions, I think it could support any
sensible auth style. 

Just to be clear on terminology, in my view there are two independent
choices to be made:

1. Preemptive or reactive:

a) send the username/password upfront without waiting for a challenge,
or 
b) send the creds only after receiving a 401 response with
WWW-Authenticate header

2. Static or dynamic:

a) retrieve the username/password from static CXF config
b) provide the username/password dynamically via a programmatic
mechanism

So we end up with a total of four combinations: preemptive/static,
reactive/static, preemptive/dynamic & reactive/dynamic.

We already support preemptive/static and preemptive/dynamic (via the
mechanism mentioned by DanK).

As I've pointed out before, reactive/static could be easily modeled by
extending the AuthorizationPolicy to allow for multiple
username/password pairs each with an associated realm. The main
difficulty around reactive is not IMO how do retrieve the creds, but
more how do we efficiently do transparent resend on 401s.

The final combo is reactive/dynamic. With a bit of creativity, I think
this could be handled within the framework of the AuthorizationPolicy
also. For example, a very simple approach would be to add a new element
giving the name of the UserPassSupplier class to instantiate.

So whereas currently we're limited to something like this:

 <http:conduit id="{http://cxf.apache.org/foo}MyPort.http-conduit">
    <http:authorization>
      <!-- single set of creds to be sent preemptively,
           regardless of realm -->
      <sec:UserName>bob</sec:UserName>
      <sec:Password>wizard</sec:Password>
    <http:authorization/>
  </http:conduit>

the schema could easily be extended to support something like the
following:

 <http:conduit id="{http://cxf.apache.org/foo}MyPort.http-conduit">
    <http:authorization>
      <!-- multiple sets of creds to be sent reactively,
           depending on realm -->
      <sec:credentials>
        <sec:UserName>bob</sec:UserName>
        <sec:Password>wizard</sec:Password>
        <sec:Realm>discovery</sec:Realm>
      </sec:credentials>
      <sec:credentials>
 
<sec:UserPassSupplier>com.acme.auth.CredsPrompter</sec:UserPassSupplier>
        <sec:Realm>governance</sec:Realm>
      </sec:credentials>
    <http:authorization/>
  </http:conduit>


> The AuthenticationPolicy 
> object is a JAXB generated object based on some XML schema, 
> so anybody using it would have to subclass it anyway veering 
> from it's intended use as the representation of a static XML document.


JAXB generated types are not restricted to usage as a 'representation of
a static XML document'.

Of course that's their primary purpose. But there's nothing to stop an
application creating an instance of one of these types, populating the
fields via the set*() methods, and then using the instance completely
decoupled from XML.

And there is no need to sub-class the JAXB generated types in order to
adopt this style. For example, CXF uses the generated
EndpointReferenceType extensively, sometimes completely decoupled from
XML, with the fields of the EPR being populated from say the
EndpointInfo or the address parameter to Endpoint.publish().


> Also, if the object is created programmatically and put on 
> message properties, it still cannot react to a 401 response 
> in which a realm is specified.


As I pointed out above, the (currently non-existent) support for
reactive mode is orthogonal to the (static or dynamic) method of
receiving the credentials.


> Furthermore, if we take "configuration" as being part of the 
> "application" the only configuration option we have is to 
> place sensitive username password information in config file 
> conforming to the AuthenticatonPolicy's corresponding XML 
> schema definition.


As I pointed out above, the schema can be easily extended to support
dynamic retrieval of the credentials, if placing these in a config file
is a problem (although I would argue that for a large class of
unattended client apps, the static model is the correct choice).

 
> If configuration is the "way forward" for "modern 
> programming" I'd like to see an object like the one proposed 
> to be instantiated for a particular endpoint, something like so:
> 
> <bean name="{http://....../EndpointName}.http-conduit.user-pass-auth" 
> class="...."/>


Lets try to keep all retreival (whether static or dynamic) of auth info
consolidated in the AuthorizationPolicy.

Cheers,
Eoghan

 
> Cheers,
> -Polar
> 
> 
> Fred Dushin wrote:
> >
> > Would the AuthenticationPolicy object be useful in a 401 challenge 
> > scenario?  I have no qualms with re-use of this object, but bear in 
> > mind that we want to be able to support dynamic retrieval of a u/p, 
> > which must be keyed off the realm passed back from the server in a 
> > WWW-authenticate header.
> >
> > On Mar 9, 2007, at 12:44 PM, Daniel Kulp wrote:
> >
> >>
> >> Polar,
> >>
> >> On Friday 09 March 2007 12:30, Polar Humenn wrote:
> >>> I have a concern about the HTTP Authentication Policy that is 
> >>> configurable in a CXF deployment. My first concern is 
> that username 
> >>> and passwords are stored in a config file. This situation may be 
> >>> acceptable in a few cases, but I would like to see alternatives.
> >>
> >> There are already alternatives.   The AuthenticationPolicy 
> object can be
> >> created programatically and passed in via the message 
> properties.   
> >> If the
> >> object is available on the message, it's used.   Likewise 
> for all the
> >> SSLClientPolicy.
> >>
> >> The JAX-WS frontend maps the standard JAX-WS USERNAME and PASSWORD
> >> properties onto the AuthenticationPolicy object.   
> However, they also 
> >> have
> >> access to the Policy object itself if they want.  I'd 
> greatly prefer 
> >> to keep it that way.
> >>
> >>
> >> --J. Daniel Kulp
> >> Principal Engineer
> >> IONA
> >> P: 781-902-8727    C: 508-380-7194
> >> daniel.kulp@iona.com
> >> http://www.dankulp.com/blog
> >>
> >
> 
> 

Mime
View raw message