The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

A good first step in any "permanent" deployment is to choose an appropriate entity ID. Review the general topic on entity naming in the Shibboleth 2 documentation to understand why and how to do this.

IdP Naming

Historically, InCommon assigned a URN (Uniform Resource Name) to all IdPs, based on the IdP's 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 the organization choose a long-lived entity ID in the URL format. 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 require changes at many partner SP sites. It is usually more important for entity IDs to remain stable.

SP Naming

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

InCommon recommends URL-based entity IDs be used throughout the Federation. For example, an IdP might have the following entity ID:

<EntityDescriptor entityID="https://operator_name.example.edu/idp">

where operator_name is a carefully chosen, logical name for the IdP operator. Similarly, an SP might have the following entity ID:

<EntityDescriptor entityID="https://service_name.example.edu/sp">

where service_name is again a carefully chosen, logical name for the SP.

Tips

  • include the substring "idp" or "identityprovider" in an IdP entity ID
  • include the substring "sp" or "serviceprovider" in an SP entity ID
  • avoid the following substrings in your entity ID:
    • "www"
    • "incommon"
    • "shibboleth"
  • in an URL-based entity ID, the path "/sp" is better than path "/sp/saml" is better than path "/sp/shibboleth"
  • an URL-based entity ID starting with "https://" is more flexible than one starting with "http://"
  • do not use a port number in an URL-based entity ID
  • do not end your URL-based entity ID with a slash (/)

Examples

  • https://webauth.example.edu/idp
  • https://its.example.edu/idp
  • 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.
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels