TeraGrid VO Support and Plans for AAA Testbed

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

2. 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)

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

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

6. 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 ?

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

8. 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 ?

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

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

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

12. 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 • 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

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

14. Testbed

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

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

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