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.

Outrageous Claims: SP Advanced Security Config Will Get Easier

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.

I feel a bi t like Thomas Veil from Nowhere Man when I find myself saying "I know they will. They have to." I guess what I'm really trying to say here is that implementing security configurations for SharePoint is still too difficult. 

Take for example that blog from Wictor Wilen on setting up SharePoint 2013 with Thinktecture Identity Server. This is a great article, but it's typical of a configuration between two identity products in that there are a ton of settings to consider and some of it can only be done through the use of complicated PowerShell commands. 

Likewise, our own product Beowulf Identity Server has faced similar challenges in early deployments. The product is great, however there are still reams of documentation on how to set it up. Don't get me wrong; I'm all for having complete documentation. Still, you know you're in for a time when one of the first things you need to tell folks is the laundry list of skills they're likely to need to configure your product. 

So when I say that advanced SharePoint security will get simpler, understand where we're starting from is truly very complicated. As the demand for more security focused installations grows, those companies that thrive in this space will need to find creative ways to do more with the resources they have on hand in what is already a pretty tight labor market for a niche skill set. From where I sit, this means making the product easier to install and configure, whether that means creating an MSI package, PowerShell administration commands, a setup wizard, or all of the above. 

Further, since some of this complexity comes from the SharePoint side of things, and Microsoft isn't really going to make that easier, the community and vendors will have to pick up the slack. (see Improvements to SharePoint Claims Authentication and Security Will Lag Behind the Industry for reasons why.) 

Wizards and installers can give you a basic set of options that will work for most customers with typical needs, but they can't tell you what is the best practice in your particular circumstance. It's important to remember that wherever you find a security wizard, you'll probably find a security loophole there too. Let's just hope that people will do the right thing and not rely on self-signed certificates and other default settings. However, I would not bet the SharePoint farm on this being the case. 

At the end of the day, IT security itself isn't going to get any easier. I think we'll see security solutions and products that will offer a basic set of turn-key options. Anything advanced or unique to your organization left for experts to figure out how to accomplish it.

 

Outrageous Claims: Where Office 365 Leads, SharePoint Will Follow

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.

 

 

Well, okay maybe that's not such an outrageous claim, since that's been Microsoft's strategy all along, right? What I mean here is that most improvements to SharePoint security have been coming out of changes driven by Office 365.  

So, for example, in 2013 we now have application and server based trust through OAuth type authentication. These are new; in 2010 land we could federate two farms through the mutual exchange of certificates, but there wasn't a really good story to tell around authorizing an individual application.

For folks who run on-premises environments, this means that there will be systems that have to be stood up and maintained alongside SharePoint that didn't exist before. For instance, admins now have to consider will they configure the app host services along with the rest of the basic SharePoint feature set. Or, will you do traditional Windows authentication or use a trusted login provider instead?

Living in a cloud first world also means that security measures we sometimes take for granted in Office 365 - like multi-factor authentication - aren't readily available to us in an on-premises farm. Yes, you could circumvent this by making your sites authenticate against ADFS 3.0 or WAAD/Azure ACS, but doing so is a complex exercise. If you're going to go that far, you'll have some very important decisions you'll want to make about what software package to use and how much you want to rely on either cloud-based or on-prem technology to manage something so important. Always keep in mind that if the authentication provider isn't available for any reason, nobody will be using SharePoint.

What we see happening in the industry now is that more and more products are switching from traditional Windows based authentication to claims based authentication. This change is no doubt fueled by the need to integrate in some respect with cloud platforms like Office 365. However, in the rush to support any possible type of authentication scenario, those same products are making trade-offs against single-sign-on.

Take SharePoint Online for example, where providing a windows-based SSO experience to the user requires running an IIS site specifically to redirect the user from a vanity URL to an Office 365 / ADFS sign-on page where the user's domain is already known. This trick lets us just ask for the user's Windows account and make the trip back to SharePoint without a login form, but this is something of a hack.

Another example comes from a third party product that supports many types of claims authentication including Windows, WAAD, and Office 365. Though the product is quite flexible, customers see issues with having to provide a forms based login when browsing between SharePoint sites and the product's web pages. Configuring things so that they are seamless from an authentication perspective takes significant work.

What we hope to see in the near future are improvements to the way these systems work together, both online and behind the company firewall, so that there's a better sign-on experience overall for the user. Seems like just a few years ago people were saying that federated authentication would mean not having to remember so many credentials, but there seem to be more systems today than there were at that time. Certainly, this one of the reasons why we built Beowulf, and we hope that Microsoft and other vendors will continue to open up new possibilities in this area too.