AAI and AD FS with SharePoint Workshop
SWITCH organized an AAI and AD FS with SharePoint Workshop at Universität Bern on 3 September 2013.
The intended audience were IdP and SP administrators of institutions participating in SWITCHaai.
Agenda and Slides
The goal of the workshop was to share the existing know-how within the community, identify gaps and try to find ways to fill them. The workshop was not intended to serve as a tutorial on AD FS and SharePoint. The most important components and concepts were introduced, but the use cases and their implementation were in the focus.
- Active Directory Federation Service and SharePoint @ETH Zürich, Tibor Magoc, ETH Zürich
- INSIDE FHNW - requirements and architecture, Michael Hausherr, FHNW
- Technical Implementation @FHNW, Joël Hasler, IOZ AG
Addendum
Ensuring interoperability when AAI-enabling SharePoint with AD FS
- Compatibility of AD FS with self-signed IdP certificates is a non-issue when you configure only the HTTP POST binding, see 'Myth 2' below.
-
SAML attributes not part of the standard set of AD FS (e.g. the eduPerson or swissEduPerson attributes) can be added to the list of known claim descriptions in the 'AD FS Management snap-in' by specifying the same URN-OID used by SAML as 'Claim identifier' and the 'Display name', as shown in the following figure of the 'Add a Claim Description' dialog. That way services like SharePoint can receive all attributes they need as claims.
Figure 1: Screenshot of the 'AD FS Management snap-in'
- The SP wizard in the Resource Registry is now able to process metadata generated by AD FS. That simplifies the process to add an AD FS SP.
Myths and Facts
- Myth 1: "Windows can't handle more than about 100 certificates in a trust store"
-
Fact: This is not true, a Windows trust store can easily contain several hundred entries, even tests with importing 2000 or 3000 self-signed certificates into the "Trusted Root Certification Authorities" didn't indicate any problem. The schannel.dll library, i.e. Microsoft's SSL/TLS implementation, has a limit on the length of the CA list it supports when TLS client authentication is configured, but that's a setting which is irrelevant for an AD FS environment.
References: http://support.microsoft.com/kb/933430, http://support.microsoft.com/kb/2801679
- Myth 2: "Certificates from IdPs need to be trusted (Trusted Root CA Store)"
-
Fact: This is only true for those cases where the communication between the AD FS and the IdP is using the HTTP Artifact binding, as AD FS then needs to connect to port 8443 on the IdP, which is typically configured with a self-signed certificate (according to our recommendations in the SWITCHaai IdP deployment guide). There's a simple solution to avoid this issue: when registering AD FS in the AAI Resource Registry, make sure to configure only a single endpoint, the Assertion Consumer Service for the HTTP POST binding.
In short: Self-signed IdP certificates - as recommended for IdPs in the SWITCHaai federation - do not need any special treatment when the AD FS service provider is properly configured in the AAI Resource Registry: only add the SAML endpoint with the HTTP POST binding, and compatibility with self-signed IdP certificates becomes a non-issue.