An entity ID is a 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 entity ID. Review the general topic on entity naming in the Shibboleth 2 documentation for background information.
IdP Naming
Historically, InCommon assigned an URN (Uniform Resource Name) to all new IdPs, based on the IdP's primary DNS domain name:
<EntityDescriptor entityID="urn:mace:incommon:example.edu">
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:
<EntityDescriptor entityID="https://idp_name.example.edu/idp">
where idp_name is a carefully chosen, logical name for the IdP.
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 will almost certainly cause a service disruption and may require changes 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
Similarly, for new SPs being registered in the Federation, InCommon recommends that URL-based entity IDs be used. For example, an SP might have the following entity ID:
<EntityDescriptor entityID="https://sp_name.example.edu/sp">
where sp_name is again a carefully chosen, logical name for the SP.
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 a name you can commit to maintaining, even if the service will run at a different (or perhaps more than one) location. The entity ID and the endpoint location don't need to match.
Choosing a Name
Below are some tips and suggestions that might be useful when choosing an entity ID. A short list of basic requirements is included at the end.
Tips
- include the substring "idp" or "identityprovider" in an IdP entity ID
- include the substring "sp" or "serviceprovider" in an SP entity ID
- do not include the substring "incommon" in an entity ID
- an URL-based entity ID starting with "https://" is more flexible than one starting with "http://"
- avoid using substring "www" in an URL-based entity ID
- do not use a port number in an URL-based entity ID
- do not end an URL-based entity ID with a slash (/)
Examples
IdP names:
- https://webauth.example.edu/idp
- https://its.example.edu/idp
SP names:
- https://comanage.example.edu/sp
- https://wiki.cs.example.edu/sp
- https://intranet.math.example.edu/sp
Requirements
InCommon will verify that all submitted entity IDs meet the following requirements:
- The IdP entity ID MUST be a URI, preferably a URL.
- The IdP entity ID MUST be globally unique to avoid name collisions both within the Federation and across federations.
- The IdP entity ID MUST accurately reflect the organization asserting it, that is, it MUST contain the primary DNS domain of the organization.
- The domain name reflected in the entity ID MUST be under management control of the submitting organization.