TeraGrid VO Support and Plans for AAA Testbed Dane Skow, Deputy Director TeraGrid University of Chicago / Argonne National Laboratory Internet2 Member Meeting December 6, 2006

What is a VO to TeraGrid ? A group of users and their infrastructure to manage their policies PI led Projects –Most commonly a faculty PI and her team of students –Today TeraGrid has ~1000 of these projects (and ~4000 users) Science Gateways –A portal which provides tools useful to a community of users –Today TeraGrid has ~25 of these gateways (serving communities of ~20,000+ users total)

What is Virtual about a VO ? (Virtual) Organization has a set of members, a budget they administer, a set of policies, … VOs don’t necessarily have –Physical infrastructure or permanent presence –Electronic infrastructure or permanent presence –Need to do business as a (legal) entity

Project VOs Characteristics –Multiple people sharing work within context of single project –Multiple roles and delegated authorities –Natural to leverage infrastructure of the project “home” TeraGrid Support –Membership tracked in TGCDB with PI control –Project based accounting –Policies set using local system methods (uid based) Questions –How do Project VOs manage policy in an easy way ?

Science Gateway VOs Characteristics –Bonding element is a research interest and/or set of tools –Frequently has access to multiple resources and wants to matchmake –Acts as a broker and/or service provider –Established “brand” above the (grid) infrastructure TeraGrid Support –Support for community accounts (to multiplex request) –Audit record for individual request “cost” (soon) –Community based accounting –Common Authentication infrastructure (post AAA) Questions –What level of individual action/privilege is needed/desired ?

Personal VOs Characteristics –Tend to be full delegation of identification secret Parallel to a tradesperson key to a house Policy enforced out of band –One persistent authority controlling the token –These VOS will always exist. Question is whether or not they go underground. TeraGrid Support –Caveat Emptor and Benign Neglect Questions: –Do shared workspaces with different identity tokens increase of decrease risk ? For whom ?

Team VOs Characteristics –Multiple people working together over a period of time –Roles change within context of different projects TeraGrid Support –None today Questions –What is the urgency of the need for such Vos ?

Issues with Authentication Status Quo IDs sometimes contain sensitive information (e.g. SSN) ID sources do not typically have direct, ongoing relationship with users Many sources of authentication mean confusion, error and insecurity for all parties Protection of online secrets is difficult and point of attack Scaling beyond ~100 sources of identity call for index and/or hierarchy –100+ in MacOS X default, etc –Currently 90+ CAs in IGTF PMA set –~1500 Institutions in EDUCAUSE

Authorization Status Quo Currently solely ID based – A user has only one mapping in the system no capability for roles Single group membership Need prior knowledge of group membership –Maintenance /synchronization problem No differentiation between services for access levels –Allocated users –Authenticated users –TG Community users –Partner/Campus users –Public Scaling –Workload scales by ID not by group –Adds new sources of authority to manage

Account Management Status Quo Single Account/authorization doesn’t map to rich set of services Persistent Execution Environments –Pre-provisioning individual environments (accounts) has large overhead and vulnerabilities –Shared environments –Environment configuration for groups must be independently duplicated Traceable actions –Need to preserve connection from actions (and costs) to individual initiating the action for troubleshooting

Workshop Workshop on TeraGrid Authentication, Authorization, and Account Management - August 30-31, 2006, Argonne National Laboratory –Organizers: Von Welch, Tony Rimovsky, Jim Marsteller, Carolyn Peters, Dane Skow Attendees: 42 persons, representatives from all TeraGrid Resource Provider sites, OSG, Internet2, Globus Whitepaper ( Von Welch, Ian Foster, Tom Scavo, Frank Siebenlist, Charlie Catlett) http//gridshib.globus.org/tg-paper.html http//gridshib.globus.org/tg-paper.html

The Proposal Plan for a world where users can be authenticated via their home campus identity management system Enable attribute-based authorization of users by RP site –Allow for user authentication with authorization by community Prototype system in testbed, with involvement of interested parties to work out issues All usage still billed to an allocation –Community or individual

Testbed

Testbed Components Enhanced CTSSv3 stack –Existing GT component extensions to enable attribute-based authorization Identify testbed resources –UChicago/ANL, NCSA Mercury, ORNL –Use OSG/TG VOMS test server Handful of user communities –Science Gateway, Educational, OSG, others TBD. Use of Shibboleth and related software –myVocs, GridShib –Leverage InQueue/TestShib, UT Fed

Testbed Timeline Until year end 2006 –Refine Testbed plans and participants Jan - Mar 2007 –Deploy first instances on Testbed and first use cases Mar - May 2007 –Refine use cases and double instances June 2007 –Assess results and plan deployment July - Sept 2007 –Retool, package, document,.. Sept - Dec 2007 –Deploy and pre-production test Jan 2007 –Production deployment

Technical Plan 1.Enable logging of attributes through the system –Improves traceability and prepares for attribute handling 2.Enable group membership decisions based on attributes –Provides for community based authorization 3.Enable attribute based authorization/provisioning decisions –Enables user mapping to different environments –Enables specialized provisioning by attribute set