As promised, here's a post on the design for a Security Token Service (Identity Provider) that integrates SharePoint (2010, 2013, or 2016 take your pick, one service covers all versions) and Microsoft's Azure AD (a.k.a. Passport, Windows Live ID, XBox Live ID, Live ID, Windows ID). The premise for such: Microsoft used to provide claims-based authentication for Windows Live IDs, but seems to have lost interest in supporting the interface (the certificate expired October 29th, 2013). Further, SharePoint doesn't accept OAuth2 tokens (even though it will provide them for "Apps").
Hence, an interface layer is required to translate OAuth2 tokens (provided by the Azure AD login service) to a SAML 2.0 token that can be consumed by SharePoint. The following diagram is a high level UML Sequence diagram depicting an unauthenticated Browser (User Agent), SharePoint (Service Provider), Security Token Provider (a.k.a. STS, Identity Provider), and Azure AD (OAuth 2.0 Identity Provider).
So you may ask: Why not use the Azure AD SAML protocol endpoint? This is a really great question! When we started the project, information on the endpoint didn't come across our search scopes. Also, we had developed a number of Identity Providers integrated with web applications that inherited identity properties from a number of sources. Alas, as it turns out, none of these really mattered, because the Azure AD SAML protocol endpoint is described as an Oasis WS-Federation endpoint using three different signing certificates. This is something that SharePoint just cant consume (yet).
Here's some of the reasons why the Azure AD SAML endpoint wouldn't work:
- SharePoint can't consume the WS-Federation Identity Provider Identity Provider descriptor directly.
- Azure AD's Identity Provider endpoint lists three signing certificates, where SharePoint maps a single certificate to an Identity Provider
- Azure AD requires a Metadata URI from the Service Provider which SharePoint doesn't provide natively.
- Azure AD provides so many SAML assertions that SharePoint just doesn't need. This isn't really a failure, but something that can cause the SharePoint "Share UI" to become confused when assigning claims.