This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list (email@example.com).
For a complete list of software recommended for use in the InCommon Federation, see the parent Software Guidelines wiki page. Here we discuss the use of other SAML software implementations, in particular, Microsoft AD FS 2.0.
If you choose not to use one of the recommended SAML software implementations, be advised that you may incur additional deployment costs and/or experience operational challenges. In extreme cases, you may cause interoperability issues with your federation partners. While the use of recommended software is not guaranteed to eliminate all problems, experience has shown that the likelihood of issues is greatly increased if you don't.
The impact of your software choices depends to a certain extent on your role(s) in the Federation. For an Identity Provider, the primary responsibility is to authenticate users and issue accurate assertions about them. In most cases, deficiencies in software products will not negatively impact your ability to do so, but occasional disruptions in service are likely, especially if your deployment lacks appropriate metadata support, in which case your ability to handle operational changes made by Service Providers will be limited and manual.
A Service Provider on the other hand is principally concerned with securing its systems and maintaining a sufficient degree of protection of its resources. In addition to the reliability issues noted above, a lack of metadata support can in some cases limit an SP's ability to deal with a compromised signing key of an IdP partner. The use of metadata in the Federation is tightly orchestrated to address various risks that aren't adequately addressed by manually configuring metadata in the fashion that many products do.
It is strongly recommended that InCommon SPs and IdPs refresh and verify metadata at least daily. Regular metadata refresh promotes interoperability, protects users against spoofing and phishing, and is a necessary precaution in the event of key compromise. Failure to refresh metadata exposes Federation users to unnecessary risk.
Visit the Metadata Consumption wiki page for more information about metadata refresh.
In general, SAML implementations have varying degrees of support for X.509 certificates in metadata, which leads to known and well understood interoperability issues. These software limitations need to be factored into the software decision-making process.
In particular, to fully support key rollover, implementations MUST support the following features:
<md:KeyDescriptor use="signing">in a single role descriptor
<md:KeyDescriptor>in a single role descriptor
<md:KeyDescriptor>elements (with no
useXML attribute) in a single role descriptor, but this is not strictly required since it can usually be avoided in practice.
Consult your software documentation to better understand its capabilities. Indeed, evaluate software capabilities with respect to certificate handling before you deploy, if at all possible.
Although Microsoft AD FS is not recommended for general use in the InCommon Federation, it is specifically called out here for two reasons:
By far the dominant deployment scenario in the InCommon Federation involves an IdP-only campus interoperating with one or more SP-only Sponsored Partners. In this and similar situations, AD FS 2.0 can be successfully deployed as an Identity Provider if all of the following are true:
<md:EntityDescriptor>element that contains an expired certificate)
<md:EntityDescriptor>elements that contain the same certificate)
<md:EntityDescriptor>element containing more than one encryption key)
<samlp:Scoping>element in the
AuthnRequest(since AD FS 2.0 will reject such a request)
Recognizing the limitations of AD FS, the international REFEDs community is calling upon Microsoft to address this situation. Visit the adfstoolkit.org web site to add your voice to this effort.
Another good source of relevant information is the Microsoft Interoperability page in the Shib wiki.