OverviewUS CMS and US ATLAS, based at Fermilab and Brookhaven National Lab respectively, are sponsoring the VO Privilege Project to develop and implement fine-grained authorization for access to grid-enabled resources and services in order to improve user account assignment and management at grid sites, and reduce the associated administrative overhead. Authorization is to be linked to user roles. User-to-account mapping is to be flexible, dynamic, and based on both user role and least privilege access. It is a two-stage project that involves building and/or extending, implementing and integrating elements within the grid authorization architecture developed by the Grid2003 team. The VO Privilege Project software, depending on its implementation, relies on, interfaces to and further develops at least some of the following independent pieces of VO-implemented and site-implemented authorization software: VOMS, VOMRS, Gridmap callout interface, GUMS, and SAZ. The project schema requires a number of enhancements to these products, for example that VOMS dynamically add attributes to a user's proxy certificate specifying the role under which the user is making a request to access grid resources, and that GUMS act as an identity mapping service to map users to local accounts. The Globus gatekeeper Gridmap callout interface allows for the replacement of the built-in Gridmap file mechanism with a component (called PRIMA) that can query the GUMS identity mapping service. The interface between the PRIMA module and the GUMS identity mapping service is based on the OGSA SAML Authorization Interface, which is in the process of being standardized in the OGSA-Authorization working group of the GGF. Stage IThe first stage of VO Privilege development seeks to integrate VOMS, the Gridmap callout interface, and GUMS, and to develop the PRIMA software module to parse the Gridmap callouts and communicate with the GUMS identity mapping service. On or at a given grid resource, the integration of these elements is intended to:
Stage one also includes integrating the doors into the dCache storage system to also utilize the identity mapping service. Stage IIStage two will implement finer-grained access control in which a given role is assumed to grant the user a set of rights, and the user is charged with selecting from this set, enabling only those rights he or she will need, following the least privilege access principle. Least privilege access is intended to prevent accidental overusage and limit the damage a malicious entity can cause when a user's credentials are compromised. Stage two will also implement dynamic execution environments, designed to enforce access rules via file system access control lists, network firewall rules, system quotas, and so on. How it works, in a nutshellThe user is required to provide role-related information when requesting a proxy certificate from VOMS. (Each time a user wishes to change roles, he or she must request a new proxy certificate using the appropriate arguments.) When the proxy gets forwarded to a gatekeeper, a Gridmap callout invokes the PRIMA module. PRIMA extracts the VOMS attributes containing the VO and role information from the user's proxy certificate, and queries the identity mapping service for an appropriate local user account assignment. As a final step to user authorization, the gatekeeper contacts the Site Authorization Service (SAZ) which enforces the site-specific access control rules/policies, e.g., specifying prohibited users, checking for revoked certificates, and validating the user's certificate path.
Last modified by AH, ML on 9/23/04 |
