Using Authentication Context with Azure AD Conditional Access Policies to Secure Access to Sensitive SharePoint Content

In recent Microsoft 365 implementation projects, one question always appears in the requirements: using Azure AD conditional access policies, can we create a condition so that certain users can only access certain parts of Microsoft 365? I wish the answer were yes, but unfortunately, it’s not possible. Today, conditional access policies can restrict access to Microsoft 365 workloads but not to specific objects within a workload, such as individual mailboxes or SharePoint sites. Microsoft released a preview feature called Authentication Context back in June 2021 as part of the conditions that Conditional Access policies can enforce for SharePoint Online sites. This feature, however, is a Microsoft 365 E5-specific feature. Let’s do a quick walkthrough of this feature and understand how it helps satisfy customer concerns.

What is Authentication Context?

I always like to describe Authentication Context as a tag you can apply to Microsoft 365 objects. Currently, you can only apply it to SharePoint Online sites. Once you apply an Authentication Context to the site, you can then have conditional access policies use the context to control access to the SharePoint site.

Figure 1 depicts how the Authentication Context works with conditional access policies.

In a nutshell, the Authentication Context is like a tag applied to securable objects (SharePoint site) and recognized by the Conditional Access Policy as a condition to support administrators in defining different sets of objects in different Microsoft 365 workloads.

Authentication Context allows organizations to achieve granular control over different objects for different parts of Microsoft 365. I will later explain how we can do that.

To add an authentication context, you must first go to Azure AD’s Conditional Access configuration section. Simply add an authentication context and make sure you select to publish to apps, as seen in Figure 2. Without publish to apps enabled, the authentication context will not be visible in other parts of the admin portal, like the Sensitivity Label Wizard.

How to Apply Authentication Context?

Before using an authentication context with a conditional access policy, we must tag the SharePoint site with the Authentication Context. Currently, there are two ways to apply the Authentication Context to SharePoint Sites, which are:

1. Use a container management Label.
2. Use PowerShell to apply the Authentication Context directly.

I always recommend going with the Sensitivity Label method, as that allows the organization to apply multiple settings to the target container at one time. Among the other settings we can apply via Container Management Labels at the SharePoint site or Team levels are:

• External User Access
• M365 Groups Privacy Setting (i.e., public or private team)
• Sharing Options

A container management label with an authentication context defined helps to apply the authentication context to the site assigned with the label.

What if there are some SharePoint sites in which you cannot apply labels, but you still want to control the access using authentication context? Microsoft also provides a way to apply an authentication context to a site using PowerShell. This method uses the Set-SPOSite cmdlet from the SharePoint Online management module to apply an authentication context to a SharePoint site. Here is an example of the PowerShell command:

Set-SPOSite -Identity https://<your tenant>.sharepoint.com/sites/demo1 -ConditionalAccessPolicy AuthenticationContext -AuthenticationContextName "<authentication context name>"

The last step is to create a conditional access policy like the other conditional access policy policies, but we use the Authentication Context as a condition instead of an App. Figure 4 is an example of the policy configurations.

How to use Authentication Context in the real world?

Now that we have discussed how to apply Authentication Context through conditional access policies, let’s discuss some real-world use cases.  In a recent project, we set up two authentication contexts:

1. Internal Use Only – SharePoint/Team site with this authentication context can only be used within the client’s network.
2. Allow External Access – SharePoint/Team site with this authentication context can be used by external users with added security checks.

We then configured two conditional access policies with the following settings:

1. Policy 1
   1. Conditions -> Locations – exclude office network IP range
   1. Cloud apps or actions -> Authentication Context: Internal Use Only
   1. Conditions > Locations  – exclude office network IP range
   2. Cloud apps or actions  > Authentication Context: Internal Use Only
   3. Access Controls > Block Access
2. Policy 2
   1. Cloud apps or actions > Authentication Context: Allow External Access
   2. Access Controls > Grant Access and require MFA
   3. Session > enable Use Conditional Access App Controls

This allows some sites to be accessible by partners and customers yet restrict others to internal users.

Preview Limitations

Everything looks great, right? Those who have worked with different technologies long enough will know there is always a catch. The same applies to support for Authentication Context since it is still in preview. However, Microsoft documents a comprehensive list of limitations, which you can find here.

Authentication Context is a Great Feature, but…

At the beginning of this article, I mentioned that almost all my clients asked for the ability to restrict access to the SharePoint site on a granular basis. My team and I tested out this feature with a client, but we didn’t deploy it in production. Why? The key reason is that some of the limitations blocked the adoption of this feature. Two key points prevented my client from deploying authentication context in production:

• Workflows that use Power Apps or Power Automate fail to work for sites with an authentication context, as Power Apps and Power Automate fail to grant access to the SharePoint site
• Teams private channel won’t provision a SharePoint site if the main team site has an authentication context as Teams client is prevented to access the SharePoint site to create the subsite for private channels.

I believe that 90% of my clients will hit one or more limitations. Therefore, we can only wait and see how Microsoft develops the authentication context feature to address its current limitation. Until then, I might not recommend this feature for deployment in my projects.