Understanding Azure AD Conditional Access Authentication Contexts

hello and welcome this session is about authentication context an application can use authentication contacts to trigger the evaluation of azure ad conditional access policy this allows the policy to match the requirements for individual components of an app for instance a website could require MFA or terms of use to be agreed when a particular page is accessed authentication contacts are also used for protected actions which is a new feature that has just gone into public preview keep watching and I'll show you how authentication contacts work for custom apps SharePoint and protected actions don't forget to subscribe and keep learning click the Bell to keep up to date come with me into the cloud let's start by reminding ourselves how we actually authenticate to an application so I have my application and would call this application a uh we have our user and we also have the browser that we're using and the user is going to go to the application using the application URL and the user could have already been authenticated to the app and in which case a cookie would be passed to prove that user's authentication but in our case we're going to say user is currently not authenticated so what the app will do is redirect the user up to Azure ad and we arrive at Azure ad and there's an authentication string that's sent up and that string is basically saying please authenticate the user to application a so step one we hit the app step two we get redirected up to azure now Azure needs the user to be authenticated so this will happen here so this is step three and we're going to auth the user and that authentication of the user will happen in whatever way is set up for that user so Cloud only user we use a username and password in the cloud it could be a hybrid user in which case we're using a username from on-prem probably the password is synced to the cloud using password hash synchronization and the user could be using authenticator app going passwordless using a 502 key and so on it really doesn't matter as your ad gets the user authenticated next job is are we going to issue a token to prove the user's authentication to application a and that's where conditional access evaluation can actually kick in and the question is are we going to allow the user to access application a and of course all the good things about conditional access kick in what's the user's location what's the device they're being used is the device compliant have the requirements for actually issuing a token been matched if the answer to all that is is yes then the next thing that will happen is we'll return a token back to the application and that could be an ID token in this particular case as in proof of authentication of the user to the application and that ID token will prove the users authenticated to the app at the same time as passing back the ID token there will be a cookie that comes back and that cookie will store in the browser and that is proof of the user's authentication to Azure ad so this solution allows evaluation of the user's access to the application let's just finish the numbering on here so one we hit the app two we're being redirected up to Azure saying please authenticate the user to application a three we authenticate the user to azir and four we're going to evaluate conditional access and five we're going to pass the token back and while and also the cookie allowing access to application a but of course the reality is that an awful lot of applications are made up of multiple components and if you've got a website it could have multiple Pages if it's SharePoint you could have multiple sites within SharePoint and each of those pages or sites might require different authorization so to access one page you might absolutely need MFA or you might need phishing resistant MFA to access another page you might need terms of use to be agreed so this page we go terms of use this page we want to have MFA now of course the application could sort of do its own terms of use and give back to terms of use get the agreement from the user and so on but wouldn't it be nice if we could bring that behavior for each of the individual components of the app in to conditional access and this is where the magic of authentication context kick in an authentication context is a particular claim that the app can request from Azure ad before the claim is issued CA policy can be evaluated are we going to issue this claim and the ca policy could require MFA CA policy could inquire terms of use to be agreed and that's all done before the claim is issued there are actually 25 authentication context claims that can be used and the claim name is acrs as in authentication context references and the claim values are C1 to c25 so let's go back to the previous we could have already authenticated the app and then we hit a particular page and what happens now and this is step two we're going to be redirected back up to azir and we'll send back the authentication string we will add on to this we'll say a c r s equals whatever number we want so let's say it's C two that's number two please authenticate this user to this application and give back an acrs claim with a value of C two so once again Azure ID is going to check the user's authenticated well this time what can happen is the cookie can be passed so it's seamless single sign-on the cookie just gets passed through already signed in CA evaluation we always do CA evaluation so is the user allowed to access the application and then what we do is we do are we going to issue the claim issue a c r s equals C2 question mark that is the question and the answer that is yes if that's good then what will happen is the ID token will be issued and inside that ID token we have the acrs equals C2 claim set inside the ID token and that's it really so the app is asking for a particular claim type that particular claim type will only be issued if the appropriate conditional access policy is satisfied now if there is no conditional access policy it's always satisfied so if there's no conditional access policy saying how C2 is to be issued or under what conditions C2 is to be issued then what will happen is the app will automatically get back the C2 claim now Microsoft have extended the use of authentication context to protected actions and we'll get into a demo of using authentication context for application access and then I will explain what protected actions are and how to set them up so let's get in to that demo okay I'm going to use my test app XTS oidc V2 and I'm going to request an ID token and I'm going to use code flow to do that so we're going to sign in as my user John and we've got a code back I'm going to convert the code token and if we have a look at this notice there is no acrs claim in here at all it's an ID token it's an ID token for my application and there's my client ID for the application and we're signed in as John Williams okay let's go back to the home page and let's this time when we sign in ask for a C1 authentication context claim value so I'm going to click on the link here and it's going to send me off again this time we've gone up to zero A.D we've got the authentication string and we're requesting this particular claim type I haven't had to sign in this time because it's automatically using the cookie that is held in the browser so I'm going to convert the code to token and I have an acrs claim let's look in Fiddler and what we can see in Fiddler is we've got an initial logon to azir so let's have a whoops let's choose the right one this one here and I'm going to copy that and I'm just going to go to the text Wizard and URL decoded okay so copy that and drop that in to notepad and we're going to go now and look at the second interaction that we had with azir which is this one and this is where we asked for the C1 claim value so once again select it into the text wizard URL decoded and drop it into Notepad okay and I'm not going to go into the details of these authentication strings what I want to do is point out the difference and in the second one we are actually asking for a claim to be added to the ID token the claim type is acrs which is shown there and the value is C1 so that's how we ask for this particular claim to be added to the ID token so let's now go to the enter portal and have a look at the authentication context defined so I'm going to go under protect and secure conditional access and the first thing is if we look at authentication context and what have I got I've got C1 and I've got C2 now normally you would have some sensible name but what I've done is I've actually chosen here to use the name as the same as the ID that is requested so when my app asks for a C1 value it's it's I've got the same name I like to minimize the levels of interaction in my test environment normally you'd have this as a sensible name such as you know if the policy that deals with the issuing of a C1 claim is going to do MFA you would call it MFA if it was going to deal with terms of use you would call it terms of use so let's just create a new one and I'm going to give it a example name all right and um it's C3 in this case of course I've got my C1 to 25 that I can select well I've already used C1 and C2 so it starts at C3 and I'm going to save that okay now if we go to the policies we can see that I got a policy defined here so when C2 is requested what I want is I want to do a terms of use for James Bond and John Williams when always okay so if we look at the details we've got specified users we've got James Bond and John Williams and we look at the C2 in here notice my example name has appeared as well and what's the grant the grant is terms of use okay let's um just enable this save that and let's just have a look at terms of use if you're not familiar with it now what the simplest way of looking at this actually is to look at new terms and I give it a name for this terms of use I upload a PDF file that actually contains the terms of use and then I've got things like require user to expand the terms of use to require user to look inside the PDF require user to consent on every device and so on so I can Define you know not only the terms of use document but also the interaction of the user with the terms of use okay let's go back again to um my conditional access and look at the policies and I've got another one in here which is a C1 policy which again is this for the same users and the authentication context here is C1 what do I want to happen I want to actually require multi-factor so I'm going to turn that on as well so I turned on two policies so let's go and actually have a look at that from the user experience now if we go back to my application remember I have a C1 claim I got it because there was no policy in place uh let's go back and request that again so I've gone home and I'm going to do a code flow C1 Authentication context and this time it's immediately prompting me for MFA so I'm going to approve that sign in and convert the code token and of course I have a C1 but this time my ability to get a C1 was gated by the fact that I had to do MFA Let's uh close that off and let's go to SharePoint and I'm going to go to SharePoint and I'm going to sign in as my user John and I've got access to the SharePoint site now what I want to do is go to a different site I want to go to the legal case law site click on that and I'm being asked to agree the terms of use so I can so look at my terms of use and then I can accept and now I'm in the legal case law site so that's an example of connect the authentication context used with a custom app but also used with SharePoint let's look a little bit more at SharePoint and I'm going to go back to well I've actually got the the portal in here for SharePoint and we'll go across and we'll go to my active sites and we'll look at the legal case law site and look at settings and what you can see is a sensitivity label that is using the C2 authentication context how do we get that sensitivity label we have to use purview now I said earlier that protected actions use authentication contacts and protected actions have just gone into public preview protect actions require a CA policy to be evaluated before a particular administrative role permission can be used for instance you might be a conditional access administrator and if the permission required to create a new ca policy is designated as a protected action you'll be required to satisfy a CA policy before you can create a new policy okay let's have a look at that so I'm going to go back to my intro portal and this time I'm going to choose roles and admins if I look at my roles and admins I've got this new protected actions tab here but first of all let's have a look at the there's a conditional access administrator and John is a conditional access administrator and therefore he will be able to create policies he will be able to edit policies and so on but I can add a protected action and so I go ADD protected actions and um I need to select permission that I want to protect and I'm going to choose access policy create so this is our conditional access policy create I'm going to protect that and how am I going to get it well I gate it using an authentication context so I'm going to get it using the C1 authentication content saying that you must do MFA before you can do this now of course um you know if this was a production environment of course I'd have already done MFA before I'm allowed to do anything in terms of administration but what I could have is a initial access policy that says you have to do phishing resistant MFA before you can actually do this action but for now I'm just going to leave that as C1 so I'm going to save that I'm going to go back to my other environment and I'm going to close that off I've had a few problems using the intra portal so I'm going to use the Azure portal I'm going to sign in as my user John and John for this demo has actually been enabled as a conditional access administrator so we'll go to conditional access so we're looking down here for security and we're going to go in here and look at our policies and I can go in as John and I can modify and edit the policy without a problem so I could add in someone in here remove someone Etc okay let's go back to the credential access page and click on create a new policy and this is the one is protected so here it says missing required claim so I'm going to click yes on that and it's prompting me for MFA so I'm going to put in my MFA in here and that should sign me in and allow me to create a new policy which it does thanks for watching this session now you know how applications and protected actions can trigger a particular Azure ad conditional access policy using authentication contacts don't forget to subscribe and keep learning and please click that Bell to receive notifications as my new videos become available I'll see you next time in the cloud thanks for watching my channel subscribe for more free training you might like to join me for my identity masterclass hopefully see you soon [Music]

Channel: John Craddock Identity and Access Training

Views: 1,800

Keywords: John Craddock Identity and Access Training, Azure AD, Identity, Microsoft Entra, Cloud, Deep-dive, Authentication Contexts, Protected Actions, John Craddock, John_Craddock

Id: BhZpj1y-ApA

Length: 22min 23sec (1343 seconds)

Published: Thu Jun 01 2023