530 likes | 671 Views
GridShib A Technical Overview. Tom Scavo trscavo@ncsa.uiuc.edu NCSA. Overview. GridShib project details GridShib use cases GridShib implementation GridShib attribute pull profile GridShib-MyProxy integration GridShib browser profile. What is GridShib?.
E N D
GridShibA Technical Overview Tom Scavotrscavo@ncsa.uiuc.edu NCSA
Overview • GridShib project details • GridShib use cases • GridShib implementation • GridShib attribute pull profile • GridShib-MyProxy integration • GridShib browser profile
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
Tale of Two Technologies Shibboleth Federation Shibboleth Bridging Grid/X.509 with Shib/SAML SAML Grid Security Infrastructure Grid Client Globus Toolkit X.509
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?
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
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 Project • GridShib is a project funded by the NSF Middleware Initiative (NMI awards 0438424 and 0438385) • GridShib is a joint project of NCSA, University of Chicago, and Argonne National Laboratory • Project web sitehttp://gridshib.globus.org/
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
Related Projects • Globus Toolkithttp://www.globus.org/toolkit/ • Shibbolethhttp://shibboleth.internet2.edu/ • LionSharehttp://lionshare.its.psu.edu/ • eSP-gridhttp://e-science.ox.ac.uk/oesc/projects/index.xml.ID=body.1_div.1#esp
Leveraged Standards • X.509 Public Key Infrastructure (RFC 3280) • Proxy certificates (RFC 3820) • OASIS SAML 1.1 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security#samlv11 • Internet2 Shibbolethhttp://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-latest.pdf
Use Cases • There are three use cases under consideration: • Established grid user (non-browser) • New grid user (non-browser) • Portal grid user (browser) • Initial efforts have concentrated on the established grid user (i.e., user with existing long-term X.509 credentials )
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
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
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
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:http://gridshib.globus.org/download.html
The Actors • Standard (non-browser) Grid Client • Globus Toolkit with GridShib installed (which we call a “Grid SP”) • Shibboleth IdP with GridShib installed C L I E N T IdP Grid SP
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) C L I E N T IdP 2 3 1 Grid SP 4
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 C L I E N T IdP 1 Grid SP
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 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 C L I E N T IdP 2 1 Grid SP
Attribute Query • The Grid SP formulates a SAML attribute query:<samlp:AttributeQueryResource="https://globus.org/gridshib"> <saml:Subject> <saml:NameIdentifierFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"NameQualifier="http://idp.uchicago.edu/shibboleth"> CN=GridShib,OU=NCSA,O=UIUC </saml:NameIdentifier> </saml:Subject> <!-- AttributeDesignator here --> </samlp:AttributeQuery> • 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 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) C L I E N T IdP 2 3 1 Grid SP
Attribute Assertion • The assertion contains an attribute statement:<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifierFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="http://idp.uchicago.edu/shibboleth"> CN=GridShib,OU=NCSA,O=UIUC </saml:NameIdentifier> </saml:Subject> <saml:AttributeAttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation"AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <saml:AttributeValue> member </saml:AttributeValue> <saml:AttributeValue> student </saml:AttributeValue> </saml:Attribute></saml:AttributeStatement> • The Subject is identical to the Subject of the query • Attributes may be single-valued or multi-valued • Attributes may be scoped (e.g., member@uchicago.edu)
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 fileCN=GridShib,OU=NCSA,O=UIUC gridshib"CN=some user,OU=People,DC=doegrids" test • The DN must conform to RFC 2253
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 C L I E N T IdP 2 3 1 Grid SP 4
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
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 4 1 C L I E N T IdP 2 4 5 3 SP 6
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 C L I E N T IdP Grid SP
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 significantly 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…
MyProxy-first Attribute Pull • MyProxy with Online CA • MyProxy inserts a SAML authN assertion into a short-lived, reusable EEC • IdP collocated with MyProxy C L I E N T IdP MyProxy 1 4 5 2 3 Grid SP 6
MyProxy-first Attribute Pull Step 1 • A MyProxy Client sends a MyProxy Protocol request to a MyProxy Server • Any authentication method supported by MyProxy may be used C L I E N T IdP MyProxy 1 Grid SP
MyProxy-first Attribute Pull Step 2 • The MyProxy Server authenticates the requester • MyProxy issues an X.509 credential with embedded authN assertion • The credential is returned in a MyProxy Protocol response C L I E N T IdP MyProxy 1 2 Grid SP
Authentication Assertion • MyProxy inserts an assertion containing a minimal authentication statement into the certificate:<saml:AuthenticationStatementAuthenticationInstant="2004-12-05T09:22:00Z"AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:Subject> <saml:NameIdentifierFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"NameQualifier="https://idp.example.org/shibboleth"> user@idp.example.org </saml:NameIdentifier> </saml:Subject></saml:AuthenticationStatement> • AuthenticationMethod may be used by Grid SP • The NameQualifier attribute is the IdP providerId • The IdP easily maps the NameIdentifier to the desired local principal
MyProxy-first Attribute Pull Step 3 • A Grid Client requests a service at a Grid SP • The client presents the decorated X.509 certificate obtained from MyProxy C L I E N T IdP MyProxy 1 2 3 Grid SP
MyProxy-first Attribute Pull Step 4 • The Grid SP authenticates the Client and processes the assertion • The Grid SP queries the Shib Attribute Authority (AA) referred to in the assertion C L I E N T IdP MyProxy 1 4 2 3 Grid SP
MyProxy-first Attribute Pull Step 5 • The AA authenticates the requester and returns an attribute assertion to the Grid SP • The assertion is subject to policy C L I E N T IdP MyProxy 1 4 5 2 3 Grid SP
MyProxy-first Attribute Pull Step 6 • The Grid SP parses the attribute assertion and makes an access control decision • A response is returned to the Client C L I E N T IdP MyProxy 1 4 5 2 3 Grid SP 6
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
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
Attribute Pull or Push? Push Pull user user Grid SP request request attributes attributes AA AA
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 1 C L I E N T IdP 2 3 MyProxy 7 6 4 5 Grid SP 8
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 1 C L I E N T IdP 2 3 MyProxy 4 5 Grid SP 6
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
IdP-first Browser Profiles • As a consequence of the IdP-first Non-Browser profiles, MyProxy gains the ability to consumes SAML assertions • If we replace the non-browser client with a web component, we can reuse that functionality in the following GridShib Browser Profile