SC06

1
Scaling TeraGrid AccessA Roadmap (Testbed) for
Federated Identity Management for a Large
Cyberinfrastructure

• Von Welch
• NCSA
• Manager, Security Research and Development

2
Acknowledgments

• This represents thinking by myself and a number
  of others Ian Foster, Tom Scavo, Frank
  Siebenlist, Charlie Catlett, Jill Gemmill, Dane
  Skow
• Whitepaper
• http//gridshib.globus.org/tg-paper.html
• 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
  

3
So what the heck am I talking about?

• Federated Identity Management

4
Identity Management

• Keeping track of people
• Who they are
• What they are
• How they authenticate
• E.g. their password, certificate name, public key
• Its the process of managing a user database
• E.g. /etc/password, Kerberos KDC
• For large sites, an actual database

5
Ok, whats Federated Identity Management?

• Lets start with non-federated identity
  management
• This is what we do today
• Each site has their own Identity management
  system
• I.e. I have a separate account (username,
  password, etc.) at NCSA, SDSC, PSC, TACC
• So I have a separate identity at each site and
  they have no ties (federation) with each other

6
Federated Identity Management

• Instead of replicating a user in each identity
  management system, allow systems to leverage each
  other
• E.g. I already have a username and password at
  the University of Illinois, allow me to use that
  to authenticate to NCSA, SDSC, PSC

7
Why do we care?

• (About Federated Identity Management)
• Having to manage every user is hard work for a
  site
• Enrollment Password or key distributed
• Maintenance Password or key reset when
  forgotten/lost
• Users dont really care for it either
• Need a new username and password for each site
• If TeraGrid is going to scale to O(100k) users it
  cant enroll them all

8
One more thing
9
What you are your Attributes

• Up to this point weve talked about who you are
• And how you authenticate
• Equally important is what you are
• I.e. your attributes
• E.g. Im a NCSA staff person, GridShib project
  leader, TeraGrid staff person, Globus
  security guy
• Others are more interesting with attributes such
  as nanoHUB user, ESG PI, BioPortal Admin,
  LEAD user, etc.

10
Attribute-based Authorization

• What Im allowed to do is often based on what I
  am
• Today this is often implicit and bundled with
  authentication
• E.g. I have an account at PSC because Im a
  TeraGrid staff person
• What a resource makes an authorization decision
  based on what I am instead of who, we call this
  attribute-based authorization
• When this happens the resource may already know
  me or may never have heard of me

11
Why do we care?

• (About Attribute-based Authorization)
• It separates concerns appropriately
• E.g. TeraGrid wants to serve the nanoHUB
  community
• But, TeraGrid doesnt know who the nanoHub
  community is, nanoHUB does

12
Why do we care? (cont)

• Old Model nanoHub gives TeraGrid a list of all
  its users, TeraGrid adds each to their user
  database
• And creates a password for them
• And then on-going maintenance as users come and
  go and forget passwords
• Once again, this is a large burden on TeraGrid
  identity management infrastructure

13
Science Gateways

• Science Gateways represent one form of
  attribute-based authorization today
• Science Gateway represents a user group
• Users access TeraGrid through the Science Gateway
• TeraGrid gives access to the group as a whole
• But has short-coming in that user identity is
  lost to TeraGrid

14
A vision for the TeraGrid Federated Identity

• Plan for a world where users can be authenticated
  via their home campus identity management system
• Outsource authentication and avoid identity
  management burden
• Allow communities to assert user attributes
• 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

15
The Vision
Attributes

nanoHUB
NVO
LEAD
Communities
Identity
Campuses
16
Cracking the Chicken and Egg Problem

• Chicken Federated Identity-enabled Resources
• Egg Federated Identity-enabled Users
• With TeraGrid as the Chicken, try to attract
  significant users

17
Must keep this tied to users

• Has potential to suffer from copper plumbing
  syndrome - better infrastructure without obvious
  user benefit
• Identify target communities to participate in
  testbed
• Need right combination of Shibboleth deployment
  and TeraGrid interest
• (Yes, come talk to me, or Dane or Charlie if you
  are interested.)

18
Testbed Use Cases

1. Individual New User
2. Individual Existing User Access
3. Shibboleth authentication to Gateway
4. Gateway attribute authorization to RP Use Case
5. OSG/VOMS access
6. Educational Access
7. Incident Response

