Hi Polar
I'd suggest minor refactoring
public interface UserPassSupplier {
with HTTPUserPassSupplier extending it and adding HTTP specific
public UserPass getUserPassForRealm(EndpointInfo ei, String realm);
What is the advantage of having UserPass being modelled as interface ?
Cheers, Sergey
----- Original Message -----
From: "Polar Humenn" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, March 09, 2007 5:30 PM
Subject: Http Authentication Policy
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.
I would rather see username password supply operated more by the
application instead of some configuration manager. A username password
supplier interface either loaded as bus extension, or a configured for
particular endpoint would be sufficient It would interact with HTTP
username/password authentication mechanism either preemptively, or in
response to a 401 response.
That way the application developer can decide to have username/password
combinations in any number of places the application decides is safe.
For example, reading from the browser password file, throwing up a user
login window, etc.
I suggest the possible interface, which follows:
package org.apache.cxf.transport.http;
import org.apache.cxf.service.model.EndpointInfo;
/**
* This interface is called upon for the bus, or configured for a particular
* endpoint that uses an http-conduit, by the conduit to supply username
* and password information. The conduit first calls getPreemptiveUserPass
* to see if there is a username and password already supplied for that
* particular URL. If there is not, then no username and password can be
supplied
* for the outgoing http request. The conduit may then get a 401
response with
* a particular realm named. The conduit will always call the
getUserPass operation
* in response to a 401 with a WWW-Authenticate header.
* If this call returns null, the HTTP request will not be resent and
aborted as
* unauthenticated.
*
* The getUserPassForRealm call may cache its response, so that later
calls to
* getPreemptiveUserPass may supply the same username password combination
* for the same endpoint, or some address aspect of similar endpoints.
*
* It is important to note that in order to supply username password
information to a
* particular endpoint, sufficient trust in the connection to that
endpoint must be
* established through a EndpointTrustDecider, which is configured for
the particular
* endpoint represented by the URL, or for the entire bus.
*
* This trust decider, if it exists, is called by CXF before the
operations on this interface
* are invoked.
* It is also important to note, that CXF only has the ability to have a
trust decider for
* the HTTPS protocol, and does not have the ability to place a trust
decider
* for plain HTTP.
*/
public interface HTTPUserPassSupplier {
/**
* This interface represents a username
* password pair.
*/
public interface UserPass {
String getUsername();
String getPassword();
}
/**
* This operation returns a username password combination if
* the username and password may be supplied preemptively.
* It returns null, if there is no user/name password.
*/
public UserPass getPreemptiveUserPass(EndpointInfo ei);
/**
* This operation returns a username password combination for
* a particular realm and URL in the EndpointInfo, which may be in
* response to a 401 with a WWW-Authenticate response header.
*/
public UserPass getUserPassForRealm(EndpointInfo ei, String realm);
}
Cheers,
-Polar
