Outrageous Claims: SP Claims and Auth Will Lag Behind the Industry

Principal Architect Thomas Carpe shares his thoughts and opinions on the state of the art in SharePoint security, including predictions about things to come. This blog post is part of a continuing series leading up to and following the official launch of Liquid Mercury Solutions' new product Beowulf Identity Server.

Okay, this isn't really fair, since it's really more a case of predicting the present.


To be honest, I was completely caught off guard back in 2013 when the new version of SharePoint was released into the wild without even mediocre support for basic things like FederationMetadata.xml, token encryption, or a half-decent people picker for claims. I'd previously assumed that developing anything in this area was a lost cause; Since Microsoft could easily catch up, and whatever they implemented would inevitably become the standard.

Seems that I was mistaken about where they'd put their energy, and this got me thinking about why SharePoint, which was among the first Microsoft products to fully embrace the claims authentication model, would be so slow to mature.

First thing that comes to mind is that SharePoint really suffers from early adopter syndrome. Back in 2010 when claims authentication was still pretty new, SharePoint was one of the first to implement its own Secure Token Service. Unlike other web applications than can be easily adapted to use an external claims service, this STS still serves as the backbone of SharePoint security to this day, even when external providers are in the mix. At that time it was built with a still-beta version of Windows Identity Framework. Likewise, when 2013 was developed, it's also true that it was one of the first MS products built on .NET 4.5. However, at that time WIF still hadn't been fully integrated into the .NET framework - though parts of it had.

Lately I've been doing a lot of digging around in SharePoint's STS using Reflector, and I can see that a lot of design choices were made here without interoperability or extensibility in mind.

Just as one example, let's take the relationship between SPTrustedLoginProvider and the STS itself. Leaving aside the unusual naming convention (sometimes it's a trusted identity token issuer and other times it's called a login provider), it's interesting to note that much of the information actually needed to federate with another provider isn't actually part of this object, but has to be read from the STS itself. Compare this design with ADFS, which also serves as a kind of STS but has the structure for Relying Party configuration, wherein practically everything that you need to form a relationship between ADFS and another server is stored in one location.

Additionally, a lot of critical functionality here is internal and sealed. While I have never been shy about using reflection to invoke critical methods where needed, this is going to make life difficult for anyone who wants to develop capabilities that require these functions. Just from a support perspective alone, it means that you can't count on Microsoft not to change these functions later on - though from the look of things most of this stuff has not changed much in the past few years. IMHO, MS would do well to open up some of these classes and methods, since sealing them doesn't really provide much in the way of code security anyway. Until they do, it will always be a race to make sure that any patch they release don't radically change things.

Finally, the last reason that I think MS will continue to lag behind others in terms of supporting claims in SharePoint comes down to one simple thing. Microsoft's SharePoint strategy is cloud-first, and the fact is that what federation they needed to support SharePoint Online access via WAAD and externally shared MS accounts has already been implemented. Plus, they have their roadmap in place for SSO using ADFS. So, in essence, they have no impetus to make major improvements to the way this is being done. Sure, there'll continue to be improvements in the API for apps, client side code, etc. But don't expect future versions of SharePoint to be oriented around major usability enhancements for authentication - at least until there's something in it for Microsoft.

This op-ed piece is by no means the end of the story. What experiences have you had with configuring SharePoint security and do you agree with me or disagree that a lot of ground will continue to be left uncovered? Leave your opinion in the comments.