Sunday, October 31, 2004

Shibboleth

Components | Profiles | Attributes | Metadata | Summary ]

Shibboleth, a project of Internet2/MACE, is both a specification and an implementation of a federated identity management solution for higher education. For notational consistency, the current Shibboleth Architecture specification is written in the language of SAML2, which itself is based on Liberty 1.2.

The Shibboleth architecture extends the SAML1 single sign-on and attribute exchange mechanisms by specifying service-provider-first SSO profiles and enhanced features for user privacy. An optional WAYF ("Where are you from?") service provides a means for identity provider discovery.

As an implementation, Shibboleth is built on top of an open-source implementation of SAML 1.1 called OpenSAML. Shibboleth 1.2, the current version of the implementation, is available for download at

Shibboleth 1.2 supports the browser/POST profile only. Later implementations of Shibboleth will support the browser/artifact profile as well. Note that Shibboleth does not specify a single logout profile.

Shibboleth Components

The functional components of a conforming Shibboleth implementation include the following:

  • Identity Provider (formerly called an origin)
    • Authentication Authority

      The authentication authority issues authentication (authn) assertions to other components. The authentication authority is integrated with the IdP's authentication service (the details of which are out of scope).

    • Single Sign-On Service

      A single sign-on (SSO) service is the first point of contact at the IdP. The SSO service initiates the authentication process at the IdP and ultimately redirects the client to the inter-site transfer service (unless the function of the SSO service and inter-site transfer service are combined, which is encouraged). Note: The SSO service is not defined by SAML 1.1 but is defined by SAML 2.0.

    • Inter-Site Transfer Service

      The inter-site transfer service issues HTTP responses according to the browser/POST and browser/artifact profiles. The inter-site transfer service interacts with the authentication authority behind the scenes to produce the required authentication assertion. Note: The concept of inter-site transfer service has been deprecated in SAML 2.0.

    • Artifact Resolution Service

      If the browser/artifact profile is used, the IdP sends an artifact to the SP instead of the actual assertion. (An artifact is a reference to an authentication assertion.) The SP then sends the artifact to the artifact resolution service at the IdP via a back-channel exchange. In return, the IdP sends the required authentication assertion to the SP.

    • Attribute Authority

      The attribute authority processes <samlp:AttributeQuery> requests, that is, it issues attribute assertions. The attribute authority authenticates and authorizes any requests it receives (since such requests may come from either administrators or principals) before responding.

  • Service Provider (formerly called a target)
    • Assertion Consumer Service (formerly called a SHIRE)

      The assertion consumer service is the service provider endpoint of the SSO exchange. It processes the authentication assertion returned by the inter-site transfer service (or artifact resolution service, depending on the profile used), initiates an optional attribute query (see below), establishes a security context at the SP, and redirects the client to the desired target resource.

    • Attribute Requester (formerly called a SHAR)

      An attribute requester (at the SP) and the attribute authority (at the IdP) may conduct a back-channel attribute exchange once a security context has been established at the SP. That is, the SP and IdP interact directly, bypassing the principal.

  • WAYF Service

    An optional WAYF service is operated independently of the SP and IdP. The WAYF is used by the SP to determine the principal's preferred IdP, with or without user interaction. The WAYF is essentially a proxy for the authn request passed from the SP to the SSO service at the IdP. It must therefore fully support the authentication request protocol described below.

Note: Only the components whose name ends in "Service" have browser-facing URIs. The attribute authority is also a web service, but it is only accessible by authorized attribute requesters.

Shibboleth Profiles

Shibboleth specifies two browser-based SSO profiles and a service that may be used with either profile:

  1. Browser/POST Profile
  2. Browser/Artifact Profile
  3. WAYF Service

While the corresponding SAML 1.1 profiles begin with a request to the IdP, the Shibboleth profiles are service-provider-first, and therefore more complicated.

