Implementing Finer Grained

Authorization in the

Open Science GridGabriele Carcassi, Ian Fisk, Gabriele, Garzoglio, Markus Lorch, Timur Perelmutov,

Abhishek Singh Rana, Alan Sill, John Weigand, Frank Würthwein

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 2

History of the ProjectThe Open Science Grid (OSG) effort in fine grained authorization is called the Privilege Project. Privilege has been a successful collaboration

between US-CMS and US-ATLAS, Universities and National Labs, and Grid Projects and Experiments

•Two national Labs and three Universities

The project began in the spring of 2004 At the time authentication was well established

•Reasonable infrastructure of X509 certificates for communicating identity

• Policy chain to establish and register identities Authorization was not as well established

•Defining what a user is allowed to do once achieving access

•Distinguishing between different kinds of users and activities

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 3

Goals of the ProjectWhen Privilege was first established, the US Grid infrastructure used group accounts, where entire VOs were mapped. Did not meet the security requirements of many of the

sites, because it did not allow sites to easily distinguish the activities of users.

Goal was to enable finer grained authorization on OSG sites Create multi-user environment in which traditional UID

based security audits are possible if desired by site.

•“dynamic”, static, or group accounts according to site security policy.

Move from host based to site based authz

•Authz = VO-allowed & !site-vetoed Distinguish user activities based on proxy cert with

attributes attached.

•Utilize capabilities of EDG Developed Virtual Organization Management System (VOMS) to

•Make authorization decisions based on attribute information• One human can have many different roles across multiple VOs, or within

one VO.

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 4

Envisioned Use Cases Enable support for priority in batch systems based on

VO activities.

•One person may submit as either themselves, or as cms mc production, and receive different priority in batch system accordingly.

•One user who maintains a service (e.g. cms soft install) may get redirected to special batch slots for service maintenance.

Support write-authorization for sub-groups or individuals of VOs in storage systems, or application areas.

•One person installs cms application software on all OSG sites that all others have only read but not write access to.

Enable quotas (disk and/or CPU) for individuals or sub-groups based on published VO policy.

Allow data transfer requests from all users, and prioritize them based on role of the user.

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 5

Architecture ChosenWe examined scalable storage authorization technologies trying to achieve more advanced ACL functionality In the end we chose to use UNIX permissions for

reliability and scalability reasons.

At large sites UNIX UID domains tend to span multiple clusters and services. Even small sites have multiple grid services CE and SE are often independent systems

Important that the mapping returned by the authorization module is consistent across all the services in a UID domain

We have chosen an architecture were there is a central source for authorization and mapping information. A secure communication protocol was chosen for the

connections between the grid services and the authorization system

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 6

ComponentsWe rely on VOMS (Virtual Organization Management System) Developed by EDG VO membership and attribute repository

VOMRS: (registration system) Developed at FNAL Efficient way to manage group membership and group

assignments

GUMS (Grid User Management System) Developed at BNL Service that maps roles and groups assignments to unix

IDs responds to authorization requests

PRIMA Module: Developed at Virginia Tech Implements Security Assertion Language (SAML) callout

from globus gatekeeper to GUMS. Returns Obligation

gPLAZMA Architecture: Developed at UCSD Interfaces authorization call-outs to Storage Element

within dCache• See separate talk for details.

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 7

Processing Authorization

Client systemvoms-proxy-initJob Submission

VOMSServer

AttributeRepository

Globus

Gatekeeper Gatekeeper

Callout PRIMAModule

Job Manager

GUMS Identity Mapping Service

(manages mapping on resources, including dynamic

allocation)

VOMS-proxy-init Request with Role

Retrieves VOmembershipattributes

Standard Submission

with extended proxy

HTTPS/SOAP RequestSAML query

May user bob with VO=USCMSRole=admin

access the resource

HTTPS/SOAP ResponseSAML Statement

Permit with ObligationUsername=cmsadmin

VOSynchronization

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 8

Storage Authorization dCache

Gateway

gPlasma

Architecture

PRIMAModule

GUMS Identity Mapping Service

(manages mapping on resources, including dynamic

allocation)

HTTPS/SOAP RequestSAML query

May user bob with VO=USCMSRole=admin

access the resource

HTTPS/SOAP ResponseSAML Statement

Permit with ObligationUID=admin GID= admin

Homepath=/tmp

Storage Authorization

Service

(Augments Authorization Response with

Storage Specific Components)

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 9

DeploymentBoth Tier-1 and most Tier-2 centers for OSG from LHC experiments have deployed the Privilege Infrastructure Several different policy implementations at University

and Lab clusters The GUMS configuration file that implements roles and

groups is written in XML.Many OSG sites continue to use static grid-mapfiles Both are supported in OSG

Several OSG VO’s have defined roles for sites to implement admin for software installation, data management and

transfer roles for writing to protected storage, production for priority jobs, and a pool for normal users.

So far even on large sites with multiple grid services like FNAL, the central GUMS server for mapping has not been a bottleneck. The FNAL server has had over 60k authentications in a

day

•Scaling is an issue to watch as the activity increases

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 10

Recent Development Activities

Privilege recently developed a callout for the Web Service implementation of Globus Toolkit 4.0 Implementation in Java similar to the structure used

in the gPLAZMA storage callout. This will be deployed on the spring release of OSG

(0.4.1) Increased performance of the web service

implementation of GRAM will require a careful validation of the performance of the existing components

•Activity for this springPrivilege also released a 64 bit compilation of the C callout used in the pre-web service implementation of GRAM Increasing numbers of 64 bit gatekeepers

Wide deployment of dCache Storage Element callout should occur this spring OSG has 9 dCache based SEs and growingStarting to think about network & data transfer authz.

Frank Wuerthwein U.C. San Diego

CHEP Mumbia February 13-17 11

Future PlansThe deployment of finer grained authorization will continue to spread over OSG

GT4 Web Service deployment in the spring Storage Element deployment as well Scale testing will continue.

Made progress on authentication & authorization but are lacking tools for policy communication.

Not possible for remote submitter to determine what roles and groups are supported at a site, if any.

Depend on VO web page for sites to learn what policies are desired.

Need improved policy communication in both direction, especially as we deploy authz for SE more widely.

The security assertion protocol (SAML) will have a release 2.0 during the year.

Privilege currently uses an extended release of version 1