Deep Diver – Azure AD Conditional Access authentication context setup for custom apps and MS Cloud App Security

I am writing this blog mostly to highlight configuration steps and simple code examples of triggering authentication context for third party apps and Microsoft Cloud App Security – As always, I try to include background and references to give an idea what this feature is about before delving into configuration details.

💎 I believe Auth Context with Conditional Access will be one of the biggest Azure AD Features released this year; The examples I provide here are just scratching the surface, and I am eager to see what use-cases and implementations the community and MS peers will be coming up with! 💎

Table of contents

• Background
• Setup for your own app
  • Developer guidance article available @ msftdocs
  • Configuration for custom application
• Configuration for MS Cloud App Security and Azure Portal Action
• Ending words

Background

Step-up-authentication (Authentication context) enables variety of scenarios you can use to require further proof for actions or activities within the app. This is possible with the help of new policy target called ‘authentication context’ in Conditional Access Policies. Auth context is triggered by claims request (challenge), that the app can make towards the authorization endpoint of Azure AD.

In general there are three product use cases

• Require step-up authentication in Cloud App Security on action triggered by session policy

– Some of the coolest scenarios you can achieve with authentication context is to work with cloud app security session policies (demo in the article)

• Require step-up authentication in SharePoint Use Azure AD Conditional Access to protect labeled SharePoint sites

• Require step-up authentication in your own app
  • This scenario besides MCAS use case is explored in this article

There is also good overall article on techcommunity which I highly recommend

---

Setup for your own app

Reading the techcommunity article I referenced earlier I could see reference to OIDC specs, regarding requesting the "requesting specific Authentication Context Class Reference values" ref

So my first idea was to test the feature based on familiar claims request concept ref

 "acr": {"essential": true,
          "values": ["urn:mace:incommon:iap:silver",
                     "urn:mace:incommon:iap:bronze"]}

• I tried few familiar combinations:

var claims= {
    "id_token": {
        "acr": {
            essential: true,
            values: ["C1", "C2"]
        }
    }
}
var loginurl = `${authorization_endpoint}?client_id=${client_id}&redirect_uri=${rdr}&scope=openid profile offline_access&response_mode=form_post&response_type=id_token&acr_values=c1&nonce=${nonce}\n&claims=${JSON.stringify(st)}`

• But couldn’t figure out, why I was not triggering the Conditional Access Policy for Authentication Context

• Finally I decided to check the Cloud App Security Implementation to see, what is the right content for the claims requests object.
  • The trace from Cloud App Security revealed that value used for Authentication Context Class Reference is ”acrs”, instead of ”acr”
  • Below example from Cloud App Security Session Policy
    • {"id_token":{"acrs":{"essential":true, "values":["c1"]}}}

Developer guidance article available on ms docs

Only shortly after I had inspected MS cloud app security’s implementation, I did found there is excellent article for developer guidance already available https://docs.microsoft.com/en-us/azure/active-directory/develop/developer-guide-conditional-access-authentication-context – The article includes diagrams and especially information about the correct key for the acr attribute 😎…

There is also example code available for ToDo app

ms-identity-ca-auth-context/README.md at main · Azure-Samples/ms-identity-ca-auth-context (github.com)

---

Configuration example:

Configure Authentication Context Policies

I configured two policies for two Auth contexts:

• one for requiring trusted device (ACRS = C1)

• and second for requiring MFA (ACRS = C2)

Configuration for custom application

Example: Admin access page triggers claims challenge for policy that is tagged with MFA context to be required.

Example of the policy in action

• 

The application creates claims request param with acrs value =2 and sends the user to authorization endpoint, if it detects current session does not include required value in the token for acrs.

https://login.microsoftonline.com/a4ccfb0b-349b-4a25-8e12-8190f1331734/oauth2/v2.0/authorize?client_id=94a69b0e-6029-4517-af44-4850bf7e2d7c&redirect_uri=https://az.dewi.red/adminPanel&scope=openid profile offline_access&response_mode=form_post&response_type=id_token&nonce=yournonce
&claims={"id_token":{"acrs":{"essential":true,"values":["c2"]}}}

• Upon ’continue’ user is redirected to authorization endpoint where CA policy is triggered for the requested claims (c2 for MFA) and acceptance of TOS

Upon satisfying the request, the application validates the token, and inspects acrs claim value to be = 2

Configuration for MS Cloud App Security and Azure Portal Action

I created policy to highlight triggering of auth context evaluation on specific action (Such as Copy/Paste etc) on Azure Portal App.

This is very cool, and I am keen to test this with 3rd party integrations, or custom Oauth2 apps, at some point.

• AuthContext2 policy is the one configured in Cloud App Security

• The policy is then configured to be triggered on action on MCAS session policies

Example of the policy in action

• Admin is greeted by session monitoring notification

• Admin initiates copy paste from resource (Could be storage account key for example)

• But since the admin is not on trusted device, the step-up auth fails

• This also triggers alert in the Cloud App Security Portal

Ending words

Azure AD Conditional Access Authentication is great feature which helps to granularize access inside your own apps, and best of all in native Microsoft applications as well.

Reading the developer guidance I also noticed a recommendation ”Do not use auth context where the app itself is going to be a target of Conditional Access policies. ” I am not sure I understood the point of the article correctly, but I believe this is exactly one of the use cases, where your app might be covered by baseline CA policy, lets say requiring MFA, but some parts of the app you want to protect explicitly with trusted device or location condition. Nonetheless, I understand scenario where this effect of extra assurance can become redundant if the auth context and the baseline policy already cover the same requirement.

Developer guidance for Azure AD Conditional Access authentication context | Microsoft Docs ”