To accommodate SP-first profiles, Shibboleth introduces the notion of authentication request. A Shibboleth authn request is a URL-encoded message sent to an SSO service endpoint at the IdP. The following parameters are included in the query string:

  • providerId

    The providerId parameter is the unique id (usually a URI) of the SP. The IdP may use the providerId to perform special handling or processing of the authn request.

  • shire

    The shire parameter (so named for historical reasons) is the URI of the assertion consumer service endpoint at the SP. When using the browser/POST profile, this URI becomes the value of the FORM element's ACTION attribute. For the browser/artifact profile, the value of the shire parameter is the redirect URL used by the inter-site transfer service.

  • target

    The target parameter is the URI of the target resource. Regardless of the profile used, the target parameter must be preserved by the IdP.

  • time

    The (optional) time parameter is the current time in seconds past the epoch. It is used to avoid caching issues on the client. It is important that the time parameter not be used as any kind of security measure.

Here is an example of a Shibboleth authn request (without URL encoding for clarity):

https://idp.com/shibboleth/SSO?
providerId=https://sp.com/shibboleth/&
shire=https://sp.com/shibboleth/SSO&
target=https://sp.com/myresource&
time=1084819377

Detailed handling of this request is outlined in the subsections below.

Shibboleth Browser/POST Profile

Here is a possible implementation of the Shibboleth Browser/POST Profile. The message flow begins with a request for a secured resource at the SP.

  1. The client requests a target resource at the SP:
    https://sp.com/myresource
    The SP performs a security check on behalf of the target resource. If a valid security context at the SP already exists, skip steps 2–7.
  2. The SP redirects the client to the single sign-on (SSO) service at the IdP. Three parameters (providerId, shire, target) are appended to the redirect URL. (The optional time parameter is omitted in this example.)
  3. The client requests the SSO service at the IdP:
    https://idp.com/shibboleth/SSO?
    providerId=id&shire=acs&target=target
    where
    id = https://sp.com/shibboleth/
    acs = https://sp.com/shibboleth/SSO/POST
    target = https://sp.com/myresource
    The SSO service processes the authn request and performs a security check. If the user does not have a valid security context, the IdP identifies the principal (details omitted).
  4. The SSO service responds with an HTML form:
    ...
    <form method="post" 
          action="https://sp.com/shibboleth/SSO/POST" ...>
      <input type="hidden" name="TARGET" value="target">
      <input type="hidden" name="SAMLResponse" value="response">
      ...
      <input type="submit" value="Submit">
    </form>
    ...
    where the value of the TARGET parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of a SAML Response element:
    <samlp:Response
      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
      MajorVersion="1" MinorVersion="1"
      Recipient="https://sp.com/shibboleth/SSO/POST"
      ResponseID="..."
      IssueInstant="...">
      <ds:Signature 
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>...</ds:SignedInfo>
        <ds:SignatureValue>...</ds:SignatureValue>
        <ds:KeyInfo>...</ds:KeyInfo>
      </ds:Signature>
      <samlp:Status>
        <samlp:StatusCode Value="samlp:Success"/>
      </samlp:Status>
      <saml:Assertion
        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
        MajorVersion="1" MinorVersion="1"
        AssertionID="..."
        Issuer="https://idp.com/shibboleth/"
        IssueInstant="...">
        <saml:Conditions 
          NotBefore="..." 
          NotOnOrAfter="...">
          <saml:AudienceRestrictionCondition>
            <saml:Audience>
              https://sp.com/shibboleth/
            </saml:Audience>
          </saml:AudienceRestrictionCondition>
        </saml:Conditions>
        <saml:AuthenticationStatement
          AuthenticationInstant="..."
          AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
          <saml:Subject>
            <saml:NameIdentifier 
              NameQualifier="https://idp.com/shibboleth/"
              Format="urn:mace:shibboleth:1.0:nameIdentifier">
              3f7b3dcf-1674-4ecd-92c8-1544f346baf8
            </saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>
                urn:oasis:names:tc:SAML:1.0:cm:bearer
              </saml:ConfirmationMethod>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:Assertion>
    </samlp:Response>
    Note that the SAML Response must be digitally signed by the identity provider.
  5. The client issues a POST request to the assertion consumer service at the service provider. To automate the submission of the form, the following line of JavaScript may appear anywhere on the page:
    window.onload = 
      function() { document.forms[0].submit(); };
    This assumes of course that the page contains a single FORM element. If JavaScript is disabled on the client, the user simply presses the submit button.
  6. The assertion consumer service processes the authn response, creates a security context at the SP and redirects the client to the target resource.
  7. The client requests the target resource at the SP (again):
    https://sp.com/myresource
  8. Since a security context exists, the SP returns the resource to the client.
