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