I present a UML model for authenticated and authorized usage of the VO. I assume the following points.
The model consists in the UML diagrams as follows.
The rest of this document contains notes on the meaning of the diagrams.
The data-centres are shown as having local gatekeeper-daemons. These are the interface-programmes that already exist at the data-centres to which the new code provided by the VO needs to connect. In general, the LocalGatekeepers don't support the VO's APIs and protocols.
The VO provides VoGatekeeper daemons to the data-centres so as to make a uniform interface to each data-service. A VoGatekeeper handles all the authentication and authorization for an incoming request from the VO, then pass the request to the LocalGatekeeper in a form that the latter can understand. Because each VoGatekeeper is colocated to one LocalGatekeeper, the hand-off of requests from the former to the latter can be made secure using local communication channels; the LocalGatekeeper can trust all incoming requests from its VoGatekeeper.
The catalogue of affiliations by user is common to the entire VO. It can be centralized, probably with mirroring to improve reliability. The centralization makes it easier to update the catalogue. All VoGatekeepers refer to the central catalogue during authorization of requests.
If mirroring is efficient and can be done securely, the affiliation catalogue could be mirrored to every data-centre attached to the VO. This would remove the need for one of the network operations for each authorization. A central, master copy would still be needed as the target for updates. The replicas at the data-centres would be be read-only copies of the master.
The catalogue of affiliations could be distributed. For example, there might be separate catalogues of users for AstroGrid, AVO and NVO. The AffiliationService objects should then hide the distribution and make the catalogue seem homogeneous. This means that we can start off with an AstroGrid-only catalogue and attach it to AVO and NVO catalogues later, if those organization decide to use the same protocols.
Each data-centre has its own access policy, and hence its own catalogue of permissions on its resources. There is no real reason to centralize these catalogues, so I have shown them local to the data-centres.
The deployment diagram has one node marked as "the VO". The objects running on this node can be anywhere on the grid, which distinguishes them from the objects that need to be at a specific data-centre.
In practice, the objects "at the VO" are likely to be located at one of the data-centres attached to the VO, in facilities leased by or donated to the VO.
The current scheme shows gatekeeper software provided by the VO running at the data-centres: it maps VO protocols to local standards. This is a different technique to system like Vizier which do the mapping to local standards in a VoPortal. The difference is due to the needs for authentication: Vizier does not deal with identified usage, and the services it connects to typically do not provide a secure way of authenticating.
In principal, it is possible to place the VoGatekeeper at a portal site and to have it talk to a LocalGatekeeper using some non-standard authentication protocol...if such a protocol exists. In practise, it seems easier to put some VO software into each data-centre. If a given data-centre offers only public-domain, read-only data, then no authentication is needed and the VoGatekeeper (which is still needed to localize the queries) can be at the portal site.
VoJobRequest is an association class: it represents the data that are passed in the association. The VoJobRequest is a superclass for all requests to VoGatekeepers, and it provides a place to carry the user's credentials. The subclasses VoQueryRequest, VoIdUpdateRequest and VoPermUpdateRequest define the nature of the job.
The association class Query represents the parameters of a query to a data-resource. The exact format of the Query is likely to be different for each association.
Many jobs don't need identified access. In these cases, the user agents should put a a null IdCertificate in the VoJobRequest, and the VoGatekeepers will then know not to bother with authentication or authorization.
Given that standard web-browsers don't know about VO protocols, and that some identified work must be done using web browsers, we need a secure link from the browser to the portal that is separate from the main authentication scheme.
In general, authentication schemes based on web-browsers don't allow single sign-on for an entire network, and don't support delegation of authorities beyond the server that the browser talks to. This is a problem for the VO, because the portal wishes to talk to data-centres on the user's behalf and needs a delegated authority to do so.
The model shows this as a two-part operation: a simple VoUserAgent programme is used to enable a proxy for the user at the portal which is tied to the identity presented by the user's browser. The portal then has full VO abilities including delegation which it will only use in requests that it can identify as coming from that browser. The browser then only needs to authenticate to the portal, not to the entire VO.
A user of the VO needs, on his or her computer:
The whole model is biased to an implementation with Grid Security Infrastructure from Globus. The dual authentication to the VoPortal would be done with the "myProxy" system.
If the user agents, portals and VoGatekeepers communicate using SOAP, then VoJobRequest and its sub-classes can be implemented as XML structures to go in the SOAP messages.
