Blog Post

Microsoft Entra Blog
4 MIN READ

Granular Conditional Access for sensitive data and actions

Alex Weinert's avatar
Alex Weinert
Icon for Microsoft rankMicrosoft
Mar 08, 2021

Today I am excited to share how you can maximize user productivity AND protect your most sensitive resources with Conditional Access authentication context. Conditional Access is the Zero Trust control plane that allows you to target policies for access to all your apps – old or new, private or public, on prem or multi-cloud. And now, with Conditional Access authentication context, you can apply different policies within those apps.

 

I have asked Caleb Baker, a PM on the Identity team, to tell you more. Let us know what you think!

 

Alex Weinert

 

 

--------------------------

 

 

Hello! We are incredibly excited to introduce Conditional Access authentication context, because it really empowers you to apply policies in exactly the ways you’ve told us you want to. Your HR handbook and secret plans in SharePoint can have different access policies, and your company’s financials app can apply a different standard between reading balances and wiring funds.

 

 

Conditional Access authentication context lets you target policies for data and actions within an app so you can refine your Zero Trust policies for least privileged access while minimizing user friction.

 

With the public preview, which will start soon, we are adding support to several Microsoft services as well as support for SaaS apps and line-of-business apps:

 

Microsoft Cloud App Security (MCAS) file upload and download: Use the MCAS session proxy to trigger Conditional Access policy when files are uploaded or downloaded from a Microsoft application SaaS application or apps that use the Application Proxy in Azure Active Directory.

 

Azure AD Privileged Identity Management (PIM) role activation: When a user activates Azure AD or Azure roles, you can require Conditional Access policies like Azure AD multifactor authentication, third-party multi-factor authentication, device compliance, Azure Identity Protection risk levels, or location-based controls. This will make it more difficult for an attacker to act in a privileged role.

 

Microsoft Information Protection (MIP) labeled SharePoint site collections: Use MIP labels to identify sensitive SharePoint sites and apply Conditional Access policies so your organization’s most sensitive data is kept secure.

 

SaaS app integration: Conditional Access authentication context support is not just for Microsoft apps. SaaS apps can use the same approach to protect your data and actions. We’d like to thank SaaS app providers like LumApps and Powell Software for their help in validating the approach and showcasing how authentication context can be used by all apps.

 

Line-of-business apps: The same integration available to SaaS apps is there for your apps. Do you have sensitive employee data in your HR app, or need protection for high-value transactions? Conditional Access will help you add extra security.

 

Look for the public preview in April!

 

User experience

Here’s what a user sees when authentication context is used to protect an app resource. In this case, we’ll show the MCAS integration, but the user experience is similar in all cases. The user will need to accept terms of use before downloading classified files.

 

After signing into a cloud app, they are redirected to the MCAS session proxy. At this point, if there’s a Conditional Access policy applied to user sign-in, like multifactor authentication, the user will be prompted.

 

When they try to download a classified document, MCAS intercepts the click and displays a page to tell the user an additional security check is required.

 

 

 

A user clicks on Download PDF.

 

 

User receives a notification that additional security checks are required.

 

After clicking OK, Proceed, the user is prompted to agree to the organization’s terms of use, on a page triggered by authentication context.

 

 

Any app can use this functionality to require a Conditional Access authentication context and make use of the existing Conditional Access controls.

 

How it works

You may be curious about how this all works behind the scenes. It’s a familiar standards-based pattern that’s used when an app requires Azure AD multifactor authentication, except we’ve allowed the app to make a sign-in request that will trigger Conditional Access policy. After a user signs in, app controls if  additional policies need to be enforced. A redirect and new sign-in request is sent back to Azure AD, and the user is then prompted to complete any policy requirements. This way, the app can use its own business logic to trigger additional policies when needed.

 

 

The app or MCAS then inspects claims in the sign-in token to tell if the required authentication context and Conditional Access policies have been satisfied. If the required claim is present, the user will be granted access.

 

Protocol support is built on top of industry standards in OpenID Connect. authentication context reference value with the claims request parameter to give apps a way to trigger policy.

 

What’s next

We’re finalizing the details of the release and will get the public preview out soon. Then, we plan to extend support to more Microsoft apps and work with more SaaS apps. Our goal is to allow you to create more granular security policies, where you need them, and help move you forward on your Zero Trust journey.

 

We look forward to hearing your feedback and suggestions!

 

 

 

Learn more about Microsoft identity:

Updated Aug 19, 2021
Version 2.0
  • bart_vermeersch's avatar
    bart_vermeersch
    Steel Contributor
    Mar 14, 2021

     

    Would it be possible to explicitly request an MFA token even though the user is logged in on an AAD joined device (with a valid PRT)?

     

    The use case is as follows: when entering a critical (section of an) application we would like to be sure/confirm the user behind the keyboard is the user who is currently logged on to the device.

  • mikeburns7's avatar
    mikeburns7
    Copper Contributor
    Mar 09, 2021

    Azure AD Privileged Identity Management(PIM)role activation:When a user activates Azure AD or Azure roles, you can require Conditional Access policies likeAzure AD multifactor authentication, third-party multi-factor authentication, device compliance, Azure Identity Protection risk levels, or location-based controls. This will make it more difficult for an attacker to act in a privileged role.

    I do not see any Microsoft reference to third-party MFA being an option for PIM. 

    Alex Weinert - has this changed? If so, can you point me in the direction on how to configure this?

  • giladkeidar's avatar
    giladkeidar
    Brass Contributor
    Jun 13, 2021

    HI Alex Weinert

     

    Authentication context and PIM makes a lot of sense as you really can't reply on the initial token, you want to re-prompt for MFA when the user activate PIM (even if already verified with MFA in an earlier stage of the day).

     

    From your article I understand that it is possible to achieve that, but technically I couldn't found how, can you please share information regard that?

     

    the goal is to require MFA at the moment of PIM activation (regardless any other MFA user might satisfied earlier in its session)

  • Kjetil Smith's avatar
    Kjetil Smith
    Bronze Contributor
    Mar 09, 2021

    Hi Alex,

    Excellent and in the right direction; would love to add even some more possibilities. We are standing in front of a small paradigm shift; where agility, flexibility and maintainability are getting even more important; with even better advantages from the proper clouds: far better parallel execution, availability, traceability, security and of course AI/ML to better predict, extend, renew, report and learn.
    Your new model would also make it easier to dynamically rice the security level when systems are typically under attach; even by self-discovering with AI/ML tools under unspeculative behavior or under massive attacks or those often very difficult to discover and where you need a far larger time perspective to see it; eg from a region, on specific MFA devices or specific user or device groups. Soon also the callback, call through concepts and authentications chains should be improved.

    With the new capabilities that comes along with decentralized identity model we will extend it even further; it’s the beginning of a new period to better protect our western way of living, our democracy, more equal rights for living and protect against trafficking, human trading and identity theft.
    I just love some of the stuff; it will take some time for modern applications to adopt and we do need even some more magic to get old applications ready for it; but it doesn’t matter if it run in Azure, OnPrem, on any device or in different clouds. Though inside of Azure you will easier discover if anyone is stalking, hijacking, injecting, modifying or analyzing your applications.

    We have just got Mellissa onboard, so anything is possible. To day has been the day to celebrate women’s equal rights and we do also have the “SHE” conference going on.

    https://www.linkedin.com/posts/crayon-group_crayon-executive-among-norways-top-women-activity-6774641198683455488-rC4G

    https://news.microsoft.com/transform/how-one-microsoft-mom-inspired-health-care-companies-to-embrace-the-life-saving-potential-of-ai

    Best regards

    MrSmith