Office 365 Security and You - Access Control

YouTuber JackSkepticEye plays Papers, Please. What does this have to do with Office 365 security, read on and find out! This is the second part of a series on cloud security topics. In the first part, I discussed the threat that has Ransomware over people and companies. I started this series to book-end around my appearance as part of the SharePoint security panel at this week's Federal IT Security Conference. Since that conversation unfolded, I think we'll do a Part 3 next week to cover the topics discussed at the panel, which were very different that I imagined they would be.

PART 2: 12 Ways to Control When and Where People Access Office 365

Recently, many of our customers who are interested in migrating to Office 365 have been asking us questions about whether it's possible to control when, how, and where their employees can access their data.

While there are some technical approaches that may work, the unfortunate news is that there's no "silver bullet", at least as far as we've been able to find - yet. Many possible solution feel like kludgy work-arounds, temporary half-measures, partial solutions, or something created only for larger organizations.

I thought I'd take the opportunity to put together a list of possible ways to tackle this challenge. Even though no option is a complete answer, it's possible that some of these may be a good fit for your specific circumstances. I'll do my best to go over the pros and cons of each option.

Is this necessary? Depending on who you are and what you do, maybe not. Overkill? A bit heavy handed? Perhaps. Thus the graphic above, which (for those of you who may not be gamers) parodies an Arstotzkan border guard from the dystopian job simulator game classic "Papers, Please". Understand though that in some cases it may be reasonable, since many industries are subject to regulatory compliance requirements that might not always be perfectly aligned with a cloud based IT strategy.

Fair warning, this is a pretty complex topic. Hopefully everyone has gotten over their election night hangover and is ready to dig in. So, without any more fanfare, let's check out some methods to implement extreme vetting in Office 365.

Access Control - The Basics

When we think about granting access, we're basically describing the five W's that need to be addressed in order to make a decision about letting a person have access to information. A perfect access and identity system would answer all the questions below before letting someone in to the system - and may even use some of the answers to put a limit on what they can access at any given moment.

Who

  • Is the user logging in actually who they say that they are?
  • How confident are we in that?
  • Have they been educated and informed about security and privacy policies?
  • Is their ability to act responsibly expected?

What

  • What is being accessed; is it email, documents, some other data?
  • Is accessed content subject to regulation such as HIPAA, SOX, or GLBA?

Where

  • What network are they connected from?
  • Do we have any geo-location data?

When

  • Is it the normal workday or after-hours?
  • How does "now" jive with past or expected work patterns?

How

  • Is it a known PC, mobile device, or something new/different?
  • Are they using a browser (that can run JavaScript or CAPTCHA test), or could this be a bot?

Why

  • What's the business purpose behind needing the information?
  • Is it reasonable to expect responsible behavior?
  • If the behavior is unusual, is it known in advance or has it been vetted?

Okay, so now that we've been over what sorts of things go into granting access, let's get specific. The answers to "who" and "what" are already largely covered by conventional authentication and authorization systems. The topic in question - the one we're hearing about from our customers - specifically addresses the "when", "where", and maybe "how" above.

So, without further ado, here's my list of 12 things that can be done to control access to Office 365 and other resources in the cloud. Some are cheap. Some are definitely not. None are perfect for everyone. That's just life, I guess. If you'd like help finding a solution that will work for you, please talk to us about it, because that's what we do at Liquid Mercury Solutions.

Option 1: Just don't share the password with the user

It sounds stupidly easy, but if you don't want somebody to login from home, don't give them their own password. You can handle this in a couple of different ways. Either set up the Office 365 account on their work PC and save the credentials to it without telling them the password, or go ahead and give them their own account but have another account that is only used for access to important or sensitive information, and then keep that one under lock and key.

Plus side:

  • 100% effective once stored on the local PC.
  • Cheapest option available.
  • Can work even with Cloud Only users. No AD domain controller required.

Down side:

  • Creates a feeling of oppression and lack of ownership.
  • Ties access to a single person; people can't get access when people who know the password aren't there.
  • Tendency to use the same password on multiple logins is a bad idea.
  • Tendency to use the same login for multiple people is a worse idea.
  • These factors together mean that this approach may be abused in ways that are worse than the problem that its trying to prevent.

