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