problems with VO certificate authorities

From: Roy Williams <roy-at-cacr.caltech.edu>
Date: Tue, 24 Oct 2006 09:20:38 -0700


This note refers to:
Single-Sign-On Authentication for the IVO: introduction and description of principles
http://www.ivoa.net/Documents/Notes/SSO/SSO-introduction-20051002.html

Guy and Ray

As you know, we are building a system (Nesssi) to allow VO clients to run secure batch jobs on major computing resources. The intention is to support a multiple usage models, where the client can be authenticated weakly or strongly, and can use a web page or a commandline to drive the system. We have been following the model outlined in your paper above, but I think it is time to revise the document.

We have built two prototypes, one is complicated and based on your proposed VO model, and the other is much simpler and is what the HEP community has adopted. Each aims to connect a Client to a Resource securely. We are not considering workflows or delegation in our model.

Specifically:
(1) The NVO model keeps all certificates (aka "warrants") in a
certificate store, and only issues proxies. This forces one of two architectures:
(a) There is an intermediate Proxy between Client and Resource that
connects to the cert store, gets a proxy, and sends it to the Resource on behalf of the Client. Note that there are now four systems interacting securely. This is quite a complex and delicate arrangement.
(b) The user runs a program that connects to the cert store to obtain a
proxy, then sends that to the Resource. It works well for commandline access, but is awkward if the client uses web access -- because the proxy must be loaded into the browser again *every day*.

(2) The HEP model assumes that the Client has the certificate locally.
For commandline, a proxy can be created with a program like globus_proxy_init. For web application, the cert is loaded *once* into the browser, and a Javascript application used to connect to the Resource. The advantages are:
-- No need for a Proxy machine between Client and Resource, and no need for the cert store (except once to fetch the cert). -- Easily extensible to "normal" certificate authorites, where you get the cert itself instead of all this messing about with cert stores and proxies.

THEREFORE I would like to use VO certificate authorities for VO work. BUT it is awkward to do so because of the artificial restrictions that are embedded in the model, specifically two of your Recommendations in section 9: "Don't issue long-term warrants to users" and "Issue warrants to user agents, not to users"

If these can be eliminated, I would be happy with using VO-sanctioned cert authorities.

Thank you
Roy Received on 2006-10-24Z18:21:51