Option 2: Trust but verify

You know, I really think we spend too much time thinking about all the ways that people are going to steal from us. When you consider it, it's amazing how rarely someone actually does.

Today, our reporting tools are much better than our access controls, so it's much easier for us to build a solution that will help create accountability than it is to enforce compliance by making it impossible to violate policy. Instead of spending lots of money on IT, trying to fit a square peg in a round hole by making cloud services act like old-school computers, why not focus that same energy on making sure employees know their responsibilities to protect data.

If employees know that they are not supposed to access HIPAA sensitive documents from home - and that you can tell when they have done so and will fire them for it - chances are very good that nobody will ever cross that line. The hard part is making sure there is a system in place that makes you aware if there is a problem, and that your employees know they're accountable too.

Plus side:

  • Simply modifying employee policy to allow remote access can be cheaper than any technical solution.
  • Having HR policies in place should probably be done anyway to make sure users understand their responsibilities.
  • While not the cheapest option, no or very little IT cost required compared to other options.
  • Provides maximum flexibility in unusual or unplanned situations.

Down side:

  • There are a few options for decent reporting, but not as many as we'd like.
  • Taking the time to audit usage can be just as taxing as blocking it.
  • By itself, this does nothing to prevent an account from being used improperly.

Option 3: Use ADFS

If you absolutely need to make sure that nobody can login to Office 365 from home, there's one absolutely foolproof way to go about it and that's to federate with an ADFS server located in your office. Then, all you need to do is not expose the ADFS server to the internet and your users will never be able to get to anything in Office 365 - period.

This is actually a "broken" version of a typical ADFS configuration, since usually most folks want to be able to allow access from home. We know it works, because when the power or internet goes down at the main office where ADFS is running, people working from home can't login.

Of course, if you absolutely need remote access, or some users need cloud access, you can configure a second DNS domain for them and not enable it for SSO. Without ADFS, this second domain and its users would use the regular login process for Office 365, and thus be able to get in from anywhere.

Unless you are such a small company that you can't afford to maintain a domain controller in your office, this may very well be the best solution for you. I'd be hesitant to recommend it to companies of less than 25 employees unless they have a very compelling reason, like HIPAA for example. It does take an experienced IT person to get it set up and correctly configured.

Plus side:

  • Well established solution; well documented.
  • ADFS comes free with Windows Server.
  • Absolutely effective as preventing outside access; if you don't want users outside your network, simply don't expose ADFS to the internet.
  • Flexible enough to work in a variety of scenarios.

Down side:

  • ADFS has a high technical debt.
  • Requires a Windows AD domain controller; many small companies would rather eliminate on-premises servers.
  • Adds to technical complexity, especially if you also have some cases where access to Office 365 from outside the network is allowed.
  • Doesn't readily distinguish between access to e-mail and documents, so you may need multiple accounts if you want to access some systems remotely but not others.

Option 4: Lock account based on login times using a script

It's possible to enable and disable logins using PowerShell. It's also possible to run PowerShell as a scheduled task in Windows. Both of these can be done from a workstation computer and do not need a server or other fancy hardware. Using PowerShell, you could "open the cloud store" in the morning and close it in the evening. In this case, nobody but you would be able to sign in unless you logged into the web site and overrode the settings.

This is a sort of weird scenario, really. I don't know very many people willing to go to these lengths to keep people out of Office 365 when they aren't at work. Also, then they wouldn't be able to check email either. It might have an application against a special-access account that only gets used during the day, like the one I talk about above in Option 1.

I probably should mention that if you go with Option 3 and use ADFS, it will automatically follow login times configured in Active Directory, making this totally unnecessary. So, unless your company is very small, I'd probably recommend doing that instead.

Plus side:

  • This can be run from any Windows machine, even a workstation
  • Can work even with Cloud Only users. No AD domain controller required.
  • Easy to automate based on a schedule.

Down side:

  • Prone to problems if the script fails to fully "open or close the store".
  • Not a good fit for people who need around the clock access, but only from certain locations - or other scenarios that are not strictly time based.
  • Will take extra time and effort to manage and support.
  • Doesn't distinguish at all between access to e-mail and documents.

