| 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.
...
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:
...
- 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.
...