SVOPME: Scalable Virtual Organization Privilege Management EnvironmentNanbor Wang1, Balamurali Ananthan1, Gabriele Garzoglio2, Steven Timm2

1Tech-X Corporation, 5621 Arapahoe Ave, Suite A, Boulder, CO 80303 2Fermi National Accelerator Laboratory, P.O. Box 500, Batavia, IL, 60510, USA

This work is partially funded by the Office of Advanced Scientific Computing Research, Office of Science, United States Dept. of Energy under contracts DE-FG02-07ER84733 and DE-AC02-06CH11357, the Fermi National Accelerator Laboratory, and the Tech-X Corporation.

SVOPME as a solution

SVOPME attempts to solve this problem by providing a set of tools to the VO and the Grid administrators. With these tools, the VO administrator can define VO policies, publish and verify them. In turn, the Grid administrators can probe their underlying Grid resources and auto-compile Grid policies.

In addition, SVOPME provides tools for a VO to compare its policies with the Grid site policies and discover compliant sites. Similar tools are available for the Grid administrators to compare site policies with VO policies and generate recommendations on how to alter the Grid configuration to comply with them.

List of currently supported policies

1. Account Type Policy: Run job submitted from FQAN A using Pool (unique) / Group (shared) accounts.

2. Account Mapping Policy: Must have accounts for all users in FQAN-A (may be pool accounts or Group accounts).

3. Relative Priority Policy: Jobs submitted from FQAN A should have higher priority than those from FQAN B.

4. Preemption Policy: Jobs from FQAN A should be allowed to execute for N consecutive hours without preemption.

5. Package Installation Policy: Allow users from FQAN A to install software in $OSG_APP (assuming there is NO space reserved for any VO)

6. Unix Group Sharing Policy: Accounts belonging to FQAN A and FQAN B must share the same unix Group ID

7. File Privacy Policy: Users belonging to FQAN A expect privacy for their files

8. Job Suspension Policy: Do not suspend / resume jobs submitted from FQAN A

9. Disk Quota Policy: Assign disk quota of X GB to accounts mapped from FQAN A

Sample policy advisor output:

Grid Account Mapping Policy Advices /TECH-X/Role=Test is group mapped on the Grid site. Should be pool mapped.

Grid Accounts Policy Advices /TECH-X/Role=User mapped to 5 account(s) on the Grid site, is not suffient enough. Needs to be mapped to atleast 8 accounts./TECH-X/Role=Test mapped to 1 account(s) on the Grid site, is not suffient enough. Needs to be mapped to atleast 8 accounts.

Grid Priority Policy Advices /TECH-X/Role=User has a priority of 1689 and /TECH-X has a priority of 8. To comply with the VO, /TECH-X/Role=User should have a higher priority than /TECH-X Grid JobRuntime Policy AdvicesJobs submitted by user /TECH-X/Role=VO-Admin may not run continously for 00 Hrs 10 Mins and 00 Secs. Failed! Atleast 1 Condor Startd machine is configured with a MaxJobRetirementTime of 00 Hrs 06 Mins and 40 Secs. Checkout gridpolicies/CondorJobRuntime.txt to see what each condor startd machines is configured with.

Grid FQAN Unix Group Account Policy Advices The account mapped to /TECH-X/Role=Test belongs to these [techxVO] group accounts and the account mapped to /TECH-X/Role=Software-Admin belongs to these [vdt] group accounts. To comply with the VO policy, configure the Grid system such that the accounts mapped to the FQANs shares atleast one unix group account

Files Privacy Policy AdvicesThe home directory of /TECH-X does not seem to posses adequate privacy. This FQAN is mapped to 'techx' whose's home dir is '/scr_multipole/techx' and has permissions 'lrwxrwxrwx'. To conform with the VO policy, it is advised that the home directory has read-write-execute permission only for the user and for no one else

Job Suspension Policy Advices The jobs submitted from /TECH-X/Role=User may be suspended. To conform with the VO policy, it is advised to configure all the Condor Startd machines such that the jobs submitted from 'techx001' will not be suspended.

Future outlook:

We are currently soliciting VO’s and sites interested in testing out SVOPME in a production environment. We will continue to enhance and harden SVOPME tools based on the feedback and experiences from these early adopters. We will implement more policies for future extension based on the needs of the VOs that we work with.

We intend to have SVOPME incorporated in the Virtual Data Toolkit (VDT). VDT is considered the de facto standard for Grid middleware. This should allow SVOPME to be available to the whole Grid community to realize a fully automated privilege management environment.

Typical architecture of OSG Grid components and VO components.

SVOPME policy interactions between the VO and the Grid site.

Previously compiled policiesPolicy Description

