U.S. CMS and U.S. ATLAS Privilege Project
http://computing.fnal.gov/docs/products/voprivilege/
Date: 2005-01-11, Last Updated 2005-01-17
Author: Markus Lorch, Email: mlorch at vt dot edu
Content:
This document is intended as a high-level overview and transition guideline for OpenScienceGrid sites wishing to employ improved access-control mechanisms for their Grid resources based on the mechanisms made available by the Privilege Project.
Virtual Organizations that want to become part of OpenScienceGrid will have to provide information on who the VO's members are. The mechanisms provided by the Privilege Project built on the management of VO members through VOMRS (The Virtual Organization Registration Service) and VOMS (the Virtual Organization Membership Service) as already practiced in Grid03 VOs. In Grid03 the membership information from VOMS was frequently converted into grid-mapfiles which in turn were distributed to the gatekeepers.
This basic approach has several limitations, most notably only a many-to-one mapping can effectively be implemented where all members of a VO get mapped to the same local identity. This decreases overall system and data security and hinders accounting due to the use of shared accounts. Individual one-to-one mappings, while theoretically possible, are typically not used due to prohibitive administrative overhead. Further more a single grid identity (certificate DN of a user) could not be member of more than one VO. To deal with this issue users sometimes had to hold, maintain and use multiple different identity certificates.
These issues and the motivation for the Privilege Project are documented in a motivational document. [motivation-2005-01-14.pdf].
The Privilege Project functionality developed for OSG-0 enables primarily two improved ways to manage the assignment of local user accounts:
The infrastructure provided by the Privilege Project components allows for additional functionality to be provided in the future. This functionality can include fine-grained access control decisions based on advanced access control policies as well as distributed management of access control through direct delegation of access rights.
Figure 1 provides an architectural overview that shows the components needed for "centralized identity mapping" in blue (PRIMA module, GUMS Server) and the additional components that enable "role-based identity mapping" in pink (VOMS-Proxy-Init). The light green components (VOMS and VOMRS or VOMS-admin) are already in place in Grid03 VOs but will need to be updated to current versions.
Figure 1 - Privilege Architecture Overview
The following sections provide information on what Privilege Project components are required to achieve either only the "centralized identity mapping" or also the "role-based identity mapping" functionality and their dependencies.
To support centralized identity mapping on compute resources two components are required. The PRIMA module on each gatekeeper and the GUMS server for each administrative domain (local user account domain).
1. PRIMA module requirements
2. GUMS requirements
3.1 PRIMA module configuration
3.2 VOMS-proxy-init
The following transition scenarios are envisioned in which the introduced components may not be deployed at all sites:
The following discussion assumes that existing Grid03 sites utilize a grid-map generation and distribution mechanisms that generates grid-map files from VOMS databases and distributes these files frequently to all Grid compute resources. The transition to support centralized identity mapping and role-based identity mapping is envisioned as follows:
Invalid ACs (ACs without a VOMS payload are being ignored) by the PRIMA module.
Due to the (current) seeding of the GUMS database from VOMS it is unlikely that there would be a VOMS issued attribute that GUMS doesn't know about. However, we already identified a scenario where people who are not in a VO (and thus not in a VOMS database) would like to run with a (locally managed) role and include a "desired role" attribute. PRIMA would pass this attribute on and GUMS makes a decision based on its policy (which may include these people and their roles) knowing that the attribute was in fact self-signed by the user. (this is not yet implemented for OSG-0)
In any case, depending on how the GUMS policy is written:
If the user requests a role that he/she is not a member of (in the view of GUMS) then
the mapping/access request will be denied. There is a good chance that by not requesting
a specific role (e.g. through a standard proxy) the user may be mapped to a
default account (which may be associated with a different VO than the user
intended). So I think this boils down to the issue of "What should be the
default VO/default mapping for a user". (see below)
This is the "what is the default VO/role" question from above. In Grid03
the user had to "know" which of his certificates is mapped to which
of his VOs at what site. This has been reduced to "to which role is
my certificate mapped to at site X".
This question is currently being discussed (2005-01-17).
In the current architecture it is up to the GUMS administrator to define this
behavior (default mapping) for the local site. I see that this may breed
confusion and issues on the user sites if the GUMS administrators at
different sites may different default mapping choices. (And they will).
E.g. if I run at FNAL my default (primary) VO may be USCMS, at BNL my
default VO may be USATLAS.
-> should we include a field in VOMRS which identifies a VO as a
primary VO?
-> should we recommend that there is no default mapping? Then legacy
proxy support would have to be specifically requested from the site/GUMS
administrator.
Then this user is not allowed at the GUMS site - even though he is a
member of a VO. Request is denied.
The GUMS server is able to map a user on the user's first access to a site to a previously unallocated user account (from a pool of precreated accounts). On subsequent accesses the user will always be mapped to the same account. This can alleviate delays present if standard allocation procedures, designed for interactive accounts at the site, are followed to create local user accounts for grid resources.
The GUMS identity mapping service can also provide, together with a local user ID, the local group ID and the set of supplemental group IDs that a request access should be executed with. This is a proposed mechanism that would allow to dynamically change the group access rights available to a user based e.g. on the current role the user has. This idea is discussed in more detail in a separate document [group mapping doc].
If group IDs and supplemental group IDs are to be dynamically set, the PRIMA module has to override the default group ID assignment based on /etc/password and /etc/group. Provisions must be in place that assure that the same mapping is being performed on the worker nodes of cluster computers at the time of job execution by the batch system. Prevalent batch systems do not support this dynamic, request-specific allocation of group IDs.