FIM will accept ADFS SAML2 compliant metadata but cannot support ADFS to the same level as the Shibboleth reference implementation. If ADFS is going to be used, we recommend:
- Reviewing the known limitations of ADFS that have been documented here as well as by other federations: https://www.ukfederation.org.uk/content/Documents/ADFS
- Understanding and planning for mitigation of the possible security risks, extra work, and lack of similar features that may cause operational problems borne by using ADFS instead of the reference Shibboleth software
- Using versions of ADFS no older than Microsoft Windows Server 2016, also known as ADFSv4
- Using the aggregate loading feature ADFSClaimsProviderTrustGroups to load the FIM Production Domestic Aggregate and the FIM Production Interfederation Aggregate
If you have not upgraded to ADFSv4, there are numerous third-party tools that can help which can be found at http://adfstoolkit.org
Known Limitations of ADFS and Related Components
ADFS has a number of limitations or differences that Shibboleth software users take for granted.
ADFS limitations include:
- ADFS will not consume SAML metadata whose root element is an
<md:EntitiesDescriptor>
element - ADFS will not consume an
<md:EntityDescriptor>
element that contains an expired certificate - ADFS will check any CRLs or OCSP endpoints that might be contained in the certificate
- ADFS will not consume two
<md:EntityDescriptor>
elements that contain the same certificate - ADFS will not consume an
<md:EntityDescriptor>
element containing more than one encryption key
(pys)FEMMA (This script is intended to automate membership configuration of an ADFS Security Token Service in a SAML2 based Identity Federation.)