The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdPUnderstandingRP

Type of Relying Parties

In nearly all cases an IdP communicates with a service provider. However, in some more advanced cases an IdP may communicate with other entities (like other IdPs). The IdP configuration uses the generic term relying party to describe any peer with which it communicates. A service provider, then, is simply the most common type of relying party.

The IdP recognizes three classifications of relying parties:

  • anonymous - a relying party for which the IdP has no metadata
  • default - a relying party for which the IdP does have metadata but for which there is no specific configuration
  • specified - a relying party for which the IdP has metadata and a specific configuration

Whether a relying party is authenticated to the IdP is irrelevant to the decision about which category a belongs in.

The configuration for each type of relying party is given by their respective configuration elements: <AnonymousRelyingParty>, <DefaultRelyingParty>, and <RelyingParty>.

type

metadata

specific configuration

configuration elements

anonymous

NO

NO

<AnonymousRelyingParty>

default

YES

NO

<DefaultRelyingParty>

specified

YES

YES

<RelyingParty>

Metadata and Relying Parties

The IdP uses metadata to drive a significant portion of its internal communication logic with a relying party. The metadata contains information such as what keys to use, whether certain information needs to be digitally signed, which protocols are supported, etc. A relying party is identified within metadata by an <EntityDescriptor> element with an entityID attribute whose value corresponds to the relying party's entity ID. Entities may be grouped within an <EntitiesDescriptor> element and this group may be given a name by means of the name attribute. Entity groups may be nested.

When creating a specified relying party configuration you may specify either a specific entity or a group of entities. In that event that there is overlap the most specific configuration is used, no settings are "inherited" because of this overlap. As was mentioned above, a relying party for which the IdP can find no metadata is termed an anonymous relying party.

Relying Party Type Examples

Assume the IdP has loaded the following metadata and has specified configurations for urn:example.org:sp3 and EntityGroup2.

Example Skeletal Metadata
<EntitiesDescriptor Name="AllEntities">

  <EntitiesDescriptor Name="EntityGroup1">
    <EntityDescriptor entityID="urn:example.org:sp1">
       <SPSSODescriptor />
    </EntityDescriptor>
  </EntitiesDescriptor>

  <EntitiesDescriptor Name="EntityGroup2">
    <EntityDescriptor entityID="urn:example.org:sp2">
       <SPSSODescriptor />
    </EntityDescriptor>
    <EntityDescriptor entityID="urn:example.org:sp3">
       <SPSSODescriptor />
    </EntityDescriptor>
  </EntitiesDescriptor>

  <EntityDescriptor entityID="urn:example.org:sp4">
      <SPSSODescriptor />
  </EntityDescriptor>

</EntitiesDescriptor>
  • If a relying party identified as urn:example.org:sp5 attempts to communicate with the IdP it will be treated as an anonymous relying party because there is no metadata for it.
  • If a relying party identified as urn:example.org:sp4 attempts to communicate with the IdP it will be treated as a default relying party since it can be found in metadata but neither has a specified configuration for itself nor belongs to an entity group with a specified configuration.
  • If a relying party identified as urn:example.org:sp3 attempts to communicate with the IdP it will be treated as a specified relying party since there is a specified configuration for it.
  • If a relying party identified as urn:example.org:sp2 attempts to communicate with the IdP it will be treated as a specified relying party since it belongs to the entity group EntityGroup2 which has a specified configuration.