Option 5: Tie Office 365 Multi-Factor Authentication to a device that's only available in the office.

This is a lot like not sharing the password for an account, except that really what you'd be doing is withholding the second layer of authentication. Since the second factor authentication may not come up all the time, this would be more transparent and thus less destructive to employee autonomy than not giving them their own password.

Here's how it works: create an account in Office 365 and configure a password to use while you set it up. Then, configure multi-factor authentication and enroll the user against a device that's only in the office, like a desk phone or their supervisor's cell phone. Once they are enrolled, reset their password to a temporary one and share that with the user so they can pick one of their own. Now, you've effectively prevented them from logging in at home, since it will be an unfamiliar device and network, which would trigger the MFA.

Before you count on this method, you might want to test it for yourself. There are different flavors of MFA in Office 365, and some of them only come with E3 / E5 / EMS plans. The enforcement options, triggers, behavior, and configurability may all be different if you're using the vanilla MFA that comes with a Business Premium plan, for example.

Plus side:

  • Allows people to know their own password.
  • Adapts well to contingencies such as having to arrive early / work late.
  • MFA settings can be configured per user and overridden as needed.

Down side:

  • Requires a cell phone or voice phone to be present in the office; Most people have a voice line though.
  • You can't let users self-enroll in this scenario.
  • Takes about 1 to 2 minutes longer to login to the system each time.
  • May require multiple accounts/licenses per user if some information needs to be controlled but other information does not. For example, if you need MFA for access to HIPAA sensitive documents, but not to e-mail.

Option 6: Customize SharePoint to Increase Security

Most folks who want to protect documents from their own employees are not actually interested in preventing them from accessing emails. But, most security solutions for Office 365 are applied against all the Office 365 services. If the documents you need to protect are in SharePoint, there may be better ways to go about this that wouldn’t impact other aspects of your service.

Of course, the ultimate solution would be to deploy CipherPoint Eclipse. You can think of that as the very best form of SharePoint customization there is, because it will let you encrypt documents and then use a variety of different policies to determine whether they can be decrypted. It's an expensive option, comparatively, but also a good one that offers true security (rather than security through obscurity). And now that I'm done plugging for our partner, I'll tell you about a slightly cheaper one.

Microsoft won't actually let us run server side code in SharePoint Online as they once did. So, our options are limited from being able to control the users access and experience on the site. Even so, it's not too difficult to do some rudimentary access control using JavaScript in the browser. For example, you can hide the page contents and display apocalyptic warnings instead. In some cases, you can also end a user's login session.

However, it is important to understand that code that works this way can be circumvented by those with a moderate amount of computer savvy. If you're going to rely on sleight of hand tricks to protect your information, you'd better also back it up with a clear employee policy, firm contractual agreement, audit logs, and regular reviews for bad behavior.

Plus side:

  • Significantly easier (and cheaper) than implementing security at the login prompt
  • Relatively easy to track both IP address and login time when using SharePoint.
  • Transparent to non-SharePoint Office 365 services, so if you're just trying to protect HIPAA documents, but still allow email access, this may be the way to go.

Down side:

  • To be fully effective, use of OneDrive sync and the SharePoint API will need to be blocked in sites that have sensitive documents, and this can limit how you customize SharePoint.
  • Requires documents to be stored in SharePoint. Other Office 365 services can't be protected this way.
  • Can be defeated by a determined intruder; many would say this does not offer true security but is more "security theatre".

Option 7: Encrypt It!

Most people don't need to protect literally everything they store in Office 365. Further, not everyone needs to protect what they store in SharePoint lists too, or implement complex policies to determine which employees should have access to what documents. Thus, solutions like CipherPoint that I mention above would probably be a bit heavy handed for most small businesses. (If you fit the above description, we'd still love to hear from you, because there's a lot more we can do in these cases.)

