Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of polar.humenn@iona.com
 designates 65.223.216.181 as permitted sender)
Message-ID: <45F1CFA9.4080401@iona.com>
Date: Fri, 09 Mar 2007 16:20:41 -0500
From: Polar Humenn <phumenn@iona.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20070103)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Http Authentication Policy
References: <45F199C8.4030003@iona.com>
 <200703091244.43907.daniel.kulp@iona.com>
 <1E32FD2B-6DBA-46A7-ACDD-DE4AB6817E02@dushin.net> <45F1B760.5020508@iona.com>
 <5BF94CF5-8455-4741-BFDB-B884D6CEBFB2@dushin.net>
In-Reply-To: <5BF94CF5-8455-4741-BFDB-B884D6CEBFB2@dushin.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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