GridShib !IdP-first Non-Browser Profile with Attribute Pull

This non-browser profile is analogous to the SAML 1.1 Browser/POST profile.

Preconditions

All the preconditions of the Attribute Pull profile apply. In addition, the following preconditions must be satisfied:

  • MyProxy has been assigned a providerId.

Protocol Flow

Overview

This GridShib profile consists of eight (8) steps:

  1. Client authenticates to the !IdP
  2. !IdP returns a SAML Response to the Client
  3. Client presents the Response to MyProxy
  4. MyProxy returns an X.509 credential (with embedded authentication assertion) to the Client
  5. Client requests a service at the Grid SP
  6. Grid SP queries a Shibboleth Attribute Authority
  7. Attribute Authority returns an attribute assertion to the Grid SP
  8. Grid SP returns a response to the Grid Client

Outline

  1. The Client makes a Shib Authentication Request to the !IdP. Any passive authentication method supported by the !IdP may be used.
  2. The !IdP returns a signed SAML Response to the Client. The Response contains an authentication assertion.
  3. The Client issues a MyProxy Protocol request to !MyProxy. The Response obtained at the previous step is included with the request.
  4. MyProxy validates the signature on the Response , generates an X.509 credential, inserts the authentication assertion into the certificate, and returns the credential to the Client.
  5. The Client requests a service at the Grid SP, authenticating with the credential obtained at the previous step.
  6. The Grid SP authenticates the request, validates and extracts the assertion from the certificate, formulates an AttributeQuery based on the Subject element in the assertion, and issues the query to the Attribute Authority (AA).
  7. The AA maps the NameIdentifier in the query to a LocalPrincipal by virtue of step 2 and returns an attribute assertion to the Grid SP.
  8. The Grid SP parses the attribute assertion, makes an access control decision, and returns a response to the Grid Client.

Requirements

All the requirements of the Attribute Pull profile apply.

Advantages

  • supports separate security domains
  • this protocol is independent of Shibboleth.NameIdentifierFormat
  • !IdP both produces and consumes Shibboleth.NameIdentifier and Shibboleth.LocalPrincipal
  • requires no shared state between !IdP and MyProxy
  • reusable by grid portal use case

Issues

  • Authentication assertions are typically short-lived (5 mins or so) while proxy certificates are relatively long-lived (8 hrs). Since we want the NameIdentifier in the assertion to have a lifetime equal to that of the certificate, how do the !IdP and MyProxy coordinate the lifetimes?
  • No labels