# Presentation: 420477

## SVOPME – A Scalable Virtual Organization Privileges Management EnvironmentPhase I Project ReviewandPhase II Project Kickoff

**Oct 28, 2008 @ FNAL, Batavia, IL**
**Funded by DOE OASCR SBIR Grant #DE-FG02-07ER84733**

**Nanbor Wang**
**Tech-X Corporation**
**nanbor@txcorp.com**

**Gabriele Garzoglio**
**Fermi National Accelerator Laboratory**
**garzoglio@fnal.gov**

## Outlines

**Project overview**
- What SVOPME tries to address
**Phase I results**
- Design and capability of the prototype tools
**Phase II outlook and planning**
- Our current plan
- We need your feedback and wishes
- Verify our focus areas and prioritize tasks
- Particular features that’s needed

**Remember that we have tried one possible solution that works**
**We are ready to adopt a better approach or address other more pressing issues related to various VO policies**

## What are VO Privileges?

- VOs use resources
- VOs wish to define usage policies for various resources for different users within the VOs
- Production team members submit jobs with higher priority
- Software team members can write to disk area for software installations
- VOs grant users privileges for using different resources to enforce the usage policies
- However, VOs do not manage/configure grid sites

- Grid sites provide resources
- Grid sites may want to provide different services to different VOs
- As an example, some site might decide to offer DOE-sponsored VOs higher priority to local resources
- Grid sites help VOs to enforce their useage policies by managing user privileges
- Grid sites don’t define VOs’ usage policies

**Challenge: Enforcing VO privileges on multiple grid sites (ah hoc solution: verbal communication)**

## Motivations of SVOPME

**With the growth in Grid usage, both the numbers of VOs and grid-sites increase**
**Serious scalability problems in propagating VO privilege policies**
**SVOPME: **
- Provide the tools and infrastructure to help automate enforcing VO privilege policies
- Reuse proven administrative solutions – we adopt common system configuration patterns currently in use in major grid sites

- ...

- CMS

- USATLAS

- CompBioGrid

- STAR

- LIGO

- FermiGrid

- SDSS

- iVDGL

- FERMIGRID

- CMS-T2

- LIGO-MIT

- GPFARM

- UCSDT2

- UC-ATLAS

- ASGC

- STAR-BNL

**Address scalability**

## Modern User Privilege Management 

**Moving away from the use of gridmap files to VOMS/GUMS role-based privilege mangement**
- Eliminate the need for multiple user certificates
**Similar trend in EGEE (LCAS & LCMAPS and VOMS)**
**Job priority management for both SE and CE**

## Phase I Objective and Tasks

**Objective: validate the approach**
**Design suitable XML schemas for describing policies**
- We have adopted XACML
- Allow aggregation of policies
- Also used by AuthZ Interoperability project
**Determine the information needed in VOs and site policies**
- Come up with a list of resources and policies

**Implement a prototype environment for synthesizing administrative directives and verifying VO policies**

- VO PrivilegePolicies

- Site PrivilegePolicies

- Site Configurations

- ConfigurationRecommendations

- Propagate

- Verify

- Synthesize

- SVOPMEConcept
- Diagram

## Task 2: Survey Resources and Policies Needed

**Resources**
- OS protection (account types: group or pool)
- Batch system
- File system
- External storage (SRM/dCache)
- Network access (inbound/outbound)
- Edge services
**Site policies**
- Timed availability (execution time slots for certain VO users)

**VO policies**
- Relative priority in batch system
- Directory access permissions
- Consecutive execution period
- Suspension/resumption of jobs
- Repeat execution (More like allowing restart or not in batch system)
- User file privacy
- Two roles to share the same GID
**VO or site policies**
- Disk quota
- File retention period
- Account type
- Network (inbound/outbound) access control

- We have implemented the highlighted policies in the Phase I prototype tools

**Notes:**
Looks like all are we should only care about VO policies.  All these policies seem to be applicable to VOs.  We should review this for Phase II workplan

## Task 3: SVOPME Prototype Architecture

**Task 3: SVOPME Prototype Architecture**

## VO Tools – Used by VO-Admin

**VO Tools – Used by VO-Admin**

**Comprises of 2 Tools**
- VOMS Client
- VO Policy Editor
**VOMS Client**
- Obtains info about all the Group/Role and the no of users from VOMS server
- This information is passed to VO Policy Editor (next slide) to avoid operator’s errors

## Domain-Specific VO Policy Editor

**XACML is a generic XML-based language for specifying access control policies**
- Not very human readable
- Suitable for machine processing
**The VO Policy Editor therefore allows VO administrators to edit a pre-defined set of VO policies in simple readable forms**
- For example: Account Mapping Policy
- Group _____ should run with _pool/group_ account
**The Editor, however, stores the policies in XACML format to enable automation**
- Privilege policies
- Test queries for verifying correct implementation and enforcement of policies on Grid sites
**Support for new policy types can be added as “Policy Templates”  plug-in’s**
**We also plan to develop a command-line policy editing tools to convert between a text based policy specification and XACML documents **

