Grid Security - Grid Computing: Infrastructure, Service, and Applications - page 311

Shibboleth. When a user attempts to access a Shibboleth-protected service
or service provider (SP) more generally, they are typically redirected to a
WAYF server that asks the user to pick their home identity provider (IdP)
from a list of known and trusted sites. The service provider site already
has a pre-established trust relationship with each home site, and trusts the
home site to authenticate its users properly.
After the user has picked their home site, their browser is redirected to
their site's authentication server, for example, an LDAP repository, and the
user is invited to log in. After successful authentication, the home site
redirects the user back to the SP and the message carries a digitally signed
SAML authentication assertion message from the home site, asserting that
the user has been successfully authenticated (or not!) by a particular
means. The actual authentication mechanism used is specii c to the IdP.
If the digital signature on the SAML authentication assertion is verii ed
and the user has successfully authenticated themselves at their home site,
then the SP has a trusted message providing it with a temporary pseudo-
nym for the user (the handle), the location of the attribute authority at the
IdP site and the service provider URL that the user was previously trying
to access. The resource site then returns the handle to the IdP's attribute
authority in a SAML attribute query message and is returned a signed
SAML attribute assertion message. The Shibboleth trust model is that the
target site trusts the IdP to manage each user's attributes correctly, in
whatever way it wishes. So the returned SAML attribute assertion mes-
sage, digitally signed by the origin, provides proof to the target that the
authenticated user does have these attributes. We note that later versions
of the Shibboleth specii cation have introduced a performance improve-
ment over the earlier versions, by allowing the initial digitally signed
SAML message to contain the user's attributes as well as the authentica-
tion assertion. Thus the two stages of authentication and attribute retrieval
can be combined.
We note that the connection from the IdP to the service provider can also
be optionally protected by SSL in Shibboleth. Here SSL is used to provide
coni dentiality of the connection rather than message origin authentica-
tion. In many cases a coni dential SSL connection between the IdP and SP
will not be required, since the handle can be opaque/obscure enough to
stop an intruder from i nding anything about the user, while the SAML
signature makes the message exchange authentic. However, the message
exchange should be protected by SSL if coni dentiality/privacy of the
returned attributes is required. The attributes in this assertion may then be
used to authorize the user to access particular areas of the resource site,
without the service provider ever being told the user's identity. Shibboleth
has two mechanisms to ensure user privacy. First, it allows a different
pseudonym for the user's identity (the handle) to be returned each time.
Second, it requires that the attribute authorities provide some form of
control over the release of user attributes to resource sites, which they