InCommon Technical Discussions

["Matthew X. Economou" <>]

Dear Alex,

Nick Roy at Internet2 (copied) said that you had some questions about
using AD FS to interoperate with InCommon.  I have some experience
running AD FS 2.0 and 3.0, both as a SAML identity provider (IdP, a/k/a
claims provider) and as a SAML service provider (SP, a/k/a relying
party).  I'm replying from my personal email in order to underline the
point that this is my personal opinion and not that of my employer or my
clients.  All of the usual disclaimers apply.  ;)

You wrote:

> Hello, I am a novice in InCommon and Microsoft ADFS. I would like to
> know the procedures on how to configure MS ADFS for InCommon. Any
> information or assistance will be gratefully appreciated.

To put it bluntly, don't.

If you want an InCommon IdP, deploy a Shibboleth or SimpleSAMLphp
instead, and configure that to release the REFEDS R&S attribute bundle
to all SPs (https://refeds.org/category/research-and-scholarship).  I
would be happy to share my Shibboleth IdP configuration with you.

If you want an InCommon SP, deploy SimpleSAMLphp in SAML proxy mode,
with SimpleSAMLphp's SP registered as an InCommon SP and with AD FS
treating SimpleSAMLphp as its sole IdP.  It isn't possible to disable
the built-in "Active Directory" claims provider trust, so you must set
"ClaimsProviderName" on the relying party trusts, which causes AD FS to
bypass home realm discovery.

AD FS as an InCommon SP (e.g., for SharePoint) will run into the
following problems:

  - metadata integrity checks

AD FS 2016 now allows you to create a group of claims provider trusts
using the InCommon metadata aggregate
(https://md.incommon.org/InCommon/InCommon-metadata-idp-only.xml).
However, it cannot validate the XML digital signature of the aggregate.
We all *strongly* encourage you to download the aggregate and verify its
signature per
https://spaces.internet2.edu/display/InCFederation/Metadata+Consumption.
HTTPS does not guarantee the integrity of the metadata aggregate, which
carries the public keys that the federation trust relies upon.  Only
verifying the signature on the metadata each time it is downloaded
achieves the required level of trust.

  - attribute scope checks

Scoped user identifiers prevent identifier spoofing by rogue IdPs
(https://spaces.internet2.edu/display/InCFederation/2016/05/08/Scoped+Us
er+Identifiers).  I don't know how to write SAML attribute (claims)
acceptance transform rules that implement the necessary scope checks for
a claims provider trusts group.  I do know how to do this for individual
claims provider trusts, cf.
https://github.com/iay/mdq-server/wiki/Interoperating-with-AD-FS, but
this approach has its own challenges.

  - discovery

In the default configuration, where you've consumed the InCommon
metadata aggregate via "Add-AdfsClaimsProviderTrustsGroup", the home
realm discovery (HRD) page will list all 2000+ IdPs by entity ID.  This
makes the default HRD page completely unusable.  We ended up adapting
the Shibboleth Embedded Discovery Service (EDS) for use with AD FS 3.0
(https://github.com/ibrsp/adfs-web-theme), which might also work with AD
FS 2016.

I hope this helps.  Please feel free to ask further questions!

Best wishes,
Matthew

-- 
"The lyf so short, the craft so longe to lerne."