gridshib-intro-dec051 GridShib An Introduction Tom Scavo NCSA

gridshib-intro-dec052 What is GridShib? GridShib enables secure attribute sharing between Grid virtual organizations and higher-educational institutions The goal of GridShib is to integrate the Globus Toolkit® with Shibboleth® GridShib adds attribute-based authorization to Globus Toolkit

gridshib-intro-dec053 Tale of Two Technologies Grid Client Globus Toolkit Shibboleth X.509 SAML Grid Security Infrastructure Shibboleth Federation Bridging Grid/X.509 with Shib/SAML

gridshib-intro-dec054 Motivation Large scientific projects have spawned Virtual Organizations (VOs) The cyberinfrastructure and software systems to support VOs are called grids Globus Toolkit is the de facto standard software solution for grids Grid Security Infrastructure provides basic security services…but does it scale?

gridshib-intro-dec055 Why Shibboleth? What does Shibboleth bring to the table? –A large (and growing) installed base –A standards-based, open source implementation –A standard attribute vocabulary (eduPerson) A well-developed, federated identity management infrastructure has sprung up around Shibboleth

gridshib-intro-dec056 Shibboleth Federations A federation –Provides a common trust and policy framework –Issues credentials and distributes metadata –Provides discovery services for SPs Shibboleth-based federations: –InCommon (23 members) –InQueue (157 members) –SDSS (30 members) –SWITCH (23 members) –HAKA (8 members)

gridshib-intro-dec057 InCommon Federation

gridshib-intro-dec058 Introduction

gridshib-intro-dec059 GridShib Project GridShib is a project funded by the NSF Middleware Initiative (NMI awards and ) GridShib is a joint project of NCSA, University of Chicago, and Argonne National Laboratory Project web site

gridshib-intro-dec0510 Milestones Dec 2004, GridShib project commences Feb 2005, Developers onboard Apr 2005, Globus Toolkit 4.0 released May 2005, GridShib Alpha released Jul 2005, Shibboleth 1.3 released Sep 2005, GridShib Beta released GridShib-MyProxy integration TBA

gridshib-intro-dec0511 Use Cases There are three use cases under consideration: 1.Established grid user (non-browser) 2.New grid user (non-browser) 3.Portal grid user (browser)  Initial efforts have concentrated on the established grid user (i.e., user with existing long-term X.509 credentials )

gridshib-intro-dec0512 Established Grid User User possesses an X.509 end entity certificate User may or may not use MyProxy Server to manage X.509 credentials User authenticates to Grid SP with proxy certificate (grid-proxy-init) The current GridShib implementation addresses this use case

gridshib-intro-dec0513 New Grid User User does not possess an X.509 end entity certificate User relies on MyProxy Online CA to issue short-lived X.509 certificates User authenticates to Grid SP using short-lived X.509 credential Emerging GridShib Non-Browser Profiles address this use case

gridshib-intro-dec0514 Portal Grid User User does not possess an X.509 cert User accesses Grid SP via a browser interface, that is, the client delegates a web application to request a service at the Grid SP MyProxy issues a short-lived X.509 certificate via a back-channel exchange GridShib Browser Profiles apply

gridshib-intro-dec0515 GridShib Implementation

gridshib-intro-dec0516 Software Components GridShib for Globus Toolkit –A plugin for GT 4.0 GridShib for Shibboleth –A plugin for Shibboleth 1.3 IdP Shibboleth IdP Tester –A test application for Shibboleth 1.3 IdP Visit the GridShib Download page:

gridshib-intro-dec0517 The Actors Standard (non-browser) Grid Client Globus Toolkit with GridShib installed (which we call a “Grid SP”) Shibboleth IdP with GridShib installed IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0518 GridShib Attribute Pull Profile In the current implementation, a Grid SP “pulls” attributes from a Shib IdP The Client is assumed to have an account (i.e., local principal name) at the IdP The Grid SP and the IdP have been assigned a unique identifier (providerId) IdP Grid SP CLIENTCLIENT

gridshib-intro-dec GridShib Attribute Pull Step 1 The Grid Client requests a service at the Grid SP The Client presents a standard proxy certificate to the Grid SP The Client also provides a pointer to its preferred IdP IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0520 IdP Discovery The Grid SP needs to know the Client’s preferred IdP One approach is to embed the IdP providerId in the proxy certificate This requires modifications to the MyProxy client software, however Currently the IdP providerId is configured into the Grid SP

