New IdPs in Metadata

Effective federation depends on IdPs that are both interoperable and trustworthy. To this end, a new IdP is expected to satisfy certain requirements. Some of these requirements are operational while other requirements pertain to the IdP's entity descriptor in metadata. IdP metadata will not be approved until these requirements are met.

Contents

The following requirements contribute significantly to both trustworthiness and interoperability:

1. Refresh and verify metadata at least daily (every hour if possible)
2. Sign assertions using a strong 2048-bit key

These are basic requirements of all InCommon IdPs.

Trustworthy IdPs

A trustworthy IdP is the basic building block of an identity federation.

1. Identify at least two Site Administrators to manage IdP metadata
2. Create and handle your private key safely and securely!
3. Do not share your signing key with other SAML entities
4. Sign assertions using the SHA-256 digest algorithm (eventually)
5. Expose HTTPS endpoint locations only

In particular, safeguarding the IdP’s private signing key protects all Federation participants from the disastrous consequences of a key compromise.

Interoperable IdPs

By definition, an interoperable IdP is capable of providing an overall positive Federated User Experience.

1. Support SAML2 Web Browser SSO
2. Stabilize the following elements and attributes in metadata:
   1. entityID
   2. Scope
   3. endpoint locations
   4. long-lived, self-signed certificate
3. Publish a SAML2 HTTP-Redirect endpoint in metadata
4. Test and monitor all SAML endpoints 24x7
5. Support at least the following user attributes:
   1. eduPersonPrincipalName
   2. eduPersonTargetedID
   3. mail
   4. displayName
   5. givenName
   6. sn (surName)
6. Release a SAML2 NameID (Transient or Persistent) to all SAML2 SPs
7. Publish a technical contact in metadata

Discoverable IdPs

In addition, a discoverable IdP has the following requirements:

1. Publish the following user interface elements in metadata:
   1. DisplayName
   2. Description
   3. Logo URL
2. Publish an appropriate error handling URL in metadata
3. Publish an administrative contact in metadata

An IdP that supports the Research & Scholarship Category MUST be discoverable.

Advice Regarding IdP Protocol Support

A good rule-of-thumb is to start simple and add more features and capability to your IdP as it matures. Experience has shown that seldom used features are often deployed without adequate testing, leading to latent deployment bugs and even security holes.

A basic strategy is to initially support SAML2 only. The protocol flows for SAML2 and SAML1 are distinctly different, so constraining your IdP’s protocol support can have significant benefits in terms of troubleshooting, maintenance, and reliability. Therefore, unless you have an SP partner that specifically requires SAML1 (there are fewer and fewer of these, it seems), we recommend you avoid SAML1 endpoints in metadata altogether.

If you choose not to support SAML1, you end up removing the entire <md:AttributeAuthorityDescriptor> element from metadata since a SAML2 AttributeService endpoint is usually not needed for typical SAML2 flows (which operate completely on the front channel). Thus attribute query can be completely avoided in most cases and what you're left with is a significantly simpler entity descriptor in metadata.

Another simplification involves the SAML artifact binding. While there are uses for artifact, it too leads to deployment errors and maintenance issues, so avoid SAML artifact if possible (in both directions). Like the SAML1 protocol itself, a good strategy is to deliberately support SAML artifact only when the need arises. Chances are pretty good you will never need it, however.

So the final step is to remove the SAML2 ArtifactResolutionService endpoint from metadata. Doing so forces all traffic over the front channel, which again is easier to troubleshoot, manage, and maintain.

If an SP partner comes along in the future and needs one or more pieces of the above functionality, you can always add new endpoints to your metadata. However, since all SPs registered in the Federation today are required to support SAML2 Web Browser SSO on the front channel, you may never need these extra SAML features.

Test IdPs

The first IdP an organization introduces into metadata is assumed to be a production IdP. Please do not submit temporary IdP metadata with the intention of changing it later on. IdP metadata that is obviously temporary (e.g., metadata that contains the substring "test" in names and locations) will not be approved.

As a matter of policy, each organization is allowed one IdP entity descriptor in metadata. By request, a second IdP in metadata may be purchased for an extra $1,000 per year. This second IdP may be a test IdP, however, in almost all cases, it is neither necessary nor advised to register a test IdP in metadata.