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