gridshib-intro-dec GridShib Attribute Pull Step 2 The Grid SP authenticates the Client and extracts the DN from the proxy cert The Grid SP queries the Attribute Authority (AA) at the IdP IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0522 Attribute Query The Grid SP formulates a SAML attribute query: CN=GridShib,OU=NCSA,O=UIUC The Resource attribute is the Grid SP providerId The NameQualifier attribute is the IdP providerId The NameIdentifier is the DN from the proxy cert Zero or more AttributeDesignator elements call out the desired attributes

gridshib-intro-dec GridShib Attribute Pull Step 3 The AA authenticates the requester and returns an attribute assertion to the Grid SP The assertion is subject to Attribute Release Policy (ARP) IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0524 Attribute Assertion The assertion contains an attribute statement: CN=GridShib,OU=NCSA,O=UIUC member student The Subject is identical to the Subject of the query Attributes may be single-valued or multi-valued Attributes may be scoped (e.g., )

gridshib-intro-dec0525 Name Mapping An IdP does not issue X.509 certs so it has no prior knowledge of the DN Solution: Create a name mapping file at the IdP (similar to the grid-mapfile at the Grid SP) # Default name mapping file CN=GridShib,OU=NCSA,O=UIUC gridshib "CN=some user,OU=People,DC=doegrids" test The DN must conform to RFC 2253

gridshib-intro-dec GridShib Attribute Pull Step 4 The Grid SP parses the attribute assertion and performs the requested service A generalized attribute framework is being developed for GT A response is returned to the Grid Client IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0527 Future Work Solve the IdP Discovery problem –Implement shib-proxy-init Implement DB-based name mapping Provide name mapping maintenance tools (for administrators) Design an interactive name registry service (for users) Devise metadata repositories and tools

gridshib-intro-dec0528 GridShib-MyProxy Integration

gridshib-intro-dec0529 Shib Browser Profile Consider a Shib browser profile stripped to its bare essentials Authentication and attribute assertions are produced at steps 2 and 5, resp. The SAML Subject in the authentication assertion becomes the Subject of the attribute query at step IdP SP CLIENTCLIENT 1 2

gridshib-intro-dec0530 GridShib Non-Browser Profile Replace the SP with a Grid SP and the browser client with a non-browser client Three problems arise: –Client must possess X.509 credential to authenticate to Grid SP –Grid SP needs to know what IdP to query (IdP Discovery) –The IdP must map the SAML Subject to a local principal IdP Grid SP CLIENTCLIENT

gridshib-intro-dec0531 The Role of MyProxy Consider a new grid user instead of the established grid user For a new grid user, we are led to a somewhat different solution Obviously, we must issue an X.509 credential to a new grid user A short-lived credential is preferred Enter MyProxy Online CA…

gridshib-intro-dec0532 MyProxy-first Attribute Pull MyProxy with Online CA MyProxy inserts a SAML authN assertion into a short-lived, reusable EEC IdP collocated with MyProxy IdP Grid SP MyProxy CLIENTCLIENT

gridshib-intro-dec0533 MyProxy-first Advantages Relatively easy to implement Requires only one round trip by the client Requires no modifications to the Shib IdP Requires no modifications to the Client Supports multiple authentication mechanisms out-of-the-box Uses transparent, persistent identifiers: –No coordination of timeouts necessary –Mapping to local principal is straightforward

gridshib-intro-dec0534 IdP-first Non-Browser Profiles The IdP-first profiles require no shared state between MyProxy and the IdP Supports separate security domains Leverages existing name identifier mappings at the IdP IdP-first profiles may be used with either Attribute Pull or Attribute Push

gridshib-intro-dec0535 Attribute Pull or Push? attributes user AA Grid SP user AA request attributes Pull Push

gridshib-intro-dec0536 IdP-first Attribute Pull MyProxy with Online CA MyProxy consumes and produces SAML authN assertions The Client authenticates to MyProxy with a SAML authN assertion IdP Grid SP MyProxy CLIENTCLIENT

gridshib-intro-dec0537 IdP-first Attribute Push The IdP “pushes” an attribute assertion to the Client The Client authenticates to MyProxy with a SAML authN assertion MyProxy consumes both SAML authN and attribute assertions IdP Grid SP MyProxy CLIENTCLIENT

gridshib-intro-dec0538 IdP-first Advantages Since IdP controls both ends of the flow: –Mapping NameIdentifier to a local principal is straightforward –Choice of NameIdentifier format is left to the IdP Attribute push simplifies IdP config and trust relationships Reusable by grid portal use case