Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As mentioned earlier, whether an entityID can actually be resolved into something is generally a secondary issue. However, SAML V2.0 defines a fairly obvious way of obtaining metadata about a given entity by resolving an entityID URL (see section 4.1 of the SAML Metadata Specification).

For this reason, select a URI that you control directly and could resolve at some future date. This is generally not difficult to do because a well-chosen name that has good persistence will usually correspond to a service's public/logical DNS name. When you offer a service to a significant numbers of users, getting them to switch to a different name after they're used to one is effectively impossible.

If you wish to provide a resolvable document, please note the warning in the SAML V2.0 Deployment Profile for Federation Interoperability: "automatic generation of metadata has a strong tendency to undermine the correct functioning of peer deployments in the face of key rollover or changes to endpoints or other software features because it tends to change too suddenly to accommodate a graceful transition between states"

Selection/Assignment

Some Shibboleth federations have strict policies governing the selection of an entityID, though this is more common with IdPs than SPs. In other federations, selection is up to the federation participant, but operators may enforce basic conventions or react negatively to obviously poor choices. In general, you should check with the federation(s) you plan to join, and follow the advice above.