Gridshib-intro-dec051 GridShib An Introduction Tom Scavo NCSA

gridshib-intro-dec05 1

GridShibAn Introduction

Tom [email protected]

NCSA

mailto:[email protected]


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

GridClient

GlobusToolkit

Shibboleth

X.509

SAMLGrid Security Infrastructure

Shibboleth Federation

Bridging Grid/X.509 with Shib/SAML


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)


InCommon Federation


Introduction


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/

http://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


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 )


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


GridShib Implementation


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

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

IdP

Grid SP

CLIENT


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)

3

4

2

1

IdP

Grid SP

CLIENT


1

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

CLIENT


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


2

1

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

CLIENT


Attribute Query• The Grid SP formulates a SAML attribute query:

<samlp:AttributeQuery Resource="https://globus.org/gridshib"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" NameQualifier="https://idp.uchicago.edu/shibboleth"> CN=GridShib,OU=NCSA,O=UIUC </saml:NameIdentifier> </saml:Subject>  </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


32

1

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

CLIENT


Attribute Assertion• The assertion contains an attribute statement:

<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format="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:Attribute AttributeName="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., [email protected])


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


3

4

2

1

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

CLIENT


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-MyProxyIntegration


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

5

6

4

3

IdP

SP

CLIENT

1

2


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

CLIENT


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…


MyProxy-first Attribute Pull• MyProxy with

Online CA• MyProxy inserts

a SAML authN assertion into a short-lived, reusable EEC

• IdP collocated with MyProxy 6

54

3

2

1

IdP

Grid SP

MyProxy

CLIENT


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?

attributes

user

AA

Grid SP

user

AA

request request

attributes

Pull Push


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

8

76

5

4

3

2

1

IdP

Grid SP

MyProxy

CLIENT


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

5

6

4

3

1

2IdP

Grid SP

MyProxy

CLIENT


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

Documents

Gridshib-intro-dec051 GridShib An Introduction Tom Scavo NCSA