Shibboleth Browser/Artifact Profile

Here is a possible implementation of the Shibboleth Browser/Artifact Profile. The message flow begins with a request for a secured resource at the SP.

  1. The client requests a target resource at the SP:
    https://sp.com/myresource
    The SP performs a security check on behalf of the target resource. If a valid security context at the SP already exists, skip steps 2–9.
  2. The SP redirects the client to the single sign-on (SSO) service at the IdP. Three parameters (providerId, shire, target) are appended to the redirect URL. (The optional time parameter is omitted in this example.)
  3. The client requests the SSO service at the IdP:
    https://idp.com/shibboleth/SSO?
    providerId=id&shire=acs&target=target
    where
    id = https://sp.com/shibboleth/
    acs = https://sp.com/shibboleth/SSO/Artifact
    target = https://sp.com/myresource
    The SSO service processes the authn request and performs a security check. If the user does not have a valid security context, the IdP identifies the principal (details omitted).
  4. The SSO service redirects the client to the assertion consumer service at the SP. A TARGET parameter and a SAMLart parameter are appended to the redirect URL.
  5. The client requests the assertion consumer service at the SP:
    https://sp.com/shibboleth/SSO/Artifact?
    TARGET=target&SAMLart=artifact
    where the value of the TARGET parameter is preserved from step 3 and the SAMLart parameter is a SAML artifact.
  6. The assertion consumer service dereferences the artifact by sending a SAML Request to the artifact resolution service at the IdP:
    <samlp:Request 
      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" 
      MajorVersion="1" MinorVersion="1" 
      RequestID="..." 
      IssueInstant="...">
      <samlp:AssertionArtifact>
        artifact
      </samlp:AssertionArtifact>
    </samlp:Request>
    where artifact is the SAML artifact at step 5.
  7. The artifact resolution service at the IdP returns a SAML Response (containing an authn assertion) to the assertion consumer service at the SP:
    <samlp:Response
      xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
      MajorVersion="1" MinorVersion="1"
      Recipient="https://sp.com/shibboleth/SSO/Artifact"
      ResponseID="..."
      InResponseTo="..."
      IssueInstant="...">
      <samlp:Status>
        <samlp:StatusCode Value="samlp:Success"/>
      </samlp:Status>
      <saml:Assertion
        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
        MajorVersion="1" MinorVersion="1"
        AssertionID="..."
        Issuer="https://idp.com/shibboleth/"
        IssueInstant="...">
        <saml:Conditions 
          NotBefore="..."
          NotOnOrAfter="..."/>
        <saml:AuthenticationStatement
          AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
          AuthenticationInstant="...">
          <saml:Subject>
            <saml:NameIdentifier 
              NameQualifier="https://idp.com/shibboleth/"
              Format="urn:mace:shibboleth:1.0:nameIdentifier">
              3f7b3dcf-1674-4ecd-92c8-1544f346baf8
            </saml:NameIdentifier>
            <saml:SubjectConfirmation>
              <saml:ConfirmationMethod>
                urn:oasis:names:tc:SAML:1.0:cm:artifact
              </saml:ConfirmationMethod>
            </saml:SubjectConfirmation>
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:Assertion>
    </samlp:Response>
  8. The assertion consumer service processes the authn response, creates a security context at the SP and redirects the client to the target resource.
  9. The client requests the target resource at the SP (again):
    https://sp.com/myresource
  10. Since a security context exists, the SP returns the resource to the client.
WAYF Service

