TeraGrid Identity Federation Testbed Update I2MM April 25, 2007 VonWelch NCSA/U. of Illinois National Center for Supercomputing Applications
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
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
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
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
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
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
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
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
Questions? vwelch@ncsa.uiuc.edu National Center for Supercomputing Applications