Venue server connection issue
Robert Olson
olson at mcs.anl.gov
Wed Feb 4 11:01:28 CST 2004
I'd mentioned a possible change required to support online CAs, etc.
Thought I'd outline the issues for people to think about.
Consider a world where one could use normal certs, myProxy-stored certs,
various online CAs, even username/password mechanisms to provide
authentication for attaching to a venue server. The basic problem is that
given a particular venue URL, one does not know what mechanism might be
valid for that venue server.
I envision a couple main solution spaces.
One is on the client side: when a client is requested to connect to a venue
server, it consults a local database to determine which authentication
mechanisms are valid for that server. The obvious problem is how this
database is populated.
The other solution is a collaboration between client and server, where a
venue URL isn't a pointer to the actual web service, but a pointer to a
services (be it SOAP, straight HTTP GET, whatever) that returns information
about the service - URL of the service, valid authentication mechanisms, etc.
The primary problem I see with the latter solution is that in the case of
firewalled servers, it requires another port to be opened. Other problems
include an additional roundtrip to the server (however, this may not have
to be a secured connection; it also is only done on the first connection to
a server) and the additional possible complications of connection code on
the client side.
I'm not yet ready to propose a solution, but I do lean toward the latter,
as it also expands the possibilites for other options on client/server
communications.
--bob
More information about the ag-dev
mailing list