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

2. TeraGrid Overview Nine site federation of resource providers
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
Allow user to do Grid-based SSH SSO with no Grid client installation
Just vanilla Java
Using TeraGrid username and password
This is working:
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
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