cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
Subject Re: Http Authentication Policy
Date Sat, 10 Mar 2007 19:42:56 GMT

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.

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.

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.

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.  (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.

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.


On Mar 10, 2007, at 10:49 AM, Glynn, Eoghan wrote:

>> -----Original Message-----
>> From: Polar Humenn []
>> Sent: 09 March 2007 19:37
>> To:
>> 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="{}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="{}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

View raw message