TeraGrid VO Support and Plans for AAA Testbed

Dane Skow, Deputy Director TeraGridUniversity of Chicago / Argonne National

LaboratoryInternet2 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