|
Contents
GridShib distributes four software components:
These software components enable deployment scenarios such as those shown in the following diagram:
|
|
In the above diagram, the following deployment scenarios have been identified:
Note that SAML Web Browser SSO [A] is ordinary web browser SSO as implemented by Shibboleth. The remaining deployment scenarios involve one or more GridShib software components.
As depicted in the diagram, the Shib-enabled GridShib CA [B] and the Shib-enabled Science Gateway [C] require a SAML assertion in lieu of a username/password (or some other local credential). A browser user obtains this SAML assertion from an institutional identity provider (IdP) according to standard SAML Web Browser SSO [A]. The IdP identifies the user by any available means (which may or may not involve a username/password) and issues a SAML assertion containing user identity and authentication context. By "authentication context" we mean a representation of the act of authentication at the IdP.
The browser user subsequently presents the SAML assertion to a Shib-enabled service provider (SP). The SP verifies the digital signature on the assertion, consumes the assertion content, and uses the identity and authentication context to make an access control decision. What happens next depends on whether the SP is the Shib-enabled GridShib CA or a Shib-enabled Science Gateway.
The Shib-enabled GridShib CA [B] issues a short-lived end entity credential (EEC) to a browser user. Using Java Web Start technology, the EEC is stored in the file system in the usual place (that is, in the exact location that Globus clients expect to find GSI credentials).
The GridShib CA uses the identity asserted by the IdP to construct the distinguished name (DN) of the EEC. Also, the GridShib CA may issue a SAML assertion of its own, binding this assertion to a non-critical extension of the end entity certificate. Nested in the <saml:Advice> element of this X.509-bound SAML assertion is the SSO assertion received from the IdP. In this way, the GridShib CA proxies the authentication context to a relying party.
On the back end, a Science Gateway uses the GridShib SAML Tools to bind user identity and attributes to a proxy certificate signed by the Gateway's community credential. The Gateway presents this proxy certificate to a GridShib-enabled resource provider (RP) that uses the information in the proxy for auditing, incident response, and access control.
On the front end, the SAML assertion obtained from the IdP contains user identity and authentication context that a Shib-enabled Science Gateway [C] uses for account linking and access control. Like the GridShib CA, the Gateway may proxy the authentication context in the SSO assertion to the RP. The authentication context, along with Gateway-supplied attributes, is passed to the RP in an X.509-bound SAML token. The RP uses this security information for access control, but the RP may also query the IdP for additional attributes, using the identity in the nested SSO assertion. In that case, the deployment scenario incorporates each of [A], [C], and [E] (in that order).
Traditionally, Grid Security Infrastructure (GSI) involves an end user who possesses a long-lived end entity credential (EEC). Using this EEC along with one or more command-line tools, the user issues a proxy credential and requests a grid resource, authenticating with the proxy. In the simplest case, the grid resource provider (RP) uses the distinguished name (DN) in the proxy certificate as a basis for access control, that is, the RP consults an access control list of DNs, called a gridmap. Authorization based on gridmap files is an example of identity-based access control.
One or more GridShib software components may be used to enhance GSI as follows:
As a precursor to GridShib-enabled GSI [D], the GridShib CA may be used to obtain a short-lived end entity credential. This precludes the need to have a long-lived (hence, vulnerable) credential on the user's desktop. Moreover, a GridShib CA-issued EEC contains the authentication context asserted by the institutional IdP, which the RP can incorporate into its access control decision.
The end user can use the GridShib SAML Tools in lieu of grid-proxy-init or myproxy-logon to issue the required proxy credential. This credential may contain self-asserted attributes such as the user's e-mail address or an identifier that the RP can use to query an IdP. The latter addresses the so-called identity provider discovery problem.
With GridShib for GT installed, the RP extracts the identity, authentication context, and user attributes from the proxy credential, and uses this information as a basis for access control. Optionally, the RP may query an IdP for additional attributes, aggregating both pushed and pulled attributes to arrive at a fine-grained, attribute-based access control decision.
In the case of a Shib-enabled Science Gateway [C] or GridShib-enabled GSI [D], the SSO assertion issued by the IdP is bound to an X.509 proxy certificate. The resource provider (RP) can use the identity in the SSO assertion to issue an attribute query to the IdP.
In the case of GridShib-enabled Attribute Query [E], the SAML Subject of the query is the X.509-bound SAML assertion, complete with nested SSO assertion. With GridShib for Shibboleth installed, the IdP can validate the assertion itself, without placing undue trust in the requester or an intermediary (such as the GridShib CA or a Gateway).