A WAYF ("Where are you from?") service is an intermediary between the SP and the IdP. In general, the SP does not know the user's preferred IdP. The process whereby the SP determines the appropriate IdP is called identity provider discovery (generally, a very difficult problem).

Shibboleth specifies an (optional) WAYF service to aid the SP in IdP discovery. In practice, the SP sends its authn request to the WAYF, which somehow determines the user's preferred IdP (through unspecified means) and then subsequently redirects the client to the desired IdP. The WAYF preserves the values of all parameters except the time parameter, which is updated.

A real world example is the WAYF service operated by InQueue. As an experiment, click the link below:

This resource is protected by a Shibboleth SP, which redirects you to the InQueue WAYF. In your browser's location field, you will see the following redirect URL:
https://wayf.internet2.edu/InQueue/WAYF?
target=https%3A%2F%2Fwayf.internet2.edu%2FInQueue%2Fsample.jsp&
shire=https%3A%2F%2Fwayf.internet2.edu%2FShibboleth.shire&
time=1099609640&
providerId=urn%3Amace%3Ainqueue%3Aexample.edu

Now view the source of the InQueue WAYF form and note the hidden fields that preserve the parameters of the original authn request.

Attributes

Compared to other federated identity management solutions, Shibboleth has a well-defined attribute sharing and management process. Shibboleth specifies the use of a standard SOAP-based attribute query protocol from SAML 1.1, a standardized directory schema called eduPerson, and attribute release policies that allow both users and administrators to control the flow of attributes from IdP to SP. As a result, Shibboleth provides powerful authorization capabilities while protecting the privacy of users.

Attribute Query Protocol

Although attributes may be embedded in the authn assertion transferred from IdP to SP, Shibboleth specifies an optional back-channel exchange using SAML over SOAP over HTTP. The SP sends a <samlp:AttributeQuery> element to the IdP and receives an <saml:AttributeStatement> in return. For example, the SP may send an attribute query something like the following:

<samlp:Request
  xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
  IssueInstant="2004-05-25T22:46:10Z" 
  MajorVersion="1" MinorVersion="1"
  RequestID="aaf2319617732113474afe114412ab72">
  <samlp:AttributeQuery 
    Resource="https://sp.com/shibboleth/">
    <saml:Subject 
      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
      <saml:NameIdentifier 
        Format="urn:mace:shibboleth:1.0:nameIdentifier"
        NameQualifier="https://idp.com/shibboleth/">
        082dd87d-f380-4fd6-8726-694ef2bb71e9
      </saml:NameIdentifier>
    </saml:Subject>
  </samlp:AttributeQuery>
</samlp:Request>

The IdP may respond with the following attribute assertion:

<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
  InResponseTo="aaf2319617732113474afe114412ab72"
  IssueInstant="2004-05-25T22:46:10.940Z" 
  MajorVersion="1" MinorVersion="1"
  ResponseID="b07b804c7c29ea1673004f3d6f7928ac">
  <samlp:Status>
    <samlp:StatusCode Value="samlp:Success"/>
  </samlp:Status>
  <saml:Assertion 
    xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
    AssertionID="a144e8f3adad594a9649924517abe933"
    IssueInstant="2004-05-25T22:46:10.939Z" 
    MajorVersion="1" MinorVersion="1"
    Issuer="https://idp.com/shibboleth/">
    <saml:Conditions 
      NotBefore="2004-05-25T22:46:10.939Z"
      NotOnOrAfter="2004-05-25T23:16:10.939Z">
    </saml:Conditions>
    <saml:AttributeStatement>
      <saml:Subject>
        <saml:NameIdentifier 
          Format="urn:mace:shibboleth:1.0:nameIdentifier"
          NameQualifier="https://idp.com/shibboleth/">
          082dd87d-f380-4fd6-8726-694ef2bb71e9
        </saml:NameIdentifier>
      </saml:Subject>
      <saml:Attribute 
        AttributeName="urn:mace:dir:attribute-def:eduPersonEntitlement"
        AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <saml:AttributeValue>
          urn:mace:oclc.org:100277910
        </saml:AttributeValue>
        <saml:AttributeValue>
          urn:mace:example.edu:exampleEntitlement
        </saml:AttributeValue>
        <saml:AttributeValue>
          urn:mace:incommon:entitlement:common:1
        </saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