If your need to protect sensitive information is moderate and limited to a particular site, document library, or classification of content, then Microsoft's solution that comes with the E3 plan is probably good enough for you. I'm talking about Azure Rights Management, and while it won't keep an employee from viewing a document on their home computer, it can keep them from downloading it to their phone, printing it, or copying its contents to an email. Also, should the unfortunate need arise to fire their ass, it can also let you take access to that information away after the fact - no matter how many times or places they've copied that file.

While I wasn’t a huge fan or early versions of ARM, it has matured a lot. It's easier to set up now than it used it be, which is good if you don't have a huge budget for IT. Since it can be purchased a la carte, you can let Business Premium users access ARM protected documents when necessary, without having to upgrade them to the E3. (Unless you want to. I'm totally cool with upgrading if you want to. Have you met the E5?)

Plus Side:

  • Encrypted documents are useless, even if copied off the network
  • Even your IT admin (or Office 365 support partner, like us) can't read the encrypted document.
  • Easily restrict who can read or edit a document - as well as some other things they can do with it (e.g. print, copy/paste)
  • Access can be revoked after-the fact.
  • A good solution if you only have a sub-set of documents you need to protect.

Down Side:

  • While you can control a lot of access, that does not necessarily include when or where users are allowed to read or edit a document.
  • Doesn't protect SharePoint data stored in lists or web pages, OneNote Notebooks etc.
  • Azure Rights Management is only included in E3 plan and above.
  • Third party solutions such as CipherPoint can be costly.

Azure AD Premium

Before I go on, here's a few notes about Options 8, 9, and 10 below regarding leveraging Enterprise Mobility + Security, Azure AD Premium, and Azure Advanced Security. These were things I think apply in general to the entire suite that go beyond the specific applications I mention in my list.

  • There will be additional monthly costs for service, and you may need on-premises hardware too.
  • Some solutions are simple while others can be quite technically complex.
  • While there may be features we're not aware of yet, there really doesn't seem to be the kind of access control our customers have been looking for, particularly for end-users. (See Identity Protection and Privileged Account Management below.)
  • Many scenarios, especially AD Premium, don't have a large user base yet outside a few big orgs and aren't well proven especially for in smaller companies.

Option 8: Registered Devices and Workplace Join

This is Microsoft's solution for adding PCs and mobile devices into Azure AD. And it's not a bad fit if you're interested in Windows as a Service, Intune, and the like. Joining devices to Azure AD basically makes it possible to login to your "domain" even when you're out of the office. It can also, conversely be used to require users to login only from approved hardware.

Plus side:

  • Prevents users from working on unapproved hardware, such as personal computers.
  • Controls access by physical device; if you want to control access by location, don't let the physical device leave the desired location (e.g. use desktop computers not tablets)

Down sides:

  • This is a fairly complex deployment, possibly requiring help from experienced experts, and may not be suitable for small businesses.
  • Requires modern PCs (the Windows 8.1/10 scenario is better than Windows 7/8)
  • Requires a modern (2012 R2) Windows Active Directory domain controller
  • Requires configuration of ADFS server, which need to be accessible form the internet
  • Requires a license to Azure AD Premium
  • Relies on AD Connect / Sync so it can take quite a while for hardware info to be fully synchronized.
  • This solution can't really distinguish between user access to e-mail and user access to documents, so if you need mobile access to mail but not sensitive documents, this isn't your best option.

Option 9: Azure AD Premium w/ Identity Protection

I actually like this option a lot, because of its simplicity. It's not easy to take something as complex as access security and make it as easy to set up and manage as Identity Protection is - especially if you're Microsoft who seems to thrive on complexity and options. It's a really good system, and they've done a good job of providing a solution to help users deal with the identity theft threats that are becoming increasing common nowadays.

But - and I'll cook my hat and eat it if I ever say these words again - Microsoft may have gone a bit too far into easy-to-configure territory, because there are a lot of options missing from Identity Protection that I would've thought would be obvious.

For example, where's my option to say "my employees only work in the United States, and for that matter they're only in Maryland for the most part." Or, how about, "We really don't work later than 8pm EST, so could any midnight logins please be labelled 'high risk'?" Why not let the admin get a notification in addition to blocking access or triggering MFA? All these things were missing, and I was really surprised by that.

Otherwise, it's pretty good and you should totally buy it. Maybe they'll improve it later. If not, please see Option 11.

Learn More about Identity Protection from Microsoft's Blog

Side note: We had a case recently where a client has an employee who was being targeted by a cybercriminal who had taken their credit card data and was trying very hard to target their email account in Office 365 too. Fortunately, Microsoft was diligent in locking the account after many successive failed attempts. However, it is important to understand that information which may have helped to lead to an arrest in this case was not being captured until we activated Azure AD Premium and Identity Protection for the customer. If you're locked out of your Office 365 account and you have good reason to think it was because of a hacking attempt, I strongly suggest that you do not wait, but go ahead and start the free trial for AD Premium and turn on all Identity Protection's logging features. From there, if you simply want to protect yourself, you can set up MFA - or consider setting up a honey pot if you want to try and catch the would-be thief.

Plus side:

  • No local server required.
  • Can work even with Cloud Only users. No AD domain controller required.
  • Microsoft Add-on for Windows Azure AD Tenants
  • Remediate risk by requiring multi-factor authentication, force password updates, and/or blocking access entirely
  • Uses threat analytics which includes data from other Azure users, not just your own company
  • Protects from: sign in from infected devices, new/unfamiliar locations, impossible travel distances, anonymous IP addresses
  • Tracks leaked credentials
  • Doesn't seem to add much burden in the way of administrative overhead or management
  • Most of the MFA enrollment is intuitive (at least for an IT person) and can be self-service.

Down side:

  • We thought that MFA enrollment left too many steps and choices to the end users and should be something admins could lock down or simplify.
  • Conditional access risks are managed by Microsoft and divided into low/medium/high; there does not seem to be a way to define things such as normal working hours or normal location.
  • Has a tendency to throw false alarms in some networks; for example whenever we visit the Microsoft office in Washington DC, it tells us we're trying to login from Redmond, WA.
  • Although you can resolve an event or mark it as a false alarm, there didn't appear to be anyplace for an admin to leave notes explaining why the login occurred, like the situation we describe above.
  • Despite some marketing materials that seemed to indicate this would be available in EMS E3 plan, it still required applicable users to have Azure Active Directory Premium Plan 2, which is part of the EMS E5 plan.
  • None of these Azure security and logging features are enabled until you activate this service.
  • We had to actually sign up for Azure AD Premium trial offer in order to get the system to recognize our existing AD Premium licenses from Office 365.

Option 10: Azure AD Premium w/ Privileged Identity Management

Okay, I'm going to sum this up nicely. If you're a Microsoft Partner, like us, supporting Office 365 customers, or if you have more than 2 Global Administrators on your Office 365 account - for whatever reason - this solution is for you. Everybody else will probably find this to be either too expensive or much too cumbersome to justify. It really only protects your admin accounts, so in most cases you'd probably do just as well to just configure MFA on them and be done with it.

Learn More about Privileged Identity Management from Microsoft's Web Site

Plus side:

  • No local server required.
  • Can work even with Cloud Only users. No AD domain controller required.
  • Microsoft Add-on for Windows Azure AD Tenants
  • Allows Just-in-Time Access to high level (e.g. global admin) accounts
  • Monitor how privileged access is being used
  • Notify other system admins in real-time when privileged accounts are used
  • Uses threat analytics which includes data from other Azure users, not just your own company.
  • Seems to have some really cool reporting capabilities, but they take time to populate.
  • Really the only way that I am aware you can give someone global admin access to Azure or Office 365 and still keep an eye on and require them to justify their use.

Down side:

  • Adds extra login steps and technical debt for admins.
  • There is significant complexity involved for those who will need to manage and support PIM.
  • Doesn't seem to provide an option for who should receive alerts about usage.
  • Does not provide JIT access or monitoring for regular user accounts.
  • The ticket number formats are a bit restrictive.
  • Required applicable users to have Azure Active Directory Premium Plan 2, which is part of the EMS E5 plan.
  • We had to actually sign up for Azure AD Premium trial offer in order to get the system to recognize our existing AD Premium licenses from Office 365

Option 11: Beowulf Identity Server

I’ve talked plenty elsewhere about how awesome Beowulf is, how it shuts the front door on SharePoint, and how it protects your public facing web sites and applications from unwanted access. You don't need to hear even more of that from me here, so I'll stick to what we haven't said before. (Aw, c'mon. You didn't think I was going to spend all this time and energy writing a two part blog about security without promoting my own product, did you?)

We’re working on a version of Beowulf that works with SharePoint Online and the rest of Office 365, which shouldn't be terribly difficult since we already fully integrate with ADFS which is what Microsoft is using for access control in the cloud.

Since others seems to have dropped the ball on some of the options and features we've talked about here, we're doing our best to include them in the new version targeted for release in early 2017. Well, that's the big problem isn't it. Unless you want to be part of our early adopter program - and get a big discount for helping us test these new features - you're out of luck.

Lean More about Beowulf Identity Server on Liquid Mercury Solutions' Web Site

Plus side:

  • Low cost cloud based solution
  • Transparent access layer between users and Office 365
  • Can work even with Cloud Only users. No AD domain controller is required.
  • Can block access or alert you (but not block access) when a user logs in from unexpected locations or at unusual times.
  • Configurable in a lot of ways that Microsoft's solution is not.
  • Has many of the same MFA capabilities as Azure AD Premium.
  • Integrates well with Azure AD, ADFS, and other MS solutions.

Down side:

  • There is an additional cost outside of the Office 365 subscription
  • Like many advanced security products, set up is relatively complex.
  • Though many of these features are available today, our full feature set for the next release will not be available until early 2017.

Option 12: Application Layer Security Enabled Next Gen Web Proxy/Firewall

You all knew I'd bring it up eventually. Why don't you just go out and buy an F-5 Big IP with the Access Policy Manager module on it? Then you can come back to us and hire us to configure it for you, and we can totally freak out because people hardly ever want to do that. Even so, this is a nice way to go if you have a lot of money lying around, and burning it would be inconvenient.

For large enterprises with hybrid cloud/on-premises deployments, I do recommend products from vendors like F-5, Kemp, or Cisco. This goes triply so if you run a large corporation with name recognition, store a lot of confidential customer data that hackers may want to steal, or your everyday business is something that might lead people wearing Guy Fawkes masks to try to ruin your holiday weekend. They offer security features that Microsoft doesn't even come close to having in Azure yet, but you can absolutely deploy them as Azure VMs in your environment or on-premises as real metal or VM.

But then, if you're going to go that far, why not also make sure you do all the other things I talked about too?

Plus side:

  • Really, really, configurable and powerful; can probably do anything you'd want in terms of limiting and responding to access requests and use.
  • Deployable in traditional on-premises and cloud-based scenarios.

Down side:

  • Really, really, complex to configure and expensive to implement.
  • Even cloud based subscription versions are going to cost a pretty penny.
  • It will require dedicated staff and constant upkeep, so probably only suited to large enterprises.

As you can see, Microsoft offers many choices - but none of them is the perfect solution for everyone. Better solutions I think will emerge in the coming months. I hope I've done a little here to shed some light on what is sadly a very complex answer to what seems like it should be a simple question. The most important thing to consider I think is that there are some low-cost things that you can do if you want to control how people use cloud services, starting with making sure that your employees know the rules.

Technology is always changing, and it often forces us to consider scenarios that previously were just impossible. If you're considering Office 365 as a solution, you may have concerns about people having access from home (or anywhere in the world really).

Office 365 provides a lot of security advantages compared to storing sensitive data on your laptop computer, a portable hard drive, or that server in the closet. Keep in mind that this is just one potential risk in a sea of others that we've all faced for a long time; the benefits should outweigh the risks if you approach the transition to cloud services with a little bit of thought and planning. We're here to make sure you don't have to go it alone.

Did I leave something out of my list that you'd like to add? Leave a message in the comments and I’ll reply.

Thomas is an acknowledged expert on information security, the creator of Beowulf Identity Server, and spoke on the SharePoint Security panel November 8th at the First Annual FITSI.org Federal IT Security Conference. You can follow him on Twitter and LinkedIn - but if you really want to connect, your best bet is probably to call us at 410-633-5959.

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.