New IdP Checklist

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,