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

Trustworthy IdPs

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

1. Identify at least two Site Administrators to administer 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:
   1. a strong 2048-bit key
   2. the SHA-256 digest algorithm (which may or may not be supported by your software)
5. Expose HTTPS endpoint locations only

Interoperable IdPs

By definition, an interoperable IdP strives to provide an overall positive Federated User Experience.

1. Refresh and verify metadata at least daily (every hour if possible)
2. Support SAML2 Web Browser SSO
3. Publish a SAML2 HTTP-Redirect endpoint in metadata
4. Publish long-lived, self-signed certificates in metadata
5. Publish a technical contact in metadata
6. Stabilize the following elements and attributes in metadata:
   1. entityID
   2. Scope
   3. endpoint locations
   4. certificates
7. Support at least the following user attributes:
   1. eduPersonPrincipalName
   2. eduPersonTargetedID
   3. mail
   4. displayName
   5. givenName
   6. sn (surName)
8. Stabilize the value of eduPersonTargetedID
9. Test and monitor all SAML endpoints 24x7

Discoverable IdPs

A discoverable IdP has the following additional requirements:

1. Publish the following user interface elements in metadata:
   1. DisplayName
   2. Description (optional)
   3. Information URL (optional)
   4. Logo URL
2. Publish an appropriate Error Handling URL in metadata
3. Publish an administrative contact in metadata
4. Release a SAML2 NameID (Transient or Persistent) to all SPs

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

Recommended Protocol Support for New IdPs

Generally speaking, a good rule-of-thumb is to start simple and add more features and capability to your IdP deployment 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.

In any case, you should remove the SAML2 AttributeService endpoint from metadata since a typical SAML2 flow operates completely on the front channel. If you elect not to support SAML1 as well, you end up removing the entire <md:AttributeAuthorityDescriptor> element, resulting in a significantly simpler IdP entity descriptor in metadata.

Another simplification involves the SAML artifact binding. While there are distinct uses for artifact, it too leads to deployment errors and maintenance issues, so avoid SAML artifact and remove the SAML2 ArtifactResolutionService endpoint from metadata, deliberately supporting SAML artifact only when the need arises. Chances are pretty good you will never need it, however.

In summary, the following optimizations force all traffic over the front channel, which is easier to troubleshoot, manage, and maintain.

Later, if an SP partner requires one or more pieces of the above functionality, you can always add new endpoints to your metadata. You may never need these extra SAML features, however, since all new SPs registered in the Federation today are required to support SAML2 Web Browser SSO on the front channel,

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. That said, in almost all cases, it is neither necessary nor advised to register a test IdP in metadata.