GridShib Attribute Exchange Profile with Attribute Pull

Preconditions

  • The Grid User and the Grid Service Provider (SP) each possess an X.509 credential.
  • The Grid User has an account with a Shibboleth Identity Provider (!IdP).
  • The Grid Client application has access to the Grid User's X.509 credential.
  • The Grid User's X.509 certificate contains a SAML authentication assertion.
  • The !IdP and the Grid SP each have been assigned a unique identifier called a providerId.
  • The Grid SP and the !IdP rely on the same metadata format and exchange this metadata out-of-band.

Protocol Flow

Overview

This GridShib profile consists of four (4) steps:

  1. The Grid Client requests a service at the Grid SP.
  2. The Grid SP authenticates the Client and queries the AA at the !IdP.
  3. The AA returns an attribute assertion to the Grid SP.
  4. The Grid SP performs the requested service and returns a response to the Grid Client.

GridShib Attribute Pull Profile

Outline

  1. The Grid Client requests a service at the Grid SP. The Client presents an X.509 credential with embedded authentication assertion to the Grid SP.
  2. The Grid SP authenticates the Client, processes the authentication assertion, and queries the Attribute Authority (AA) at the !IdP.
  3. The AA authenticates the requester and returns an attribute assertion to the Grid SP.
  4. The Grid SP parses the attribute assertion, performs the requested service, and returns a response to the Grid Client.

Requirements

All the requirements of the Shibboleth Attribute Exchange Profile [ShibProt] apply. In addition, the following requirements must be satisfied:

  • The X.509 certificate used to authenticate the Client at step 2 MUST contain one and only one SAML authentication assertion in a certificate extension.
  • The SAML authentication assertion MAY contain multiple authentication statements. No two authentication statements may have the same value for the NameIdentifier/@NameQualifier attribute.
  • The Grid SP issues zero or more attribute queries, one for each authentication statement in the assertion.
  • The Grid SP MAY choose to skip any or all attribute queries if it is determined that a particular attribute assertion is not required or necessary.
  • If the Grid SP chooses to query for attributes, the query MUST be sent to the !IdP corresponding to the providerId given in the NameIdentifier/@NameQualifier attribute in the statement. Metadata MAY be used to determine the location endpoint of the corresponding !IdP.
  • The NameIdentifier element of the query MUST be identical to the NameIdentifier element of the assertion in the certificate extension.
  • The query SHOULD NOT have a Subject/SubjectConfirmation element.
  • The Grid SP SHOULD ignore any non-attribute statements in the response.
  • The Subject of each attribute statement in the response SHOULD strongly match the Subject of the query. Any attribute statement with a Subject that does not strongly match the Subject of the query should be discarded.
  • If there are one or more AudienceRestrictionCondition/Audience elements in the response, the Grid SP SHOULD verify that it is a member of at least one audience. [Is this a SAML requirement?]
  • The Grid SP MAY ignore any Subject/SubjectConfirmation elements in the response.
  • In processing the attribute response, the Grid SP collapses the value of the AttributeValue/@Scope attribute into the value of Attribute/AttributeValue by appending "@" followed by the AttributeValue/@Scope value to the Attribute/AttributeValue .

Examples

Issues

  • No labels