Venue server connection issue

[Ivan R. Judson]

How does this compare with or integrate with solutions that would use SASL
or ws-security?

--Ivan

> -----Original Message-----
> From: owner-ag-dev at mcs.anl.gov
> [mailto:owner-ag-dev at mcs.anl.gov] On Behalf Of Robert Olson
> Sent: Wednesday, February 04, 2004 11:01 AM
> To: ag-dev at mcs.anl.gov
> Subject: Venue server connection issue
>
> 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
>
>