cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <f...@dushin.net>
Subject Re: Http Authentication Policy
Date Fri, 09 Mar 2007 19:55:38 GMT
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
>>>
>>
>
>


Mime
View raw message