TeraGrid Identity Federation Testbed Update: Enabling Scalability and Attribute-based Authorization

1. TeraGrid Identity Federation Testbed UpdateI2MMApril 25, 2007 VonWelch NCSA/U. of Illinois National Center for Supercomputing Applications

2. TeraGrid Overview • Nine site federation of resource providers • http://www.teragrid.org/ • Each with own accounts, processes, policies, etc. • There exist both TeraGrid users and local, site-specific users • O(10k) TeraGrid users from wide variety of different sites • Most users not from TeraGrid sites • Almost all from U.S. campuses • TeraGrid users have accounts on some/all sites • Each site has own local users as well • These are centrally managed National Center for Supercomputing Applications

3. Account management • Central process for getting/managing allocation • NSF Allocations process • Central database keeps track of TG user accounts at all sites • no uid or username alignment across sites • Also keeps track of User’s Grid Identities • X.509 DNs • Both TG-issued and from external CAs • Pushes out to all sites • All users have a TG username and password • Exposed via Kerberos 5 domain and MyProxy online-CA • TeraGrid User Portal National Center for Supercomputing Applications

4. TeraGrid Access • Traditional interactive SSH login via Site authn • Grid (PKI) SSO SSH interactive login • Short-lived PKI credentials issues via MyProxy and User’s TG username & password • Hides site-specific identity details from user • Grid Services • Globus job submission, GridFTP, etc. • Science Gateways/Web Portals • Have own user databases • Tied to community accounts and allocations on TG sites • Give constrained, domain-specific interface National Center for Supercomputing Applications

5. Ultimate Id Federation Goals and Testbed • Allow scaling of TeraGrid to O(100k)+ users • Get TeraGrid out of identity management game to allow this • Leverage existing campus identity management • Allowing servicing of existing VO’s • Attribute-based authorization • Allow for incident response • Blocking and/or contacting problematic users • Testbed running first half of 2007 to evaluate how Shibboleth, GridShib and other tools can achieve this • NCSA, Purdue National Center for Supercomputing Applications

6. Testbed Thrusts • Three thrusts… • One: Java-based Grid-enabled SSH and MyProxy client • Build on work from UK NGS • http://www.grid-support.ac.uk/files/gsissh/ • Allow user to do Grid-based SSH SSO with no Grid client installation • Just vanilla Java • Using TeraGrid username and password • This is working: • http://grid.ncsa.uiuc.edu/gsi-sshterm/ National Center for Supercomputing Applications

7. Testbed Thrusts • Two: Shibboleth-based TeraGrid Access • Using GridShib-CA to access existing TeraGrid account • In Shibboleth terms, a Shibboleth SP that issues short-lived Grid credentials • Allows user to connect to TeraGrid using their local campus authentication • Integrated with Java GSI-SSH client to allow for zero-client install SSH access • Currently doing bi-lateral Shibboleth peering • eventually InCommon • Requires ePPN from IdP • Friendly user mode • One time registration of Shibboleth-based X.509 DN • http://gridshib-ca.ncsa.uiuc.edu/ National Center for Supercomputing Applications

8. Testbed Thrusts • Three: Attribute-based authorization from Science Gateways • Allow Science Gateways to push VO attributes to TeraGrid sites • Could be passed from user’s Idp or generated locally • In development. National Center for Supercomputing Applications

9. Testbed Next Steps • Get friendly users kicking the tires • Peer with some more campuses to allow this • Currently U. of Illinois, U. of Chicago, ProtectNetwork, OpenIdp • Try out some incident response dry runs National Center for Supercomputing Applications

10. Questions? • vwelch@ncsa.uiuc.edu National Center for Supercomputing Applications