It is important that the attribute authority be protected against unauthorized access.

Directory Schema

In a cross-domain federated environment, a standard approach to user attributes is crucial. It is essential that providers be on the same page with respect to attributes. If not, this will be a major impediment to federated identity on a large scale.

To address this issue, Internet2 has developed an LDAP object class for higher education called eduPerson, which is administered by EDUCAUSE:

eduPerson is derived from the standard LDAP object class called inetOrgPerson (RFC 2798), which itself is based on other standard LDAP classes (see, e.g., RFC 2256).

Of all the attributes defined by this hierarchy of object classes, approximately 40 attributes have been defined by InCommon as common identity attributes:

Common Attributes  
Highly recommended   6
Suggested 10
Optional 25
  41

For example, here are InCommon's six "highly recommended" attributes:

Attribute Name Example
givenName Mary
sn (surname) Smith
cn (common name) Mary Smith
eduPersonScopedAffiliation   student@some.idp.edu
eduPersonPrincipalName mary.smith@some.idp.edu
eduPersonTargetedID 6xCI1qyLfj12h9wiogTmcebZcL0
 

The NameIdentifier used in the previous examples is a privacy-preserving, opaque identifier that precludes the need to positively identify the principal. Unlike NameIdentifier, which is a transient identifier, eduPersonTargetedID is a persistent identifier. See the EduPerson Specification (200312) for more information about eduPersonTargetedID.

Attribute Release Policy

An attribute release policy (ARP) dictates what user attributes are released to individual service providers. For example, consider the following XML representation of an ARP:

<?xml version="1.0" encoding="UTF-8" ?> 
<arp:AttributeReleasePolicy 
  xmlns:arp="urn:mace:shibboleth:arp:1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:mace:shibboleth:arp:1.0 shib-arp-1.0.xsd">
  <arp:Description>
    This policy applies to all SPs.
  </arp:Description>
  <arp:Rule>
    <arp:Target><arp:AnyTarget /></arp:Target>
    <arp:Attribute 
      name="urn:mace:eduPerson:1.0:eduPersonPrincipalName">
      <arp:AnyValue release="permit" />
    </arp:Attribute>
    <arp:Attribute 
      name="urn:mace:eduPerson:1.0:eduPersonAffiliation">
      <arp:Value release="permit">member@some.idp.edu</arp:Value>
    </arp:Attribute>
  </arp:Rule>
</arp:AttributeReleasePolicy>

The <arp:Target> element lists the SPs to which the rule applies. The above ARP applies to all SPs but individual SPs may be listed. Regular expressions may be used to denote groups of SPs. See the ARP specification for additional examples.

Once the applicable SPs have been defined, the ARP lists the attributes that may be released to those SPs. In the above example, attribute eduPersonPrincipalName may be released to any SP. Attribute eduPersonAffiliation may also be released, but only one value is permitted, namely, "member@some.idp.edu".

Metadata

Both IdPs and SPs publish information about themselves in special XML files called metadata files. Since metadata precisely identify the provider and the services it offers, metadata files are digitally signed for security and privacy.

Shibboleth specifies a minimal subset of the SAML2 metadata specification. Only four md:RoleDescriptorType elements are defined by Shibboleth:

  1. <md:IDPSSODescriptor>
  2. <md:SPSSODescriptor>
  3. <md:AuthnAuthorityDescriptor>
  4. <md:AttributeAuthorityDescriptor>

These metadata elements correspond to the SSO service (IdP), the assertion consumer service (SP), the authentication authority (IdP), and the attribute authority (IdP), respectively.

For example, here is an example of a Shibboleth IdP metadata file (with signatures and keys omitted):

