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
