1. Implementing Finer Grained Authorization in the Open Science Grid Gabriele Carcassi, Ian Fisk, Gabriele, Garzoglio, Markus Lorch, Timur Perelmutov, Abhishek Singh Rana, Alan Sill, John Weigand, Frank Würthwein

2. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 2 History of the Project The 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

3. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 3 Goals of the Project When 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.

4. 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.

5. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 5 Architecture Chosen We 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

6. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 6 Components We 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.

7. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 7 Processing Authorization Client system voms-proxy-init Job Submission VOMS Server Attribute Repository Globus Gatekeeper Callout PRIMA Module Job Manager GUMS Identity Mapping Service (manages mapping on resources, including dynamic allocation) VOMS-proxy-init Request with Role Retrieves VO membership attributes Standard Submission with extended proxy HTTPS/SOAP Request SAML query May user bob with VO=USCMS Role=admin access the resource HTTPS/SOAP Response SAML Statement Permit with Obligation Username=cmsadmin VO Synchronization

8. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 8 Storage Authorization dCache Gateway gPlasma Architecture PRIMA Module GUMS Identity Mapping Service (manages mapping on resources, including dynamic allocation) HTTPS/SOAP Request SAML query May user bob with VO=USCMS Role=admin access the resource HTTPS/SOAP Response SAML Statement Permit with Obligation UID=admin GID= admin Homepath=/tmp Storage Authorization Service (Augments Authorization Response with Storage Specific Components)

9. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 9 Deployment Both 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

10. 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 spring Privilege 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 growing ➨ Starting to think about network & data transfer authz.

11. Frank Wuerthwein U.C. San Diego CHEP Mumbia February 13-17 11 Future Plans The 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