The PRIMA Project

Vikram Andem (vandem at fnal dot gov)

Introduction:

PRIMA ( PRIvilege Management and Authorization) is a system which provides enhanced grid security.

PRIMA is both a comprehensive grid security model and system. The model describes how privileges are created, distributed, shared, selected, and bound to resource requests. The model also describes how the privileges relate to policies defined by resource managers and how the intent of the security system can be enforced.

In PRIMA, a privilege is a platform independent, self contained representation of a fine-grained right. PRIMA achieves platform independence of privileges by externalizing fine-grained access rights to resource objects from the resource's internal representation.

For example, a privilege for a file access right is abstracted from the way file access rights are stored in the file meta information by the operating system. The PRIMA representation uses a standard XML-based language to encode the externalized form of the privilege. A privilege is self-contained in that its meaning is fully determined by the information contained in the privilege.

PRIMA provides for the grid layer management and delegation of privileges on a userto -user and administrator-to-user basis. The holder of privileges can selectively provide individual privileges to grid resources when requesting access. This enables least privilege access to resources and ensures that the user has fine-grained control over resource usage of requested services. Resource administrators create and manage polices for their resources via grid layer PRIMA mechanisms. The user-supplied privileges are combined with the administrator-provided policies to render a dynamic authorization decision.

 

 

OSG Deployment

In OSG a VO will have to provide VO membership information e.g. via VOMS

The Privilege Project functionality developed for OSG-0 enables primarily two improved ways to manage the assignment of local user accounts:

  1. It allows for the centralized management of the Grid-identity (user's certificate distinguished name) to local user Id (operating system user name) mapping. This alleviates the issues associated with the creation of static grid-mapfiles and their distribution to all grid resources. This functionality is referred to in this document as "centralized identity mapping".
  2. It provides mechanisms for user's to select a specific VO-membership and VO-role combination out of the set of VOs and roles that the user's are authorized to use. The system can map grid identities to local user Ids based on the selected VO and role attributes. This functionality is referred to in this document as "role-based identity mapping"

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.

The Authorization architecture on a compute element 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) are already present and required for Grid03 VOs

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.

 

Centralized Identity Mapping Functionality and Components

Two 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

Pre- Web services:

-        Globus Gatekeeper with the Grid-map callout introduced in GT3.2 or later and compiled against the OpenSSL library version 0.9.7. This version of the Globus Gatekeeper is distributed with VDT 1.3

-        Ability to open an outgoing HTTPS connection to the appropriate GUMS Server

Web services:

-        Globus Web service gatekeeper (globus-ws) introduced in GT4. This version of Globus Gatekeepr is distributed with VDT 1.3.9

-        The security descriptor page explains how to set up the security for a service (or a client). For GT4 PRIMA, we'll need to set the AuthZ to use the osg.opensciencegrid.authz.gt4.OSGAuthorization class. We should be able to do this by following the instructions: Something like:

<securityConfig xmlns="http://www.globus.org">
  ...
  <authz value="osg:org.opensciencegrid.authz.gt4.OSGAuthorization"/>
  ...
<securityConfig/>
        

2. GUMS requirements

  • Tomcat web service container (version 5.5)
  • Incomping HTTPS connections to port 8443 allowed
  • MySQL database
  • Synchronization of database with the VOMS servers of all supported VOs

 

Some Important links on PRIMA:

Pre-Web Services:

-        Globus Pre-Web Services Authorization Callouts

-        Configure the PRIMA module Pre-Webservices

-        Notes on building PRIMA from CVS

-        Downloading the VDT

-        PRIMA build status on Univ of Wisc NMI build and test system

-        PRIMA Architecture

-        Figure depicting certificate validation

-        PRIMA C programmers guide (Pre-Webservices)

-        OpenSAML 1.1

-        VDT Documentation

-        Sample prima-authz.conf

-        Sample gsi-authz.conf

-        Prima source code download

-        Prima 64-bit download

Web Services:

-        Configuring Authz Web Services

-        Submitting Jobs to Web Service GRAM

-        Web Services notes

-     Configuring PRIMA WS

-        Privilege Project Snapshot (Source)

-    Web services GRAM Approach

-    GT4 security key concepts

 

GUMS:

-        Gums Home page

 

 

Last update: 04/04/06