19
Testbed
20
Challenges

• Auditing/logging
• For incident response
• Tracking communities
• Account management
• Community Accounts
• Dynamic Workspaces
• Policy and Configuration
• Creation, distribution, management
• Balance with site autonomy

21
Testbed Timeline

• Complete testbed definition by end of 2006
• Start testbed deployment January 1, 2007
• Ok, maybe January 2nd, 2007
• Expect three to six months of evaluation
• Then generate plan for production deployment
• Seeking participation from admins, users,
  communities, resources

22
The Technologies

• (Warning Slides may contain acronyms typical of
  the computer profession. Those with allergies
  advised to advert their eyes.)

23
Prior Work

• Numerous others have tread this way before us. To
  name a few
• Cross-realm authentication
• SSH (RSA keys)
• Kerberos
• RADIUS
• Attribute-based authorization
• DCE
• AFS
• One could make arguments to use these.
• But Im going to side-step this.

24
Testbed Software Components

• Enhanced CTSSv3 stack
• Grid authentication (GSI/PKI/X.509 certificates)
• Existing GT component extensions to enable
  attribute-based authorization (GridShib, Virtual
  Workspace for VOMS)
• Installed on TeraGrid resources - alternate ports
  or head nodes
• VOMS test server
• Shibboleth and related software
• myVocs, GridShib
• Leverage InQueue/TestShib, InCommon, UTexas
  Federation
• OpenIdp

25
Grid Authentication

• Globus Toolkit provides authentication services
  via X.509 credentials
• When requesting a service, the user presents an
  X.509 certificate
• RFC 3820 proxy certificate or standard end entity
  certificate
• GridShib leverages the existing authentication
  mechanisms in GT

26
Grid Authorization

• Today, Globus Toolkit provides identity-based
  authorization mechanisms
• Access control lists (called grid-mapfiles) map
  DNs to local identity (e.g., Unix logins)
• Community Authorization Service (CAS)
• Some attribute-based authorization has appeared
  and is proving useful
• E.g. VOMS, caBIG
• Extensions to GT exist from GridShib, Virtual
  Workspace project

27
VOMS

• Attribute system developed by the EU Data Grid
• Uses X.509 attribute certificates (RFC 3281)
• In use by EGEE, OSG

28
Shibboleth

• System developed by Internet2 to allow for
  federated identity management
• Allows for inter-organization access to web
  resources
• Not an identity management system
• Exposes campus identity and attributes in
  standard format
• Based on SAML as defined by OASIS
• Policies for attribute release and transient
  handles to allow privacy

29
Why Shibboleth?

• A large (and growing) installed base on campuses
  around the world
• Professional development and support team at
  Inetnet2
• Additional tools from GridShib, UAB, MAMS
  (Australia), SWITCH, UK
• Some commercial support now as well
• A standards-based, open source implementation
• A standard attribute vocabulary (eduPerson)

30
GridShib

• Provides for interoperability between Shibboleth
  and Grids (Globus Toolkit 4.0)
• GridShib for Globus Toolkit
• A plugin for GT 4.0
• GridShib for Shibboleth
• A plugin for Shibboleth 1.3 IdP
• GridShib SAML Tools
• Tools for adding SAML to Grid credentials
• GridShib CA
• Converting Shibboleth authentication to Grid
  credentials

31
myVocs

• myVocs developed _at_ UAB
• Gemmill and Robinson
• NMI funded
• http//www.myvocs.org
• myVocs allows for VOs based on Shibboleth
  identities
• Users register via Shibboleth and can be added to
  myVocs-maintained groups
• myVocs acts as a Shibboleth proxy to add group
  information to users normal Shibboleth
  information

32
myVocs-GridShib integration

• GridShib authorizes use of Grid Services based on
  Shibboleth identities
• Integration allows for the creation and
  management of Grid VOs based on Shibboleth
• Demoed at I2 in April (and can do so anytime for
  interest parties)

33
OpenIdp

• A Shibboleth identity provider for those who
  dont have one at their campus yet
• Also from UAB
• www.openidp.org
• Email-based registration
• Helps to crack the egg
• Commercial equivalent protectnetwork.com

34
Thank you

• For more information
• Von Welch
• vwelch_at_ncsa.uiuc.edu
• GridShib
• http//gridshib.globus.org
• The white paper -
• http//gridshib.globus.org/tg-paper.html
• Questions?