## Phase I VO Policy Editor Screen Shot 1Select Policy Type to Add

- Select Policy

- VO Policy Description

## Phase I VO Policy Editor Screen Shot 2Edit Policy Attributes

- VOMS Client assists in setting attributes

## Phase I VO Policy Editor Screen Shot 3Allow XACML view

## Grid Tools

**Grid Tools**

**Comprises of 3 Tools**
- Grid Probe
- VO/Grid Policies Advisor
- VO/Grid Policies Comparer
**Grid Probe**
- Probe the grid site local configurations
- For Phase-I we probe the settings of GUMS and Condor system
- GUMS provides info on account mapping from VO user/role to local UID
- Condor provides priorities of accounts
- Generates the equivalent Grid side policies (in XACML) from the probe results

## VO/Grid Policies Advisor

**VO/Grid Policies Advisor**

- Verify that the Grid site configurations support the VO policies by running the verification queries generated by VO Policy Editor for each VO policy
- Provide advises for the Grid site administrator on what amendments needs to be done on the Grid; such that the Grid site complies with the VO policies
- Example output:
- VO requested 3 accounts for VISITORS role via VO policies
- Site-policies derived from GUMS do not match

- 	[java] VO/Grid Grid Accounts Policy Advices
- 	[java] ------------------------------------
- 	[java] No matching Grid Accounts Policy was found for /TECHX/VISITORS on the Grid site. Create a mapping in GUMS config such that /TECHX/VISITORS be mapped to at least 3 account(s)
- 	[java] TECHX/Role=VO-Admin mapped to 1 account(s) (techxVOadmin) on the Grid site, is not suffient enough. Needs to be mapped to atleast 3 accounts.

## VO/Grid Policies Comparer

**VO/Grid Policies Comparer**

- Verify that the Grid site configurations support the VO policies by running the verification queries generated by VO Policy Editor for each VO policy
- Produces a report on which VO policies are honored by the Grid site and which are not
- Example output:

- 	[java] VO/Grid Grid Accounts Policy Comparison
- 	[java] ---------------------------------------
- 	[java] /TECHX/Role=User is mapped to 1 account(s) on the Grid site. Passed!
- 	[java] No Account Mapping Policies for /TECHX/VISITORS were found on the Grid site.
- 	[java] /TECHX/Role=Software-Admin is mapped to 1 account(s) on the Grid site. Passed!
- 	[java] /TECHX/Role=VO-Admin does not have suffient accounts on Grid Site. Failed! (Needs to be mapped to atleast 3 accounts.)
- 	[java] /TECHX is mapped to 1 account(s) on the Grid site. Passed!

## Phase II Workplan

**Objective 1: Usability**
- Support a more comprehensive set of VO policies
- Add support for remaining policies collected in Phase I
- Not sure if we want to incorporate site-specified policies or not
- Collaborate with VOs and key OSG grid sites to gather VO policies needed and how site could support these policies
- Comman-line scripting tools
- Derive a set of policies sentences
- Embed policy sentence in generated XACML

## Phase II Tasks (cont)

**Completing Features and Hardening of prototype tools**
- Overall Feature enhancements
- Change to use PolicySets for VOs and grid sites
- Allows us to aggregate policies
- Supports the semantics of a whole VO or site
- Modularize components
- Support new policies
- Support new grid environments and configurations
- VO Policy Editor
- Merge VOMS Client with the Editor
- Allow opening/editing/saving of existing PolicySet
- Support browsing of PolicySet
- Support consistency check of overall VO PolicySet
- What to do when there’s a mismatch between VO and PolicySet
- Grid Probe
- Support probing of more resources configurations
- VO/Grid Policy Comparer/Advisor
- Currently, we only check for supported policies but not redundant site policies
- Address security concerns (of site configurations and policy inconsistency, etc.)

## Phase II Workplan (Cont.)

**Objective 2: Flexibility and Robustness**
- Modularization of Aspects such as Grid configurations and tool stacks
- Migration toward a common Grid XACML profile (Authorization Interoperability Profile)
- Identify and implement more privilege policies
- Site-specific policies
- Service contracts between sites and VOs?

## Phase II Workplan (cont.)

**Objective 3: Demo the Effectiveness**
- Integrate with OSG distribution
- Develop recommendation for running/using SVOPME tools
- Deployment, documentation and customer service

## We Need Your Opinions

**Immediate features we should support**
**General approach**
- Particular policies we are not covering?
- Different strategies to verify support of VO privileges?
**VO tools**
- Features in GUI editor?
- Scripting capability?
**Grid site tools**
- New configurations to probe?
- How can we incorporate new configuration patterns that site administrators often use?