The VOMS Architecture

An high level view

In its core functionality, VOMS consists of a server process that can be contacted by users. After mutual authentication has been successful, the user process sends to the server a request for credential. At this point, the VOMS server checks in a database to see what attributes the user has a right to, and after having done an intersection with the attributes the user requested, they are returned in an Attribute Certificate. This procedure may be repeated any number of times, with any number of servers, and at the end all the gathered ACs are inserted in a non-critical extension of the user's proxy certificate.

A mid-level view

In a slightly more low-level view, it may be noticed that the components described are not the only ones that are present. Chief among the previously omitted ones, there is an administration interface, used to edit the database contents. This interface can be accessed through a browser or through a perl CLI. Then comes a set of APIs, in C, C++ and Java that are capable both of interpreting the attributes certificates when they are encountered and of contacting the server to get a brand-new AC. Finally, for backwards compatibility reasons, there is a mkgridmap service capable of creating gridmap-files from a VOMS server instead then from an LDAP server. However, as more and more services shy away from gridmapfiles and move to VOMS-based authorization, this feature will be removed.