1 / 17

TeraGrid VO Support and Plans for AAA Testbed

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

sybil
Download Presentation

TeraGrid VO Support and Plans for AAA Testbed

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ?

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

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

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

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

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

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

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

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

  13. Testbed

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

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

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

More Related