Grid SP

By definition, a SAML SP is a participant in a browser profile. A SAML SP (such as the Shib SP) consumes two types of SAML responses:

1. an authentication response (POST or Artifact binding)
2. an attribute response (SOAP binding)

In the presence of attribute push, there is no attribute response since attributes are bundled with the authentication response. In either case, attributes are resolved based on a previous act of authentication at the !IdP.

In contrast, a Grid SP does not participate in a browser profile, so a Grid SP is unlike a Shib SP. A Grid SP consumes SAML as follows:

1. a SAML response obtained as a result of standalone attribute query (SOAP binding)
2. one or more SAML assertions pushed as a result of X.509 authentication (X.509 or SOAP binding)

In the case of standalone attribute query, the Grid SP may be the principal (wielding an Attribute Query Client) or more likely an entity acting on behalf of the principal (such as GridShibForGlobusToolkit).

In the other case, the Grid SP consumes pushed SAML assertions bound to X.509 certificates or SOAP messages. Like a pulled SAML response, the pushed assertions are used exclusively for access control (not authentication). However, a pushed assertion may include an AuthenticationStatement that describes a previous act of authentication, such as authentication to an online CA (like the GridShibCertificateAuthority) or a gateway (like a TeraGrid ScienceGateway).

As it turns out, push is superior to pull. Pull raises the issue of !IdP Discovery while push has a similar (but less severe) problem called SP Discovery. More importantly, pull permits phishing at the Grid SP since the attribute query is not guaranteed to be based on user consent.