This post has been republished via RSS; it originally appeared at: Azure Active Directory Identity Blog articles.
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:
- Return to the Azure Active Directory Identity blog home
- Join the conversation on Twitter and LinkedIn
- Share product suggestions on the Azure Feedback Forum