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 Mon, 12 Mar 2007 11:04:19 GMT


> -----Original Message-----
> From: Fred Dushin [mailto:fred@dushin.net] 
> Sent: 10 March 2007 19:43
> To: cxf-dev@incubator.apache.org
> Subject: Re: Http Authentication Policy
> 
> 
> Interesting thoughts.  Some high-level comments.
> 
> I agree with the 2x2 matrix you drew, as a classification of 
> the issues we are facing.
> 
> Regarding the idea of supplying a class name to presumably 
> dynamically load (your sec:UserPassSupplier), that's a fine 
> idea, but I wonder if it potentially runs into the same issue 
> as a similar suggestion I made about dynamically loading a 
> key-retrieval mechanism.  I'd thought at one time that we 
> could simply add a classname to the relevant SSL policy, in a 
> similar vein, and just dynamically load the thing, to do the 
> keystore retrieval.  But then it occurred to me, that's not 
> going to do it in the case of key retrieval, since there may 
> be additional information that is needed in order to actually 
> do the task (e.g., information needed to hook into SSPI).  
> Dynamically loaded classes are probably going to be 
> instantiated through their default ctors -- they won't be 
> given any contextual information about the runtime.  If, on 
> the other hand, these objects were spring-loaded, then 
> (knowing as little as I do about spring) I think we could 
> provide an extension point where additional config variables, 
> outside of the scope of our meager imagination, can be 
> provided by implementors of said callabcks.  I guess I 
> thought that one of the big reasons we are using this spring- 
> based mechanism.  Just a thought -- maybe these UserPass 
> callbacks should be spring beans, in their own right, instead 
> of a field in another bean.


Yep, fair point about the UserPassSupplier possibly requiring more
context than could be provided via a simple no-arg ctor called via
Class.forName().

This could be addressed by making the UserPassSupplier a Spring bean (so
that its dependencies are injected), but then <ref>erring to this bean
from within the AuthPolicy of the http-conduit bean (so that the
UserPassSupplier is now a dependency of the http-conduit bean, as
opposed to a completely free-standing bean).

So the example config would look something like:

  <bean id="CredsPrompter" class="com.acme.auth.CredsPrompter">
      <!-- dependencies ... -->
  </bean>

  <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>
            <ref bean="CredsPrompter"/>
         </sec:UserPassSupplier>
         <sec:Realm>governance</sec:Realm>
       </sec:credentials>
     <http:authorization/>
   </http:conduit>

See the following for more detail on intra-bean dependencies:

http://static.springframework.org/spring/docs/2.0.x/reference/beans.html
#beans-ref-element
 

 
> Now, getting on to the general issue of the 
> AuthorizationPolicy -- and the following comments apply 
> equally to the client- and server- SSL policies.  These 
> policy objects appear to be doing double-duty -- as i) 
> objects representing configuration settings, and ii) as 
> objects conveying information about contextual information 
> through the request.  In particular, on the receiving side of 
> an invocation, an AuthoriztionPolicy object is created to 
> represent the u/p sent over the wire.
>
> This is fairly innocuous in the u/p case, because what is it 
> -- 2 puny bits of information -- might as well just re-use 
> the structure you already defined in XSD.  But look now at 
> what we are proposing to do -- augment the data structure 
> with additional bits of information, some of which may have 
> no applicability in a request context.


Yep, good point, we should probably replace the reuse of
AuthorizationPolicy in the receiving context, with a separate
AuthorizationContext or somesuch. 

 
> This is even more insidious in the case of SSL information -- 
> I realize we don't do this now, but someone might be tempted 
> to use one of our SSL Policy objects to carry information 
> about the SSL session (cf CXF-445).  But of course most of 
> the information on this Policy object is completely 
> irrelevant to the request context -- the information on the 
> bean is configuration information needed to load up an SSL 
> endpoint (e.g., location of keystores, key alias passwords,
> etc) -- not information about the negotiated cipher suite, 
> peer certificates, etc.


Yep, agreed. The SSL Policies shouldn't be used to represent the SSL
context.

 
> Basically, I think we are conflating what in CORBA Security 
> terminology is OwnCredentials vs ReceivedCredentials -- an 
> incredibly important logical distinction to keep in any 
> middleware technology, OMG endorsed, or otherwise.  


Agreed.


> (Our application of CXF, BTW, makes this distinction crystal-clear)
> 
> So I would propose that we exercise some care in the 
> separation of config-based information and runtime 
> information, ostensibly representative of an identity on the 
> other side of a connection.  As I said, re-sue of the 
> AuthorizationPolicy object is innocuous -- now
> -- even if it does set a bad precedent.  But as we start to 
> augment it to handle 401s and other edge-case scenarios, we 
> are going to need to rethink whether it is an appropriate 
> data structure to use to convey received creds.  I mean, I'm 
> all for re-use of types, but only if the glove fits.


Agreed.

 
> Also, a slightly related, but orthogonal question -- is there 
> any reason the client and server SSL policies haven't been 
> refactored into common base (schema) types?  Or is this just 
> a matter of not having enough time to get to it?  They seem 
> fairly similar, at least glancing at the schema.


I'm not sure why this is the case ... as you say, there are only minor
differences between the types (the Want|RequireClientAuth elements in
the server policy and the ProxyHost|Port in the client).

Maybe whomever wrote the schemas originally wasn't familiar with the
derivation by extension (<xsd:extension base=...>) mechanism, or didn't
anticipate that the polices would turn out so similar, or maybe there
was a bug or restriction in the early JAXB RI versions relating to
extension.

But if you want to go ahead and consolidate the common elements of these
policies into a single base type, I'd be +1.

Cheers,
Eoghan

 
> -Fred
> 
> On Mar 10, 2007, at 10:49 AM, Glynn, Eoghan wrote:
> 
> >
> >> -----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