<md:EntityDescriptor 
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  entityID="https://idp.edu/shibboleth/">
  <ds:Signature>...</ds:Signature>
  <md:IDPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.0:protocol:v1.1
urn:mace:shibboleth:1.0">
<md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:KeyName>IdP SSO Key</ds:KeyName> </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault="true" index="0" Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://idp.edu/shibboleth/ArtifactResolution"/> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:mace:shibboleth:1.0:nameIdentifier </md:NameIDFormat> <md:SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:authnRequest" Location="https://idp.edu/shibboleth/SSO"/> </md:IDPSSODescriptor> <md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.0:protocol:v1.1"> <md:KeyDescriptor use="signing"> <ds:KeyInfo> <ds:KeyName>IdP AA Key</ds:KeyName> </ds:KeyInfo> </md:KeyDescriptor> <md:AttributeService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://idp.edu/shibboleth/AA/SOAP"/> <saml:Attribute AttributeName="urn:mace:eduPerson:1.0:eduPersonPrincipalName" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"/> <saml:Attribute AttributeName="urn:mace:eduPerson:1.0:eduPersonAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <saml:AttributeValue>member</saml:AttributeValue> <saml:AttributeValue>student</saml:AttributeValue> <saml:AttributeValue>faculty</saml:AttributeValue> <saml:AttributeValue>employee</saml:AttributeValue> <saml:AttributeValue>staff</saml:AttributeValue> </saml:Attribute> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:mace:shibboleth:1.0:nameIdentifier </md:NameIDFormat> </md:AttributeAuthorityDescriptor> <md:Organization> <md:OrganizationName xml:lang="en"> Identity Provider University </md:OrganizationName> <md:OrganizationDisplayName xml:lang="en"> Identity Provider University @ Some Location </md:OrganizationDisplayName> <md:OrganizationURL xml:lang="en"> http://www.idp.edu/ </md:OrganizationURL> </md:Organization> </md:EntityDescriptor>

Likewise, here is an example of a Shibboleth SP metadata file:

<md:EntityDescriptor 
  xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
  xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  entityID="https://sp.edu/shibboleth/">
  <ds:Signature>...</ds:Signature>
  <md:SPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.0:protocol:v1.1">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:KeyName>SP SSO Key</ds:KeyName>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>
      urn:mace:shibboleth:1.0:nameIdentifier
    </md:NameIDFormat>
    <md:AssertionConsumerService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"
      Location="https://sp.edu/shibboleth/SSO/POST"/>
    <md:AssertionConsumerService index="1"
      Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"
      Location="https://sp.edu/shibboleth/SSO/Artifact"/>
    <md:AttributeConsumingService index="0">
      <md:ServiceName xml:lang="en">
        Service Provider University Portal
      </md:ServiceName>
      <md:RequestedAttribute
        AttributeName="urn:mace:eduPerson:1.0:eduPersonEntitlement"
        AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri">
        <saml:AttributeValue>
          https://sp.edu/entitlements/123456789
        </saml:AttributeValue>
      </md:RequestedAttribute>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
  <md:Organization>
    <md:OrganizationName xml:lang="en">
      Service Provider University
    </md:OrganizationName>
    <md:OrganizationDisplayName xml:lang="en">
      Service Provider University @ Some Location
    </md:OrganizationDisplayName>
    <md:OrganizationURL xml:lang="en">
      http://www.sp.edu/
    </md:OrganizationURL>
  </md:Organization>
</md:EntityDescriptor>

Summary

Shibboleth enjoys a number of advantages over other federated identity management solutions:

  • relatively simple architecture (compared to Liberty 1.2 and SAML 2.0, e.g.)
  • an open-source implementation
  • good online technical support
  • emphasis on user privacy (ARPs, e.g.)
  • standardized attributes (via eduPerson)
  • well-developed federations (InQueue, InCommon)

Of course Shibboleth has some disadvantages as well:

  • difficult to install
  • not fully compliant with SAML 1.1
  • limited exposure outside academia
  • no single logout profile

For an excellent, high-level introduction to Shibboleth and related Internet2 technology, see: