Re: Http Authentication Policy

[Fred Dushin]

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.

-Fred

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


-----Original Message-----
From: Polar Humenn [mailto:[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog