You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Polar Humenn <ph...@iona.com> on 2007/03/09 18:30:48 UTC
Http Authentication Policy
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.
I would rather see username password supply operated more by the
application instead of some configuration manager. A username password
supplier interface either loaded as bus extension, or a configured for
particular endpoint would be sufficient It would interact with HTTP
username/password authentication mechanism either preemptively, or in
response to a 401 response.
That way the application developer can decide to have username/password
combinations in any number of places the application decides is safe.
For example, reading from the browser password file, throwing up a user
login window, etc.
I suggest the possible interface, which follows:
package org.apache.cxf.transport.http;
import org.apache.cxf.service.model.EndpointInfo;
/**
* This interface is called upon for the bus, or configured for a particular
* endpoint that uses an http-conduit, by the conduit to supply username
* and password information. The conduit first calls getPreemptiveUserPass
* to see if there is a username and password already supplied for that
* particular URL. If there is not, then no username and password can be
supplied
* for the outgoing http request. The conduit may then get a 401
response with
* a particular realm named. The conduit will always call the
getUserPass operation
* in response to a 401 with a WWW-Authenticate header.
* If this call returns null, the HTTP request will not be resent and
aborted as
* unauthenticated.
*
* The getUserPassForRealm call may cache its response, so that later
calls to
* getPreemptiveUserPass may supply the same username password combination
* for the same endpoint, or some address aspect of similar endpoints.
*
* It is important to note that in order to supply username password
information to a
* particular endpoint, sufficient trust in the connection to that
endpoint must be
* established through a EndpointTrustDecider, which is configured for
the particular
* endpoint represented by the URL, or for the entire bus.
*
* This trust decider, if it exists, is called by CXF before the
operations on this interface
* are invoked.
* It is also important to note, that CXF only has the ability to have a
trust decider for
* the HTTPS protocol, and does not have the ability to place a trust
decider
* for plain HTTP.
*/
public interface HTTPUserPassSupplier {
/**
* This interface represents a username
* password pair.
*/
public interface UserPass {
String getUsername();
String getPassword();
}
/**
* This operation returns a username password combination if
* the username and password may be supplied preemptively.
* It returns null, if there is no user/name password.
*/
public UserPass getPreemptiveUserPass(EndpointInfo ei);
/**
* This operation returns a username password combination for
* a particular realm and URL in the EndpointInfo, which may be in
* response to a 401 with a WWW-Authenticate response header.
*/
public UserPass getUserPassForRealm(EndpointInfo ei, String realm);
}
Cheers,
-Polar
Re: Http Authentication Policy
Posted by Fred Dushin <fr...@dushin.net>.
On Mar 9, 2007, at 12:44 PM, Daniel Kulp wrote:
> 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.
Slightly orthogonal, but the SSLClient policy [sic] is deficient in
that it only supports a URL specification of key material -- so it
basically has to be on the file system. (Not a logical requirement,
but a current implementation constraint). The security implications
of loading keys off an http URL are "outside of the scope of this
paper" :)
I'd like to see judicious use of a ClassLoader, and Java code that
does key material retrieval. Gives you the opportunity to get keys
programatically from somewhere other than a file.
Something as simple as
interface KeyRetrievalMechanism {
java.security.Keystore getKeyStore();
}
where a java.security.Keystore is just a canonical representation of
key/certificate material. Default impls can read off the filesystem.
This would let you (or your clients) hook into something like the
CDSA [1] with relative ease.
[1] Cf. http://www.opengroup.org/publications/catalog/c914.htm, open
source version available at http://developer.apple.com/opensource/
security/index.html
-Fred
Re: Http Authentication Policy
Posted by Polar Humenn <ph...@iona.com>.
Fred Dushin wrote:
> I don't get something you said ("anybody using it would have to
> subclass it anyway").
>
What I meant was, that if you were going to use the AuthenticationPolicy
object to return information, let's say from getUsername() from any
source other than the result of using the "setUsername()" operation,
you'd have to subclass it changing getUsername() to do something else,
i.e. look it up in a file, get it as result of a login window, etc.
violating it's contract with "setUsername()", etc.
That maybe classified as "re-use", but more like reusing a bus to mow
your lawn.
> But more to the point, why isn't the current AuthenticationPolicy
> object (leaving aside issues with name choice) just an instance of
> your UserPass object (other than the fact that one is an interface and
> the other is not, or is that relevant?) That's what I was getting at
> by "re-use", BTW.
>
My use of an interface for UserPass is merely a way to describe what is
being returned. We could very well specify to return one of these
AuthenticationPolicy objects. We might have to modify this anyway to
think to return user password information for the proxy as well. More on
that later.
However, what's the purpose of returning an informational object in this
case in which you have "set" operations?
> Also, I am fundamentally opposed to defining an interface when you
> mean a struct. Unless I am missing something about why you'd want
> UserPass to be an interface, or even anything other than a struct.
You mean "struct" as just a Java class with fields? Sure, but I thought
we had "checkstyle" hogwartiners preventing us from accessing fields
with out "get" operations.
>
> I am all for dynamic loading of something along the lines you propose,
> instead of requiring up-front, a priori knowledge of the realm into
> which you will be authenticating.
>
Well, I personally wouldn't do it this way, but that's how the http
protocol works, so we have to make it work that way. I guess I meant, I
wouldn't be using http for an object request response protocol. :) But
the gods are crazy.
> -Fred
>
> PS> Not to keep beating the same drum, but apropos to the issue of
> in-memory keystores, it might also be good to have the same kind of
> thing you propose, but for key retrieval, as well:
>
> <bean
> name="{http://....../EndpointName}.http-conduit.key-retrieval-mechanism"
> class="...."/>
>
Why not?
Cheers,
-Polar
> On Mar 9, 2007, at 2:37 PM, Polar Humenn wrote:
>
>> The AuthenticationPolicy object is only useful for preemptive supply
>> of user-pass information. 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.
>>
>> 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.
>>
>> 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.
>>
>> 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="...."/>
>>
>> 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
>>>>
>>>
>>
>>
>
Re: Http Authentication Policy
Posted by Fred Dushin <fr...@dushin.net>.
I don't get something you said ("anybody using it would have to
subclass it anyway").
But more to the point, why isn't the current AuthenticationPolicy
object (leaving aside issues with name choice) just an instance of
your UserPass object (other than the fact that one is an interface
and the other is not, or is that relevant?) That's what I was
getting at by "re-use", BTW.
Also, I am fundamentally opposed to defining an interface when you
mean a struct. Unless I am missing something about why you'd want
UserPass to be an interface, or even anything other than a struct.
I am all for dynamic loading of something along the lines you
propose, instead of requiring up-front, a priori knowledge of the
realm into which you will be authenticating.
-Fred
PS> Not to keep beating the same drum, but apropos to the issue of
in-memory keystores, it might also be good to have the same kind of
thing you propose, but for key retrieval, as well:
<bean name="{http://....../EndpointName}.http-conduit.key-retrieval-
mechanism" class="...."/>
On Mar 9, 2007, at 2:37 PM, Polar Humenn wrote:
> The AuthenticationPolicy object is only useful for preemptive
> supply of user-pass information. 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.
>
> 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.
>
> 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.
>
> 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="...."/>
>
> 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
>>>
>>
>
>
Re: Http Authentication Policy
Posted by Polar Humenn <ph...@iona.com>.
Dan Diephouse wrote:
> I think the idea is that a UserPassSupplier could pull information from a
> variety of sources. I might want instantiate my supplier with a
> reference to
> my database, in which case I could define my supplier as a bean in
> spring,
> and then just reference that bean on the conduit:
>
> <http:conduit userPassSupplier="#fooSupplier"/>
>
> <bean id="fooSupplier">
> <constructor-arg><ref>dataSource</ref></constructor-arg>
> </bean>
>
> Or I could be completely misunderstanding what you are talking about :-)
>
What I was concerned about was that the previous example seemed
"configure" the http conduit first with a "policy" structure, and then
"configure" that *policy* with some operational component in the middle.
The approach, modulo the particular syntax, is the less convolute, using
spring to "wire" operational sub-components together.
Cheers,
-Polar
> - Dan
>
> On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
>>
>> As Fred mentioned the difference between Own and Received Credentials in
>> an effort to maintain separation from "configuration" and "rutime
>> attributes", I would like to make a distinction of what is
>> "configuration" and what is "policy". There may be a fine line that I'm
>> sure will insight arguments :)
>>
>> "Configuring" an http-conduit to use a particular UserPassSupplier is
>> what I would consider "configuration" and seems to be an acceptable use
>> of Spring configuration (for those things the code writer and the
>> deployment engineer know need to be configured apriori).
>>
>> However, placing things like "reactive" authorization "policy" in a the
>> "configuration" space seems to muddle the waters between this
>> separation. I would like to see spring used at the conduit layer to
>> "hook" together the various components needed to get the job done, and
>> have those components query various policy structures if need be.
>>
>> Why does a conduit need to "configured" with anything more than a
>> particular UserPassSupplier?
>>
>> Cheers,
>> -Polar
>>
>>
>>
>> Fred Dushin wrote:
>> >
>> > On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
>> >
>> >> 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).
>> >
>> > Excellent -- this seems workable to me. Another option would of
>> > course be to dynamically load and instantiate via a more "interesting"
>> > ctor, but I am beginning to understand the benefits of Spring here --
>> > defining said ctor would require definition of some sort of contract
>> > ("You must define a public ctor that takes a map, such that ...
>> > etc"). With a bean, it's all more or less done for you (if you can
>> > figure out what "it" is :)
>> >
>> >
>> >> Yep, good point, we should probably replace the reuse of
>> >> AuthorizationPolicy in the receiving context, with a separate
>> >> AuthorizationContext or somesuch.
>> >
>> > Yes, let's make sure things in the "configuration" namespace are used
>> > for configuration, not for anything else.
>> >
>> >> But if you want to go ahead and consolidate the common elements of
>> these
>> >> policies into a single base type, I'd be +1.
>> >
>> > Sure, I'll try -- I also at one point tried to generate my own PKCS12
>> > file and trustdb, but ran into a wall. I'll try to revitalize that
>> > effort, at well, and document what I find are the requirements. My
>> > first pass failed for reasons I could not explain.
>> >
>> > -Fred
>>
>>
>
>
Re: Http Authentication Policy
Posted by Dan Diephouse <da...@envoisolutions.com>.
I think the idea is that a UserPassSupplier could pull information from a
variety of sources. I might want instantiate my supplier with a reference to
my database, in which case I could define my supplier as a bean in spring,
and then just reference that bean on the conduit:
<http:conduit userPassSupplier="#fooSupplier"/>
<bean id="fooSupplier">
<constructor-arg><ref>dataSource</ref></constructor-arg>
</bean>
Or I could be completely misunderstanding what you are talking about :-)
- Dan
On 3/12/07, Polar Humenn <ph...@iona.com> wrote:
>
> As Fred mentioned the difference between Own and Received Credentials in
> an effort to maintain separation from "configuration" and "rutime
> attributes", I would like to make a distinction of what is
> "configuration" and what is "policy". There may be a fine line that I'm
> sure will insight arguments :)
>
> "Configuring" an http-conduit to use a particular UserPassSupplier is
> what I would consider "configuration" and seems to be an acceptable use
> of Spring configuration (for those things the code writer and the
> deployment engineer know need to be configured apriori).
>
> However, placing things like "reactive" authorization "policy" in a the
> "configuration" space seems to muddle the waters between this
> separation. I would like to see spring used at the conduit layer to
> "hook" together the various components needed to get the job done, and
> have those components query various policy structures if need be.
>
> Why does a conduit need to "configured" with anything more than a
> particular UserPassSupplier?
>
> Cheers,
> -Polar
>
>
>
> Fred Dushin wrote:
> >
> > On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
> >
> >> 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).
> >
> > Excellent -- this seems workable to me. Another option would of
> > course be to dynamically load and instantiate via a more "interesting"
> > ctor, but I am beginning to understand the benefits of Spring here --
> > defining said ctor would require definition of some sort of contract
> > ("You must define a public ctor that takes a map, such that ...
> > etc"). With a bean, it's all more or less done for you (if you can
> > figure out what "it" is :)
> >
> >
> >> Yep, good point, we should probably replace the reuse of
> >> AuthorizationPolicy in the receiving context, with a separate
> >> AuthorizationContext or somesuch.
> >
> > Yes, let's make sure things in the "configuration" namespace are used
> > for configuration, not for anything else.
> >
> >> But if you want to go ahead and consolidate the common elements of
> these
> >> policies into a single base type, I'd be +1.
> >
> > Sure, I'll try -- I also at one point tried to generate my own PKCS12
> > file and trustdb, but ran into a wall. I'll try to revitalize that
> > effort, at well, and document what I find are the requirements. My
> > first pass failed for reasons I could not explain.
> >
> > -Fred
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Http Authentication Policy
Posted by Polar Humenn <ph...@iona.com>.
As Fred mentioned the difference between Own and Received Credentials in
an effort to maintain separation from "configuration" and "rutime
attributes", I would like to make a distinction of what is
"configuration" and what is "policy". There may be a fine line that I'm
sure will insight arguments :)
"Configuring" an http-conduit to use a particular UserPassSupplier is
what I would consider "configuration" and seems to be an acceptable use
of Spring configuration (for those things the code writer and the
deployment engineer know need to be configured apriori).
However, placing things like "reactive" authorization "policy" in a the
"configuration" space seems to muddle the waters between this
separation. I would like to see spring used at the conduit layer to
"hook" together the various components needed to get the job done, and
have those components query various policy structures if need be.
Why does a conduit need to "configured" with anything more than a
particular UserPassSupplier?
Cheers,
-Polar
Fred Dushin wrote:
>
> On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
>
>> 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).
>
> Excellent -- this seems workable to me. Another option would of
> course be to dynamically load and instantiate via a more "interesting"
> ctor, but I am beginning to understand the benefits of Spring here --
> defining said ctor would require definition of some sort of contract
> ("You must define a public ctor that takes a map, such that ...
> etc"). With a bean, it's all more or less done for you (if you can
> figure out what "it" is :)
>
>
>> Yep, good point, we should probably replace the reuse of
>> AuthorizationPolicy in the receiving context, with a separate
>> AuthorizationContext or somesuch.
>
> Yes, let's make sure things in the "configuration" namespace are used
> for configuration, not for anything else.
>
>> But if you want to go ahead and consolidate the common elements of these
>> policies into a single base type, I'd be +1.
>
> Sure, I'll try -- I also at one point tried to generate my own PKCS12
> file and trustdb, but ran into a wall. I'll try to revitalize that
> effort, at well, and document what I find are the requirements. My
> first pass failed for reasons I could not explain.
>
> -Fred
Re: Http Authentication Policy
Posted by Fred Dushin <fr...@dushin.net>.
On Mar 12, 2007, at 7:04 AM, Glynn, Eoghan wrote:
> 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).
Excellent -- this seems workable to me. Another option would of
course be to dynamically load and instantiate via a more
"interesting" ctor, but I am beginning to understand the benefits of
Spring here -- defining said ctor would require definition of some
sort of contract ("You must define a public ctor that takes a map,
such that ... etc"). With a bean, it's all more or less done for you
(if you can figure out what "it" is :)
> Yep, good point, we should probably replace the reuse of
> AuthorizationPolicy in the receiving context, with a separate
> AuthorizationContext or somesuch.
Yes, let's make sure things in the "configuration" namespace are used
for configuration, not for anything else.
> But if you want to go ahead and consolidate the common elements of
> these
> policies into a single base type, I'd be +1.
Sure, I'll try -- I also at one point tried to generate my own PKCS12
file and trustdb, but ran into a wall. I'll try to revitalize that
effort, at well, and document what I find are the requirements. My
first pass failed for reasons I could not explain.
-Fred
RE: Http Authentication Policy
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----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
> >>>>
> >>>
> >>
> >>
> >
>
>
Re: Http Authentication Policy
Posted by Fred Dushin <fr...@dushin.net>.
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: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
>>>>
>>>
>>
>>
>
RE: Http Authentication Policy
Posted by "Glynn, Eoghan" <eo...@iona.com>.
> -----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
> >>
> >
>
>
Re: Http Authentication Policy
Posted by Polar Humenn <ph...@iona.com>.
The AuthenticationPolicy object is only useful for preemptive supply of
user-pass information. 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.
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.
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.
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="...."/>
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
>>
>
Re: Http Authentication Policy
Posted by Fred Dushin <fr...@dushin.net>.
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
>
Re: Http Authentication Policy
Posted by Daniel Kulp <da...@iona.com>.
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
Re: Http Authentication Policy
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Polar
I'd suggest minor refactoring
> public interface UserPassSupplier {
with HTTPUserPassSupplier extending it and adding HTTP specific
> public UserPass getUserPassForRealm(EndpointInfo ei, String realm);
What is the advantage of having UserPass being modelled as interface ?
Cheers, Sergey
----- Original Message -----
From: "Polar Humenn" <ph...@iona.com>
To: <cx...@incubator.apache.org>
Sent: Friday, March 09, 2007 5:30 PM
Subject: Http Authentication Policy
>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.
>
> I would rather see username password supply operated more by the
> application instead of some configuration manager. A username password
> supplier interface either loaded as bus extension, or a configured for
> particular endpoint would be sufficient It would interact with HTTP
> username/password authentication mechanism either preemptively, or in
> response to a 401 response.
>
> That way the application developer can decide to have username/password
> combinations in any number of places the application decides is safe.
> For example, reading from the browser password file, throwing up a user
> login window, etc.
>
> I suggest the possible interface, which follows:
>
> package org.apache.cxf.transport.http;
>
> import org.apache.cxf.service.model.EndpointInfo;
>
> /**
> * This interface is called upon for the bus, or configured for a particular
> * endpoint that uses an http-conduit, by the conduit to supply username
> * and password information. The conduit first calls getPreemptiveUserPass
> * to see if there is a username and password already supplied for that
> * particular URL. If there is not, then no username and password can be
> supplied
> * for the outgoing http request. The conduit may then get a 401
> response with
> * a particular realm named. The conduit will always call the
> getUserPass operation
> * in response to a 401 with a WWW-Authenticate header.
> * If this call returns null, the HTTP request will not be resent and
> aborted as
> * unauthenticated.
> *
> * The getUserPassForRealm call may cache its response, so that later
> calls to
> * getPreemptiveUserPass may supply the same username password combination
> * for the same endpoint, or some address aspect of similar endpoints.
> *
> * It is important to note that in order to supply username password
> information to a
> * particular endpoint, sufficient trust in the connection to that
> endpoint must be
> * established through a EndpointTrustDecider, which is configured for
> the particular
> * endpoint represented by the URL, or for the entire bus.
> *
> * This trust decider, if it exists, is called by CXF before the
> operations on this interface
> * are invoked.
> * It is also important to note, that CXF only has the ability to have a
> trust decider for
> * the HTTPS protocol, and does not have the ability to place a trust
> decider
> * for plain HTTP.
> */
> public interface HTTPUserPassSupplier {
>
> /**
> * This interface represents a username
> * password pair.
> */
> public interface UserPass {
> String getUsername();
> String getPassword();
> }
>
> /**
> * This operation returns a username password combination if
> * the username and password may be supplied preemptively.
> * It returns null, if there is no user/name password.
> */
> public UserPass getPreemptiveUserPass(EndpointInfo ei);
>
> /**
> * This operation returns a username password combination for
> * a particular realm and URL in the EndpointInfo, which may be in
> * response to a 401 with a WWW-Authenticate response header.
> */
> public UserPass getUserPassForRealm(EndpointInfo ei, String realm);
>
> }
>
> Cheers,
> -Polar