> -----Original Message-----
> From: Fred Dushin [mailto:[EMAIL PROTECTED]
> Sent: 10 March 2007 19:43
> To: [email protected]
> 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:[EMAIL PROTECTED]
> >> Sent: 09 March 2007 19:37
> >> To: [email protected]
> >> 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
> >>>>
> >>>
> >>
> >>
> >
>
>
