| Note | ||
|---|---|---|
| ||
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 (participants@incommon.org). |
The Use of Other SAML Software
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.
Contents
| Table of Contents | ||
|---|---|---|
|
General Considerations
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.
...
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.
| Warning | ||
|---|---|---|
| ||
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.
Certificates in Metadata
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.
...
| Anchor | ||||
|---|---|---|---|---|
|
Microsoft AD FS
Although Microsoft AD FS is not recommended for general use in the InCommon Federation, it is specifically called out here for two reasons:
- Due to its relationship with Active Directory, it is likely AD FS will find significant usage regardless of recommendations
- It turns out that AD FS 2.0 can be successfully used in some limited circumstances, so the goal here is to outline at least one such use case
...
...
It is strongly recommended that Microsoft AD FS not be deployed as a Service Provider since there is no known 3rd-party tool that will properly consume InCommon metadata. Such an SP represents a security risk (to itself) for reasons mentioned above.
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:
- Use pysFEMMA to refresh and verify metadata (since AD FS 2.0 will not consume SAML metadata whose root element is an
<md:EntitiesDescriptor>element) - Ensure that all SP partners support and use SAML V2.0 (since AD FS 2.0 does not support SAML V1.1)
- Ensure that all SP partners follow InCommon recommendations regarding certificates in metadata. Specifically:
- certificates should be self-signed (since AD FS 2.0 will actually try to check any CRLs or OCSP endpoints contained in the certificate)
- certificates should not be expired (since AD FS 2.0 will not consume an
<md:EntityDescriptor>element that contains an expired certificate) - certificates should not be shared (since some versions of AD FS 2.0 will not consume two
<md:EntityDescriptor>elements that contain the same certificate) - redundant certificates should be avoided (since AD FS 2.0 will not consume an
<md:EntityDescriptor>element containing more than one encryption key)
- Ensure that no SP partners include a
<samlp:Scoping>element in theAuthnRequest(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.
...