An Introduction to User Authorization and Privilege in OSG
In OSG there are a few different models of user authorization to choose from. The simplest uses a gridmap file at the site, which statically maps an authenticated grid user to a site-local account name. The most sophisticated is called "full privilege", and it implements an authorization software module (PRIMA) that interacts with a dynamic mapping service (GUMS) at the site. There's an intermediate solution called "compatability", which shares elements of both.
The difference between the simplest (called Grid3 for historical reasons) and the compatibility models is the source of the VO membership data/account assignments. In Grid3, each CE node pulls independently from the VO management servers. In compatibility, each CE node for your site pulls the data from the site mapping server; thus, centralized mapping is enabled.
Under full privilege
, centralized mapping is enabled. The VOs
can set varying policies for different user groups and roles
in order to limit which tasks the users can perform and with what priorities, on an access-by-access basis. Users
can choose an appropriate group/role combination according to the activity they plan to perform. They require a special kind of certificate proxy (called a VOMS proxy) in order to pass along this information with their jobs. Sites’
computing and storage resources can intelligently enforce priorities and data access rights set at the VO level and can identify users and stop their activities as needed, while adhering to their site-specific security requirements.
More information on these models?
You must install VOMS (or equivalent), and optionally VOMRS. These are described in the Glossary
. Several things have to be done after VOMS installation to enable your VO to be used for voms proxy generation, and for the Compatibility and Full Privilege authorization modes on destination compute (CE) and storage (SE) element nodes. These steps are described in the VOMS?
When you install a CE, you choose a form of user authorization?
, and follow the instructions for implementing it. If you choose compatibility or full privilege, you'll have to install the Grid User Mapping Service, GUMS?
The authorization/privilege components are described below and are shown in the following diagram:
- VOMS The Virtual Organization Membership Service organizes grid users into Virtual Organizations (VOs), so that users working together on a common project across multiple real organizations can be grouped together in the privilege system. Each VOMS server instance lists the X509 certificate for each user belonging to its VO and may include other information about users including the subgroups and roles in which they participate. VOMS is used to find out whether a user is a member of the VO or one of its subgroups, and whether the user may assume a given role or capability. The VOMS Admin web application and service (not shown in the diagram) is used to manage the VO, and voms-proxy-init is the client side tool that an end user uses to obtain a proxy certificate.
- GUMS The Grid User Management System maps an end-user's credentials (proxy certificates) to a local user account under which the user's job can be run. While a GUMS service can be configured to perform all mappings based on a static configuration, typically it is configured to look up users in one or more VOMS servers and to map them based on VO membership and role(s).
- PRIMA The PRIvilege Management and Authorization component is the interface between a Globus Toolkit gatekeeper (or other GSI service) and a mapping service like GUMS. It implements a Globus authorization callout by packaging requests in the SOAP web service format required by GUMS and handling responses.
On VOMS Host
Which part communicates privileges to GOC? [D.O. - I don't think the VOMS communicates to the GOC.]
- VOMS-Admin (one per VO): an administrative interface to the VOMS database. Allows the VO manager to maintain a list of VO members, and assign membership to VO groups and roles. Allows edg-mkgridmap and GUMS to retrieve the list.
- VOMS Server (one per VO): server component that allows creation of extended proxies. It's separate from VOMS-Admin, but uses the same database.
- VOMS-Admin publisher: Publishes the existence of a VOMS-Admin service to the Discovery Service [D.O. - I don't think this exists] .
On Submission Host
- VOMS Client (on each submission host): allows a user to generate a proxy with
voms-proxy-init that contains VO/group/role information. It contacts the VOMS Server to generate the proxy.
- edg-mkgridmap (on each gatekeeper not served by GUMS): a script that generates the grid-mapfile downloading information from VOMS servers. It runs every so often on a gatekeeper, contacts the list of VOMS servers specified in the configuration file (edg/etc/edg-mkgridmap.conf), and creates a grid-mapfile.
- GUMS Server (one per site): a service that allows you to manage privilege-to-userid mapping on site. It can be contacted by GUMS Client (below) to generate grid-mapfiles and the inverse accounting map (account-to-VO). It can also be contacted by the PRIMA module (below) to retrieve the mapping for a single request.
- GUMS Client (on each gatekeeper): a client tool that connects to GUMS Server to retrieve maps (grid-mapfile and accounting map). It also includes admin tools to manage GUMS.
- Used in conjuction with PRIMA to deploy the accounting map.
- Used without PRIMA for those services that must still use a grid-mapfile.
- PRIMA module (on each gatekeeper that needs to contact GUMS): gatekeeper callout module that contacts an authorization server (i.e., GUMS) to retrieve the privilege-to-userid mapping. It is a library that the gatekeeper can be configured to use. For every gatekeeper request, it will contact the GUMS server.
Original author: Alain Roy (for VDT website)
- 10 Mar 2005
- 01 Aug 2007
- 30 Oct 2007