The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
EntityNaming
Shibboleth Provider IDs
Any entity implementing shibboleth, whether as an Identity Provider or a Service Provider, is required to identify itself using a unique URI known in the Shibboleth world as a providerID. Here are a few considerations to keep in mind when selecting a providerID.
Persistence
One of the most important attributes a providerID needs to have is persistence, particularly if any type of opaque persistent ID will be used such as eduPersonTargetedId or a SAML2 Persistent Identifier. These attributes are often generated using the providerID's of the involved parties in such a way that changing that ID will completely break the persistence of this attribute for all users. It is possible to survive such a migration, but not without significant work and coordination between the parties.
For this reason, you are encouraged NOT to use the hostname of the particular server a given application will be hosted on. As time passes things get moved and that application may not always live on the same physical server. Additionally there may be multiple applications on that physical server, each needing their own unique ID, so using the server name doesn't scale beyond a single application. Instead a name which describes the application itself is preferred. For example, if the School of Engineering at Example State University is protecting their Blackboard installation, their providerId might be https://engineering.example.edu/blackboard/shibboleth-sp
.
Resolution
In SAML 1.1 (which is used by Shibboleth 1.3), a providerID is not used for any purpose other than uniquely identifying that entity. However SAML2 (which will be used by Shibboleth 2.0) defines a method of obtaining metadata about a given provider by resolving the URL-based providerID (see section 4.1 of saml-metadata-2.0-os.pdf). For this reason, it may be prudent to select a URL that you control and could have it resolve in order to take advantage of this SAML2 feature when the time comes. (This method of metadata resolution only applies if the providerID is a URL.)
Assigned providerID
Many federations assign providerIDs to their member institutions within their namespace. For example, the InQueue federation might assign a URI such as urn:mace:inqueue:example.edu. (... what is the current recommendation on this? ...)