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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
