Howdy folks,
Today we are starting the Conditional Access authentication context public preview. Authentication context allows apps to trigger policy enforcement when a user accesses sensitive data or actions, keeping users more productive and your sensitive resources secure.
We have added this capability for more granular policy targeting because of your feedback – let us know what you think!
Caleb Baker, from our PM team, will walk you through the details below.
Thanks,
Alex Simons
------------------------------------------------------------------------
Getting started with Conditional Access authentication context
Hey there, I am Caleb from the Azure AD team.
We've heard from many of you that you want to trigger a Conditional Access policy when sensitive content in your apps is accessed. This includes requiring multi-factor authentication, a compliant device or even GPS-based location. Existing app-level Conditional Access policies don't support this level of resource granularity, so we've added support for authentication contexts.
Now that Conditional Access authentication context is in public preview it’s great to be able to go deeper into some of the details. I can’t wait to see how people use it and integrate authentication context into their own apps.
You can modify your line of business apps, or, thanks to integration with Microsoft Cloud App Security (MCAS), Microsoft Information Protection (MIP), and SharePoint Online, use it with all kinds of cloud apps right away!
Let’s get started!
When you use authentication context, first you will create a custom authentication context value. This is how apps will trigger Conditional Access policies when sensitive data or actions are accessed.
You can do this from the new Conditional Access authentication context tab, and clicking New authentication context.
You’ll then provide a display name and description for the new authentication context. We recommend using a name that captures the authentication requirements. For example, Controls trusted devices or Contoso strong auth.
After creating a new authentication context, you then attach it to Conditional Access policies. These are the policies that will be enforced when an application triggers the authentication context. You author these policies in the Conditional Access policy admin UX, the same as any other Conditional Access policy. The only difference is that instead of assigning policy to a cloud app you’ll assign it to an authentication context.
Now that you’ve created an authentication context apps can make use of it. I’ll show an example with MCAS session policy, this will enforce policy when a user downloads a file from an app. MIP label management in the Office Security and Compliance Center has a similar experience for applying authentication context values.
Now when a user attempts to download a sensitive file from an app that is configured to use the MCAS session policy, they will need to satisfy the attached Conditional Access policy.
Here are some of the ways customers have been using authentication context with MCAS and SharePoint.
- Requiring users to authenticate with multi-factor authentication (MFA) when they download sensitive files from any SaaS app on the web, like Office 365, Salesforce, Workday, and more.
- Require terms of use for SharePoint site collections that have been classified as confidential. For several customers this allows them to move sensitive documents to secured sites in SharePoint online, and complete their migration from on-premises.
These documents will help you to learn more about configuring these policies.
- Configuring Conditional Access authentication context
- Microsoft Information Protection to protect sensitive SharePoint site collections
- Microsoft Cloud App Security session policy
Adding authentication context into your apps
Any app using OpenID Connect/OAuth 2.0 for authentication can also use authentication context values, including apps developed by your organization. This allows your apps to better protect sensitive resources, like high-value transactions or viewing employee personal data.
We’ve built this support on a standards-based pattern, commonly used by apps prompting for multi-factor authentication, to help simplify app integration. Of course, you can also use the Microsoft Authentication Library (MSAL) to further simplify app development.
Apps can trigger a specific authentication context value by using an OpenID Connect claim challenge, to request a specific authentication context claim value.
Once the user has been challenged and satisfied policy, they will be issued a new sign-in token containing the required authentication context claim. The app can then use the presence of the claim to grant access.
Here are some additional resources to help with app development, using authentication context.
- Authentication context developer guidance
- Authentication context developer sample app
- Authentication context MS Graph api documentation
Next, we’ll be working toward GA and adding support for even more integrations, like Privileged Identity Management role activation!
As always, we’d love to hear from you. Please let us know what you think in the comments below or on the Azure AD feedback forum.
Thanks,
Caleb Baker
Learn more about Microsoft identity:
- Return to the Azure Active Directory Identity blog home
- Join the conversation on Twitter and LinkedIn
- Share product suggestions on the Azure Feedback Forum