Entity ID Policy

Summary

If this entity already has a validly allocated entity ID, you should use that ID for the UK federation. (Ideally, an entity should be known under the same entity ID in all federations of which it is a member.)

If the entity does not already have a validly allocated entity ID, you should construct an https scheme URI based on some DNS domain in your possession, such as a service-specific subdomain of your institutional domain name, or the DNS name of the machine hosting the service in question, followed by '/shibboleth'. Examples:

https://idp.example.org/shibboleth
https://sp.server.org/shibboleth

(While the entity ID does not need to contain 'idp' or 'sp', this can be a useful naming convention.)

For historical reasons, the SDSS federation (forerunner to the UK federation) issued its own urn scheme URIs for entity IDs. While all existing names of this type will remain valid in perpetuity, they are no longer used for new entities.

See also the Internet2 recommendations on entity naming.

Rationale

Every SAML entity, such as a Shibboleth identity provider or service provider, is identified by a unique entity ID, sometimes also referred to as a provider ID. The entity ID is used by entities to refer to themselves during communications, and to look up metadata for other entities.

It is highly desirable that entities are referred to by the same name in every Shibboleth federation of which they are a member, both to simplify configuration and to allow free movement of entities from one federation to another. Allocating multiple names for the same entity should be avoided wherever possible, and to that end the UK federation has a policy of always preferring existing entity IDs for new members to the federation, as long as they have been validly allocated.

Entity IDs are always URIs. At present, the UK federation accepts entity IDs of two different kinds:

  1. An https scheme URI, of the form https://domain.name/path
    Example: https://idp.example.org/shibboleth
  2. A urn scheme URI, of the form urn:valid:urn:allocation
    Examples: urn:mace:inqueue:sp.example.org

The UK federation prefers https scheme URIs over urn scheme URIs for the following reasons:

  • Valid https scheme entity IDs can be constructed on the basis of existing DNS domain names; urn scheme URIs require use of a much more arcane registration hierarchy.
  • Another consequence of the different registration systems used is that https scheme entity IDs can be allocated by the owners of the entity being referred to, whereas urn scheme IDs are normally allocated by a particular federation. Using https scheme entity IDs therefore assists in dispelling the false notion that an entity ID is, or should be, specific to a particular federation.
  • The lack of federation-specific components in https scheme entity IDs may make them more acceptable to other federations.
  • https scheme entity IDs can be constructed to be compatible with alternative metadata publishing schemes such as that described in section 4.1 of the SAML 2.0 metadata specification.

To construct an https scheme entity ID:

  • Start with https://
  • Add the domain name for your machine or service. Prefer the domain name for the service if it is likely to be migrated across physical machines over time.
  • Add an identifying path to complete the URI; conventionally this would be /shibboleth but you can choose any path which, if the entity ID were regarded as a URL, would not currently resolve to an existing file. This allows you to place a copy of the metadata for your entity at that location at a later date, for dynamic metadata discovery. If you wish to de-emphasise the Shibboleth technology, an alternate path of /entity could be used.

If your entity has no existing validly allocated entity ID, the UK federation prefers that you construct an https scheme URI for this purpose.

A less preferable alternative is to allocate your own urn scheme URI from a urn sub-space which you have been delegated control of. As noted above, while such names are valid, the creation of new names of this type is deprecated.