An entity ID is a globally unique name given to a SAML entity, either an Identity Provider (IdP) or a Service Provider (SP). The first step in any " permanent " SAML deployment is to choose an appropriate a persistent entity ID. Review the general topic on entity naming in the Shibboleth 2 documentation for background information.
| Warning | ||
|---|---|---|
| ||
Once chosen, it is strongly recommended that you do not change the entity ID of an IdP or SP in metadata. Although this is possible in the current version of the Federation Manager (FM), future versions of the FM will not allow an existing entity ID to be changed. |
Attempts to change an existing entity ID will trigger a potentially lengthy manual vetting process. Be prepared to explain why you think it is necessary to change your entity ID.
IdP Naming
Historically, InCommon assigned an URN (Uniform Resource Name) to all new IdPs, based on the IdP's primary DNS domain name:
...
However, InCommon no longer routinely issues URNs to IdPs. For new IdPs being registered in the Federation, InCommon recommends that URL-based entity IDs be used. For example, an IdP might have the following entity ID:
...
For those IdPs that already have an URN-based entity ID, InCommon strongly recommends that you do not change your entity ID to one that is URL-based (or anything else, for that matter). Although this is possible, it is not recommended because it . In fact, you should never change an IdP entity ID. Doing so will almost certainly cause a service disruption and may require changes disruptions at many partner SP sites. It is usually more important for entity IDs to remain stable.
What about iTunesU?
Apple's deployment of SAML support for iTunesU has a bug that prevents the use of URL-based entity IDs (an assumption about URNs is hardwired into their software). If you're a customer, potential or otherwise, we would advise sticking with the URN convention rather than trying to register multiple times with different names.
We have been in intermittent contact with Apple about fixing this problem. In the meantime, it wouldn't hurt if participants asked them directly about this issue.
SP Naming
The user experience may be adversely affected as well (since discovery interfaces typically write cookies containing the IdP entity ID).
SP Naming
As with IdPsSimilarly, for new SPs being registered in the Federation, InCommon recommends that URL-based entity IDs be used in SP metadata. For example, an SP might have the following entity ID:
...
As with IdP naming, you MUST be prepared to commit to maintaining an SP entity ID essentially for the life of the service. If you aren't prepared to guarantee that using the actual hostname at which you plan to make the service available to your user community, then pick Choose a name you can commit to maintaining , even if the service will run at a different (or perhaps more than one) location . The in the future. Remember, the entity ID and the endpoint location don't need to match.
...