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:
- Client authenticates to the !IdP
- !IdP returns a SAML
Response
to the Client - Client presents the
Response
to MyProxy - MyProxy returns an X.509 credential (with embedded authentication assertion) to the Client
- Client requests a service at the Grid SP
- Grid SP queries a Shibboleth Attribute Authority
- Attribute Authority returns an attribute assertion to the Grid SP
- Grid SP returns a response to the Grid Client
Outline
- The Client makes a Shib Authentication Request to the !IdP. Any passive authentication method supported by the !IdP may be used.
- The !IdP returns a signed SAML
Response
to the Client. TheResponse
contains an authentication assertion. - The Client issues a MyProxy Protocol request to !MyProxy. The
Response
obtained at the previous step is included with the request. - 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. - The Client requests a service at the Grid SP, authenticating with the credential obtained at the previous step.
- The Grid SP authenticates the request, validates and extracts the assertion from the certificate, formulates an
AttributeQuery
based on theSubject
element in the assertion, and issues the query to the Attribute Authority (AA). - The AA maps the
NameIdentifier
in the query to aLocalPrincipal
by virtue of step 2 and returns an attribute assertion to the Grid SP. - 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?