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