An organization's primary domain is a critical piece of information used repeatedly in metadata.
Early in the boarding process, the FIDERN Registration Authority (RA) associates a primary DNS domain with the participating organization. The WHOIS database system is consulted to confirm that the organization does in fact control this domain. Alternatively, a process of Domain Control Validation (DCV) may be administered by the RA to allow an organization to demonstrate control of a domain. The fact that the organization’s home page is rooted in the primary DNS domain provides additional evidence that the organization controls the domain in question.
Any metadata the organization submits is vetted against the primary DNS domain. In particular, the following metadata elements should be rooted in the primary DNS domain of the organization:
- the value of the entityID XML attribute, which is an identifier for the entity (SP or IdP) in metadata
- the value of the <md:OrganizationURL> element, which is the URL of the organization’s home page (mentioned earlier)
- the value of the <shibmd:Scope> element, which is used by an IdP to construct so-called scoped attributes (such as eduPersonPrincipalName)
The RA is authoritative for the organization URL (<md:OrganizationURL>) and the Scope (<shibmd:Scope>). The organization’s site administrator specifies the remaining values in metadata, which are vetted by the RA.
If the entityID and scope (the latter is applicable only to IdP metadata) are rooted in the primary DNS domain, the submitted metadata is approved and the update request proceeds. Otherwise a manual vetting process is triggered, which may delay the approval process.
Entity ID
The entityID is an identifier for your IdP. Although it is almost always a URL, an entityID is a name (not a location). One of your first (and perhaps most important) tasks is to choose a permanent entityID in a namespace you control. Thus the host part of the chosen URL must be rooted in a DNS name you control (as indicated in the whois database or via a Domain Control Validation process administered by the Registration Authority (FIDERN)). This is almost always the primary domain of your organization.
Example. https://sso.example.edu/idp where the primary domain is example.edu
Choose your entityID carefully—you may not get a second chance. Once an entityID is released into the wild, it will be difficult to change, at least not without a lot of pain.
Scope
A Scope is a suffix appended to so-called scoped attributes (such as eduPersonPrincipalName). The attribute's Scope indicates the asserting IdP, which is why the best Scope value is the primary domain of the organization.. Since scoped attributes are typically used for access control at the SP, they are likewise difficult to change once released into the wild.
Avoid multiple Scopes in metadata.
Endpoint Locations
Each of the SAML endpoints published in metadata has a location. Some of these endpoints are browser-facing, and so you should choose a logical hostname that makes sense to the user. This hostname need not agree with your entityID (which is a name, not a location) but in any case, the chosen hostname should be rooted in your primary domain for security, usability, and stability.
Protocol Support
The following deployment strategy forces all protocol traffic over the front channel, which is easier to troubleshoot, manage, and maintain.
Recommended Protocol Support for New IdPs
- DO support SAML2 Web Browser SSO on the front channel
- DO NOT support back-channel SAML protocols