Scaling%20TeraGrid%20Access:%20A%20Roadmap%20(Testbed)%20for%20Federated%20Identity%20Management%20for%20a%20Large%20Cyberinfrastructure - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Scaling%20TeraGrid%20Access:%20A%20Roadmap%20(Testbed)%20for%20Federated%20Identity%20Management%20for%20a%20Large%20Cyberinfrastructure

Description:

Scaling TeraGrid Access: A Roadmap (Testbed) for Federated Identity Management for a Large Cyberinfrastructure Von Welch NCSA Manager, Security Research and Development – PowerPoint PPT presentation

Number of Views:64
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Scaling%20TeraGrid%20Access:%20A%20Roadmap%20(Testbed)%20for%20Federated%20Identity%20Management%20for%20a%20Large%20Cyberinfrastructure


1
Scaling TeraGrid Access A 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?
About PowerShow.com