...
A common misconception is that the entity ID must match the endpoint locations for the deployment. This is not required and is often not the case. Unlike the endpoint locations, the entity ID should accurately reflects reflect the organization that owns the entity. Endpoint locations, on the other hand, are resolvable DNS names. An entity ID may or may not actually resolve to a web resource. (If it does, it is usually a page that describes the deployment.)
...
The following sections give recommendations regarding entity naming within the InCommon Federation. For background information, review the general topic on entity naming in the Shibboleth 2 documentation.
...
As with IdP naming, you MUST be prepared to commit to maintaining an SP entity ID essentially for the life of the service. Choose a name you can commit to maintaining even if the service will run at a different (or perhaps more than one) location in the future. Remember, the entity ID and the endpoint location locations don't need to match.
Choosing a Name
...
- 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
- do not include the name of your SAML software 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 end an URL-based entity ID with a slash (/)
- do not include a port number, a query string (?), or a fragment identifier (#) in an URL-based entity ID
...