GUMS and the Privilege architecture

This article is intended to describe GUMS in the Privilege Project context. Here we provide information about the components that make up the Privilege architecture, what GUMS interfaces to and how in a number of scenarios relevant to OSG.

What does GUMS do?

GUMS manages the mapping between grid identity (i.e. Certificates) and local identities (i.e. UNIX accounts). It's essentially the same function as the grid-mapfile.

Users can be mapped to accounts in a variety of ways:

  • map groups of users to shared group accounts
  • map users to pool accounts, one user per account
  • map users to group accounts manually

A gatekeeper (or a generic service) can retrieve the suitable map in two ways:

  • by using gums-host to retrieve the grid-mapfile
  • by calling directly the GUMS service for every request

The accounts themselves are created outside of GUMS. Particular accounts or ranges of accounts (e.g., xyz0000 to xyz9999) are then specified in the GUMS configuration file. The mapping policy as implemented in this file may take into account the grid identity of the user and his/her VO only, or it can accommodate extended attributes (implemented via voms-proxy-init) such as the user's role and group within the VO. Furthermore, different mapping policies may be implemented depending on the host chosen to process the job.

Specifying the mapping

The whole configuration of GUMS is specified in one configuration file (also called policy file) that governs it. The configuration file addresses three aspects of mapping:

  • Where to store user and mapping data, such as a database or LDAP (the storage is referred to as "persistence" in GUMS; the interface to it is called a "persistence factory")
  • Definitions of user groups and how they get mapped to accounts
  • Definitions of user group mappings on various hosts or groups of hosts

GUMS will typically be configured to retrieve user and VO information from a VO server (i.e. VOMS). GUMS downloads this information and stores it locally (mainly for performance).

GUMS client tools

The GUMS client tools are usually installed on the gatekeepers, and provide functionality for

  • retrieving maps from GUMS server and creating a grid-mapfile
  • forcing GUMS server to update the user lists from the VO servers
  • mapping users to manually-managed groups and mapping (i.e. users and maps that do not come from VO servers)

Workflow

For configuration:

  • Admin creates accounts (the accounts must be available on the gatekeeper and the worker nodes)
  • Admin creates GUMS configuration file specifying which VO servers and which persistence (e.g., mysql) will be used
  • Admin configures the gatekeeper to either retrieve the grid-mapfile from GUMS or to use the PRIMA module to connect to GUMS
  • GUMS reads the configuration file (the "rules") into memory.
  • GUMS consults the rules to find persistence factory information, and sets up connection to persistent storage
  • GUMS contacts VO service and downloads grid id information for all users in VO; stores it in persistence

For processing an individual mapping request (assuming only group accounts are to be used, no pool accounts, and assuming user of PRIMA):

  • Gatekeeper sends request for mapping to GUMS
  • GUMS receives request from gatekeeper
  • GUMS looks in user table to verify that user is there
  • GUMS consults configuration file rules to find out how to map user (in this case, it uses only group accounts).
  • GUMS maps user to the first group account for which he or she is eligible
  • GUMS sends message out via web service to gatekeeper; message contains one of three responses: Permission granted (send with "obligations"), Indeterminate (permission is not granted, but is not denied either), or Denied (user is not valid).

For processing an individual mapping request (assuming pool accounts are to be used):

  • Gatekeeper sends request for mapping to GUMS
  • GUMS receives request from gatekeeper
  • GUMS looks in user table to verify that user is there
  • GUMS consults configuration file rules to find out how to map user.
  • If user should be mapped to a pool account, GUMS checks the db to see if user is already mapped. If so, GUMS uses that mapping. If not, it creates a mapping and stores it in the table.
  • GUMS sends message out via web service to gatekeeper: Permission granted (send with "obligations"), Indeterminate (permission is not granted, but is not denied either), or Denied (user is not valid).

GUMS in the grid architecture

First, let's look at the Grid3 system which did not use GUMS. Users run grid-proxy init to get credentials, without contacting the VOMS server. Each gatekeeper at each site has to connect to VOMS independently (e.g., via edg-mkgridmap) in order to create its static grid-mapfile. This is done periodically. There is no support for centralized mapping at a site, account pools, dynamic mappings (that is, assigned on the fly), or role/group-based mappings. The inverse map for accounting (i.e., user-to-VO mapping) is created manually.

The next scenario shows GUMS implemented such that it sits between VOMS Admin and the client(s). The gatekeeper does not implement a callout to GUMS. GUMS polls VOMS Admin periodically to update its local list of users. The site may have only one GUMS server, in which case there would be only one communication point to VOMS, thus enabling centralized mapping. All clients would access the same information locally (a site could deploy multiple GUMS servers, but would lose the centralized mapping capability). GUMS downloads mapping information to each gatekeeper: the GUMS host tool, gums-host, replaces edg-mkgridmap in this diagram. The grid-mapfiles on all the gatekeeper can be made identical to each other if they all use the same GUMS server, or you can still have different maps for different gatekeepers of group of gatekeepers. The important feature is that you have one point of configuration for your facility. Gums-host also creates the inverse map for accounting consistent with the mapfile. Mapping to account pools is available.

The next image shows GUMS implemented in a legacy client scenario. Here we deploy the PRIMA module (see the VO Privilege Project) on the gatekeepers in order to enable dynamic mapping. There are no more grid-mapfiles. We continue to use the gums-host tool to generate the accounting map (if needed), but this breaks dynamic mapping when account pools are being used. (Whenever GUMS is asked to generate a map, it has to go through the whole policy, and assign an account for all the different possibilities. Therefore, accounts will be assigned to everybody beforehand when generating the map instead of when the individual request comes in.) A better implementation of the accouting system in OSG will address this. Role based authorization is still not available, as the client is generating normal proxies.

The next image shows GUMS implemented in a full support scenario. This is similar to the previous scenario except that the user now runs voms-proxy-init which VOMS uses to produce an extended proxy with role/group information. This information is extracted by PRIMA and communicated GUMS, which is now able to produce role/group-based mappings. We continue to use the gums-host tool to generate the accounting map if needed, but this breaks dynamic mapping when account pools are being used, as discussed above.

The next image shows a legacy server scenario. You can use voms-proxy-init, but you can't take advantage of its extended proxy features. You're back to having no support for any of the four items listed at bottom.