I was asked recently to explore the possibility of external authentication with SharePoint – meaning have SharePoint source its security from an external token service. I was hoping that external provider integration would be easy, but unfortunately it wasn’t. I ran across several blog posts, which provided a step-by-step approach for achieving the security configuration I wanted to achieve, but in the end, they all were essentially what felt like unsupported hacks. All of this had me asking, “Why?”. Why is SharePoint security configuration so hard?
Implementing security configurations for SharePoint has always been painful. This isn’t necessarily the SharePoint team’s fault. SharePoint as a platform has been evolving for over a decade and remains relatively unchallenged in its core competencies—but a decade of continuous development represents at least two generations of technology improvement. Retro-integrating all of this improvement into a 13-year-old platform is difficult enough. For security features, this challenge becomes even more difficult when you consider the options historically available in the Microsoft eco-system. So it’s important to understand that where we’re starting from is truly very complicated.
All of this considered, it is still disappointing that one of the first Microsoft platforms to embrace claims authentication is still using the same mechanisms designed and implemented in 2010. Unlike other web applications today, which can easily adapt to using external claims services over standard protocols, the STS (Security Token Service) still serves as the backbone for SharePoint security. At the time it was built, the STS referenced the still-beta version of the WIF (Windows Identity Framework), which hadn’t even been fully integrated into the .NET Framework (4.5 at the time). In the end, the STS isn’t really designed with interoperability in mind—much of the functionality required for federation with external providers is either not exposed or incomplete.
One of the reasons (if not the key reason) for this gap is that Microsoft’s SharePoint strategy is cloud first. What federation they need to support SharePoint Online access via Windows Azure Active Directory (WAAD) and externally shared MS accounts has already been implemented. In addition, the roadmap for single sign on (SSO) in general at Microsoft revolves around Active Directory Federation Services (ADFS). This is great for SharePoint with WAAD, but leaves no incentive at the moment to make improvements to the way claims security is currently implemented. Of course, there will be continued improvements for app APIs, client-side code, and other integrations, but we shouldn’t expect future versions of SharePoint to natively support more open security implementations any time soon—I think.
The SharePoint with WAAD strategy is a definite improvement and speaks to Microsoft’s understanding of its customers’ needs—namely, that organizations today see enterprise SSO as somewhat of a commodity, thus they expect a straightforward and open standards enterprise solution for all systems and applications in their ecosystem (even if you’re still tied to WAAD in the end). OAuth2 and OpenID are first class protocols in Windows Azure Active Directory. Both protocols are open standards and widely accepted across the technology community, allowing you to federate with identity servers within the Microsoft eco-system (e.g., Windows Azure Active Directory) and without (e.g., Facebook). This also supports the image of the “new Microsoft,” allowing other technologies (e.g., Java or Python) to securely and more easily interact with SharePoint. When you consider the collaboration between the ASP.NET team and open source projects like Thinktecture IdentityServer, it’s becoming easier and easier for software development teams to build solutions, which are OAuth2 and OpenID compatible.
This post is by no means the end of the story. Things are changing rapidly in this space and the Microsoft teams have done an admirable job of keeping important platforms like SharePoint relevant and competitive. What has your experience in this space been? Have you federated with external identity servers in your enterprise? Is security configuration getting easier? Please, leave your opinion in the comments.