...
| Tip | ||
|---|---|---|
| ||
| RememberSince an entity ID is a name, not a location, the entity ID and the endpoint locations in metadata do not need to match. An entity ID is a name, not a location. If the entity ID is a URL (and it almost always is) it need not resolve. |
...
Historically, InCommon assigned an URN (Uniform Resource Name) to all new IdPs, based on the IdP's primary DNS domain name:
| Code Block | ||
|---|---|---|
| ||
<EntityDescriptor entityID="urn:mace:incommon:example.edu"> |
However, InCommon no longer issues URNs to IdPs. The use of URNs as entity IDs for new IdPs (or any entity, for that matter) is strongly discouraged and in some situations not allowed.
For new IdPs registered in the Federation, InCommon recommends that URL-based entity IDs be used. For example, an IdP might have the following entity ID:
| Code Block | ||
|---|---|---|
| ||
<EntityDescriptor entityID="https://idp_name.example.edu/idp"> |
...
As with IdPs, InCommon recommends that URL-based entity IDs be used in SP metadata. For example, an SP might have the following entity ID:
| Code Block | ||
|---|---|---|
| ||
<EntityDescriptor entityID="https://sp_name.example.edu/sp"> |
...
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.
Choosing a Name
Below are some tips and suggestions that might be useful when choosing an entity IDindependently of the endpoint locations, so if the latter change in the future, the entity ID need not change.
| Info | ||
|---|---|---|
| ||
This The following section is primarily for site administrators registering new entities choosing a name for the first time.in InCommon. |
Choosing a New Name
An entity ID must be globally unique to avoid name collisions both within and across federations. To help ensure global uniquenessIn almost all cases, an entity ID is almost always an absolute URL but it's important to note that an entity ID is a name, not a location. That is, an entity ID need not resolve to an actual web resource.
| Note | ||
|---|---|---|
| ||
Strict InCommon will verify that all newly submitted entity IDs meet the following requirements:
Strong recommendations:
If a site administrator submits metadata with some other form of an entity ID that does not meet the above requirements, a manual vetting process is triggered, which may delay the approval process. |
...
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.
Below are some tips and suggestions that might be useful when choosing an entity ID.
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
- do not include the name of your SAML software in an entity ID ("shibboleth", "adfs", "php", etc.)
- 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
Examples
IdP names:
- https://webauth.example.edu/idp
- https://its.example.edu/idp
...
- https://comanage.example.edu/sp
- https://wiki.cs.example.org/sp
- https://intranet.math.example.edu/sp
- https://myapp.example.com/sp
References
- A There is a general discussion of entity naming in the Shibboleth documentationwiki