User issues an id for the policy

User selects FQAN

Assigns attributes for policy

Policy compilation messages

GUI Editor to compile VO XACML policies

Current deployment:

• SVOPME tools are deployed in a realistic, large-scale Grid environment at Fermilab on the FermiGrid Integrated Test Bed (ITB).

• To evaluate the effectiveness of SVOPME, we gathered and defined the VO policies for the DZero and the OSG Engage VOs. This test motivated several enhancements to the Grid tools.

VO PrivilegePolicies

Grid SiteConfiguration

Compliance Report and

Recommendationsfor Configuration

Changes

ED

IT

VERIFY

RETRIEVE

SYNTHESIZE

Rec

onfig

ure

VO Tools

VOMS Client collects information about the list of available Fully Qualified Attribute Names (FQAN) (user groups and roles) and user membership to these FQAN.

VO XACML Policy Editor uses XACML format as the internal representation of privilege policies. This provides a generic mechanism for describing, combining, and reasoning about policies. Using the policy editor, a VO administrator compiles VO policies and their corresponding policy requests. These requests are used internally for comparing with and advising the Grid policies.

VO Requests Archiver bundles the VO policy requests as a compressed archive (tar.gz file) with a time-stamp attached to it. The VO administrator then places this VO policy request bundle in a web server located at the VO. This enables the Grid sites to download the latest VO policy requests for policy-advise purposes.

Policy Comparer Client (Command-line and GUI) enables VO administrators and users to communicate with the Policy Comparer Web Service at a Grid site. The client allows to verify the degree of support of a site for of the VO policies.

Grid Tools

Grid Probes probe the Grid resources and collect information about the Grid sites. This information is organized into individual text files that are used to build the Grid policies.

Grid Policy Builder translates information about site configuration into a set of formally defined privilege policies in XACML format.

Policy Comparer Web Service compares the VO and site policies and reports whether each VO policy is honored by the Grid site.

VO Policy Requests Version Checker compares the current version of the VO policy requests on the Grid site with the latest version of VO policy requests on the VO web server. If needed, it downloads the latest version of VO policy requests.

Policy Advisor provides advice to the site administrator on the site configuration changes that are needed to comply with the VO policies. Typically, the site administrator uses the 'VO policy requests version checker' tool beforehand to obtain the latest version of the VO policy requests.

Related works

SVOPME project is synergistic to many projects on authorization management. For example,

• The GPBox [3] project is a policy management framework for the Grid environment to globally modify the execution priorities at sites for VO jobs. Compared to GPBox, SVOPME project does not attempt to configure site policies directly. Instead, SVOPME produces compliance reports about local configurations that hint on how the configurations could be modified for the site to provide better support for VO’s. We believe that leaving local site administrators in full control of site configuration will give them peace of mind and reduce their resistance toward the eventual adoption of SVOPME.

• The EGEE Argus Authorization Service [2] aims to provide consistent authorization decisions for distributed services over the Grid. It provides software components for defining privilege policies at services. These policies are then used to answer queries about whether a particular action is permissible by certain users. Although the EGEE Authorization Service also aims at providing a set of consistent authorization policies over the Grid, unlike SVOPME, the new Authorization Service does not focus on the VO policies. The two projects will be able to leverage the work done by each other.

• Another effort related to SVOPME is the Authorization Interoperability project [1] which defines an attribute and obligation profile for authorization interoperability across Grids. We will leverage the efforts from this project to integrate SVOPME into OSG and other Grid infrastructure.

References

[1] G .Garzoglio et al. XACML profile and implementation for authorization interoperability between OSG and EGEE 2010 J. Phys.: Conf. Ser. 219 062014 DOI 10.1088/1742-6596/219/6/062014[2] The EGEE Authorization Service https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFrameworkAccessed on Oct 7, 2010[3] Cesini D, Ciaschini V, Dongiovanni D, Ferraro A, Forti A, Ghiselli A, Italiano A, Salomoni, Enabling a priority-based fair share in the EGEE infrastructure 2008 Journal of Physics: Conference Series 119 062023 DOI:10.1088/1742-6596/119/6/062023

Sample policy comparer output:

VO/Grid Account Mapping Policy Comparison/TECH-X is group mapped on the Grid site. Passed! /TECH-X/Role=Software-Admin is group mapped on the Grid site. Passed! /TECH-X/Role=Test is group mapped on the Grid site. Failed!

VO/Grid Grid Accounts Policy Comparison /TECH-X/Role=User does not have sufficient accounts on Grid Site. Failed! /TECH-X is mapped to 1 account(s) on the Grid site. Passed! /TECH-X/Role=Test does not have sufficient accounts on Grid Site. Failed!

