Tera Grid VO Support and Plans for AAA

Tera. Grid VO Support and Plans for AAA Testbed Dane Skow, Deputy Director Tera. Grid University of Chicago / Argonne National Laboratory Internet 2 Member Meeting December 6, 2006

What is a VO to Tera. Grid ? • 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 Tera. Grid has ~1000 of these projects (and ~4000 users) • Science Gateways – A portal which provides tools useful to a community of users – Today Tera. Grid 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” • Tera. Grid 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 • Tera. Grid 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. • Tera. Grid 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 • Tera. Grid 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 Mac. OS 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 Tera. Grid 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 Tera. Grid Resource Provider sites, OSG, Internet 2, Globus • http: //www-fp. mcs. anl. gov/tgmeeting/AAA-Agenda. htm • Whitepaper (Von Welch, Ian Foster, Tom Scavo, Frank Siebenlist, Charlie Catlett) 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 CTSSv 3 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 – my. Vocs, Grid. Shib – Leverage In. Queue/Test. Shib, 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