VO/Grid Job Runtime Policy Comparison Jobs submitted by /TECH-X/Role=Software-Admin will run continously for 00 Hrs 04 Mins and 00 Secs. Passed! Jobs submitted by /TECH-X/Role=VO-Admin may not run continously for 00 Hrs 10 Mins and 00 Secs. Failed! Jobs submitted by /TECH-X/Role=Test will run continously for 00 Hrs 04 Mins and 00 Secs. Passed!

Files Privacy Policy Comparison The home directory of /TECH-X/Role=Test seem to posses adequate privacy. Passed! Either /TECH-X does not exists in the GUMS configuration in the Grid site (OR) the home directory of the account to which /TECH-X is mapped to does not seem to posses adequate privacy. Failed!

Job Suspension Policy The jobs submitted from /TECH-X will not be suspended. Passed! The jobs submitted from /TECH-X/Role=User may be suspended. Failed! The jobs submitted from /TECH-X/Role=Software-Admin will not be suspended. Passed!

VO/Grid Priority Policy Comparison/TECH-X/Role=User has a priority less than or equal to /TECH-X on the Grid site. Failed! (Should be otherwise) /TECH-X/Role=VO-Admin has a priority greater than /TECH-X/Role=Test on the Grid site. Passed! /TECH-X/Role=Software-Admin has a priority greater than /TECH-X/Role=VO-Admin on the Grid site. Passed!

Problem Description

Modern Grid middleware provides both the mechanisms and tools to enable fine-grained, role-based access control. However, it comes up short in providing a streamlined and consistent distributed user privilege management across Virtual Organizations (VO) and sites. Currently, this lack of automatic policy instantiation/reconciliation is handled manually via verbal discussions between VO administrators and site administrators. Such manual propagation of VO policies is a brittle and time-consuming process. With privilege policies changing more dynamically (a trend that is becoming more common for large VO's and sites with more new VO’s getting onboard), Grid utilization suffers as legitimate users may not be able to access resources which are otherwise perfectly usable.

Key features are missing in the state-of-the-art Grid middleware to enable the effective communication of the desired VO privilege policies to Grid sites. These features call for VO’s to define the privilege policies formally and for Grid site to access these formal definitions and verify their local configurations.

VO Policy Editor

The editor is used to compile VO policies and its corresponding requests in XACML format. To compile a VO policy the administrator will

1. Set a policy ID

2. Select the FQAN(s) (collected from the VOMS server)

3. Assign relevant parameters to the policy

The VO policy and its requests are compiled.

Architecture

Overview

The architecture is designed to address the needs of VOs and Site administrators.

For the VO:1.VO administrator is able to

quickly and intuitively compile a VO policy

2.VO administrator can easily verify which of the Grid sites support the VO policy

3.The system publishes the VO policies so that a Grid site can access them for policy advise purposes.

For the Grid site:

1.The site administrator probes the Grid resources and automatically builds resulting Grid policies.

2.The site administrator uses a policy advisor tool to build a report on how Grid resources should be configured to honor the VO policies

3.The system provides a policy comparer web service that accepts VO policies and returns a report on the compliance of the Grid policies with VO policies to the VO administrator.

How it works

The following are the logical steps involved in comparing the VO and Grid site policies:

• The VO administrator compiles the policies in the VO XACML policy editor. • For every VO policy that is compiled, a corresponding XACML request is produced. • Policies on the Grid site are auto-compiled using the results from the Grid probe. • The VO requests, corresponding to VO policies, are evaluated against the site policies by the Policy Comparer web

service and by the Policy Advisor. Both tools use the Sun XACML Engine.• Using the evaluation result one concludes whether the Grid site honors a VO policy or not.

Policy Comparer

XACML Effective Site Access Policies

Synthesizes

Grid Probe

Storage Elements

Computing Elements

Crawls

Policy Advisor

Apply ChangesSuggested

Changes

Generates

Uses

Refersto

Site Administrator

VO Request Version Checker

Checks TimestampAnd Download

XACML VO Verification Requests

UsesUses

GUMSServer

Grid Site

Crawls

Stores

Generates

Compliance Report for VO

XACML VO Privilege Policies

XACML VO Requests

VO Privilege Policy Editor

VO Adminstrator

VOMSClient

ComparerClient

Request Archiver

VOMSServer

Time-stampedZip Archives

Creates/Edits

Uses

Uses

Reads

CreatesUses

Latest

Invokes

Published Via

VO HTTPServer

VOMS Info

Uses

Generates

SVOPMEGenerated

Reports

Grid site Entities

SVOPME Tools

SVOPMEGeneratedArtifacts

VO Entities

Legends

VO

Policy Builder

Grid Service

Host