Microsoft 365 Community Identity platform, 5 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Get your Apps ready for Zero Trust – February 2023

Description

This month’s in-depth topic: Get your Apps ready for Zero Trust. Conditional access is the policy engine for zero trust architecture in Azure AD. It blocks or limits access to resources based on device information and other signals. Your app needs to send device information to Azure AD to fulfill the zero trust principle “verify explicitly”, which means using all data points for authentication and authorization. This session will teach you how to do that on various operating systems, browsers, native apps and brokers. Microsoft Presenter: Marcus Carvalho - Senior Product Manager (Microsoft) | @marcusca10. This call was hosted by Nandeesh Swami (Microsoft) | @Nandeesh_Swami on February 16, 2023.

Agenda
00:00 – Intro - Nandeesh Swami (Microsoft) | @Nandeesh_Swami
01:28 – Get your Apps ready for Zero Trust - Marcus Carvalho - Senior Product Manager (Microsoft) | @marcusca10
44:17 – Closing

Learn more
• See the full blog post for this call in the Microsoft 365 platform community blog - https://aka.ms/community/blog
• Microsoft 365 Unified Sample gallery - https://aka.ms/community/samples
• Microsoft 365 Platform Community in YouTube - https://aka.ms/community/videos
• Microsoft 365 Platform Community - http://aka.ms/community/home
• Mark your calendar for next call on March 16th at 9:00am PT. Download the recurrent invite for this call | https://aka.ms/IDDevCommunityCalendar

A

A

Like always, we have an exciting call today and uh we have our guest. Today is a colleague in my team Marcus carvalo. He is a senior PM in our team me and him uh work in the application and developer advocacy and awareness team. Like always, we have something called uh uh I mean we do something on apps apis sdks, something to do with Developers devops.

A

Today's topic is get your apps ready for zero trust, so some ground rules we're gonna record. This call and put it in our YouTube channel AK dot, Ms, slash, M365, PNP, slash videos. uh You can follow us on Twitter at myself, Microsoft 365 Dev, where you would see a lot of announcements of similar calls as well as on Azure ad. You can follow me on LinkedIn at Dundee Swami, and uh we do this community call every third Thursday of the month right like we have our next call coming up on uh March 16th.

A

So, uh let's be respectful. um You know, if you have any questions, feel free to put it in the chat, we'll be happy to take it up and we should be good to go yeah. So uh we will be sharing out surveys uh through the call. We would love to get your feedback on how the call is going on and how the series is going on in general. This really helps us uh put things into perspective now. It's time to hand it over to uh my dear colleague, Marcus thank.

B

You nanjish so uh I changed my shirt because then this show told me earlier today that I need to show off my my microphone. So I can look like Joe Hogan with a lot of hair, so I did it right so quick introduction, so I'm Marcus as Angie said I'm in the same team as him, so I work in uh in the application and development development cxp team.

B

uh So our one of the things we do is learn new things, so we learn things every day and we try to share these things with with people and we like to solve problems so and by solving problems. This is something that we're going to talk about, so we're going to talk about how applications can benefit from zero trust or how can you get into zero tracks? So we'll start with an introduction, so um you won't see any live demo, so some of you may be.

B

uh May you have joined the workshop we had earlier today that I was doing live demos with the risk of failing all the time, so this one will be recorded because of the complexity of the demos you will see. uh But everything is shared, so you can use source code look into everything that will happen. Let's start with zero trust, so understand what the different, what the definition that Microsoft gives to zero address. Actually, we may even update that slide because saying Microsoft definition of Xerox is probably not exactly Microsoft.

B

So if you look everywhere, you see more there's the same singers uh um over and over. So there are three pillars for uh for zero trusts. One is verify explicitly so um verify every every connection. Every request make sure that everything is uh is the service is working, it should be.

B

The the data is exactly the way that the data that you can access so make sure that every time you need to access to the data check that or authenticate and authorize everything, so other one use least privileged access, so always require the minimal uh permission for that action and assume Bridge. So you don't know where the resources is coming or the access is coming from.

B

uh So make sure that you understand that so that you can verify useless privilege and understand what are the actions that you need to do to minimize the the radius of the of the attacks or connections. So the key thing for one of these principles is conditional access right. So conditional access is the pillar of the essential feature we have that to cover the Never Trust, always verify premise so conditional with conditional access.

B

We will look into different signs of from from every connection and every time a user tries to get an access token or identify themselves. We will validate a conditional, uh the request against this rules or policies and Define what you can do with that. So we will allow access. We can enforce MFA. We can limit access, make the access, uh because that connection is a bit different. So let's reduce the amount to reduce the surface or the basic stuff block access. So we can do much more than just okay block access. Don't access anymore!

B

uh Okay, go home, don't do anything, you block it, so we can do more, so we can enforce MFA. Today we can even use something called authentication strands where we can Define what authentication method that we can use to get access to an application.

B

So one of the key things- and that's where our going so our our focus is more on the application and how the application would work with conditional access. Never trust always verify so. The first thing that we're going to do is understand how applications authenticate with Azure ID or any identity provider. So everything that we do is based on open uh on on authentication standards on Open Standards, so we use Sumo, WSFA WS trust. Openig connect was two, so all Protocols are just standard, uh Open, Standards and available to everyone.

B

We have different client application types, so we have web-based applications and that is key to what we're going to see next. So we have applications that will run uh server side, so applications that run on the server so things that a asp.natch this. This is applications where the code runs on the server, and this just renders a UI. So a web browser UI that you can play in a browser and then send data back.

B

So Java does that too there is some Taylor, some flat, some flavors of node.js, doing that, uh but these are becoming less and less popular. So the most popular model that we see today is single page applications where JavaScript runs on the browser. So the browser is intelligent. The browser runs the code and connects to a backend API.

B

So the browser is actually running everything. So everything runs on the client, nothing on the server or the browser just calls an API to get data and then renders the UI itself it doesn't require a server to render the UI another type of application that we have is actually native apps, so native apps can run on Windows, Mac or iOS Android doesn't matter can even be a console.

B

Device can be something that doesn't have a UI just have like a text interface that you can't type so these applications they will have different ways of logging, so the whole user authentication surface in Azure ID is web-based so you will render, will render IUI and that UI will be in a browser like window, so that browser like window can be system browser or the browser that is already running on the OS that we share the surface could be an embedded webview that is actually locked into your application. So it's just uh on that Universe.

B

It doesn't share anything outside your app or some applications. Do that can be a custom logo screen, not something we do with Azure AG, not something we recommend, because that will actually allow you allow other things to do so. It's the kind of thing that you type a username and a password, and then you authenticate to an application.

B

So if you do that, you will lose everything that we offer in terms of security in terms of in Azure, AG of authentication methods, passwordless and and these things uh and the console apps that I mentioned, or devices that are headlights that don't have like a browser or UI they use. There's a authorization flow, called device code flow that device code. 4 will actually just show a code and uh headless device and can be just a text interface and you can go on your phone or in your PC and authenticate that externally right.

B

So this is something that we can also do. So you don't even if there's something an iot device that doesn't have a IUI. It just shows a code, and then you can use that code to authenticate. So Microsoft facilitates all of this using msao. Although remember we're talking about Open Standards, so you're not bound to our libraries, but we have some flexibility, some some things that you will see as we go through that are unique to the library.

B

uh Some things that you can do with any Library, so insol or Microsoft authentication library, is the library that we develop and it's running they're all open source. They we have versions for the vast majority of popular form platforms, at least they are all there. So.Net JavaScript, Java python, Android iOS, a bunch of other things.

B

So let's look into how uh authentication the authentication authentication pattern is. So when you're writing an application, you actually try to authenticate your app. So you authenticate against Azure easy and you basically do two things because of the way the protocol Works, open, IG connects and os2 there's a concept of refresh token and tokens and we need to validate I mean sometimes or many times the user doesn't need to interact with the server to get a token. So that's the first. So the pattern is you always try to get a token silently try.

B

Whatever method you have to get an access token, so we can usually so Intel will search first for a valid access tokens. It already has. So it's still on the on the cache that are valid. So if this doesn't exist, you will try to use a refresh token. So all of this doesn't require any user interaction unless something goes wrong fails. So if user interaction is required, we fall back. So that's the way we work with the pattern, so we catch the error, so UI require reception.

B

That's the standard, MSR reception that Azure ID sends and MSL translates, knowing that the user needs to interface, and then we do what we call acquire token in interactively. So then we will show the browser window, the user will authenticate and then we'll move on right. So that's the process. You always try to get a token silently. If something fails, we fall back into the the UI.

B

So that is important, because every time you try to acquire a token uh conditional access will come to play and if something changes, remember um never trust always verify. If something goes wrong and it doesn't work anymore, conditional access will not allow you to get the token and that's when the error comes, and then you need to fix something to get a new token, so the silent will not selling token will not work. So that's why this pattern is important. It doesn't require to be installed. The vast majority of libraries will do something like that.

B

So this is basically uh the standard authentication pattern for for the protocol.

B

So the key thing about zero trust um is that you you today, you can't just rely on IP addresses or uh that your the users are running the application from inside your network. You don't know when they're, where they're coming from so you don't know if they are really hard who they say they are. So that's where the device comes to play. Device has a very, very important role when it comes to authentication and authorization. So there are a bunch of things you need to know.

B

There are three concepts in terms of device and, to be honest, we even we at Microsoft. We mess up with these names and create a lot of confusion, but I'll try to set up or to to make the logic on how these things work. So we have one scenario that we call hybrid, join the device. A hybrid joining device is a device that lives in two words. It lives on the on-premises words as part of the active directory on premises and it also lives in the cloud.

B

So it also it's also a machine that is rigged. It's known to Azure ID right, so that scenario actually is a variation of the on-premises one. At the end of the day, the machine is joined on premises. It's just extended to Azure, ID and Azure. Ag knows about that machine, so a hybrid join a device for Azure ID. We know that the device exists on both words, and you can even consider that you have some sort of on-premises management, more control on that device.

B

This is one point of dress, so the other scenario is what we call Azure ID joined device or Cloud join a device. So these are the names that you hear us using. So our Cloud joined device or Azure D join device lives only in the cloud. uh It doesn't know on-premises ad, so it's not part of the directory, but it doesn't mean that it can't access on-premises resources. That's a common mistake. A lot of people think that an Azure AG joined device cannot access Capital stuff.

B

It does that's not the context of our call, uh we're not enter into the details here, but the important thing is that a cloud join a device is a device that lives in the cloud. So ad on-premises doesn't know about that device. The other scenario we have is more common with mobile devices. uh That are that's what we call a register device or a workplace joining device. That was also the status for Windows 8 Windows 7.

B

They also had this workplace join sync, so a workplace to join a device is, is a no manager device right, it's a device that is known to Azure ID, but there's no management rule yet on it. We just astrology just knows about the device, it doesn't know what it does right or doesn't know where it came from someone registered that device and that device is known. So if you try to access an application using that known device, Azure AG knows about it, and then we can create rules based on that.

B

So all of these scenarios- they don't mean they I mean at any point. They mean that your device is compliant with any rules right. We just know that the device exists. We can use other things about it, but we don't know if they are have an antivirus. We don't know if they are, if you're following your own policies, that's where the MGM comes right.

B

So when an MGM comes or a mobile device, manager like intern doesn't need to be in tune, but when, when you have an MGM enabled so that will actually use the device register in Azure ID or the information that we have in Azure AG to notify Azure ID the status of the device, so the MDM, uh if it's not in tune there are Integrations via with the intern. That will allow that to do um not not getting to how it works.

B

We can do follow-ups on that, but the idea is that intern is the the API that any MDM will use to tell Azure ad that the device is compliant and we can use that in a rule later, an MGM manager device will be what we call a manager device or adding rode device. Okay. So these are the terms that we use everywhere.

B

So uh the idea here is to show you uh how these things show up uh show up for you on how you may see in the documentation um and understand what is the status of the object, so our hybrid join device and Azure D join device or a registered device. They are not managed. We just know what these devices are. The other thing about that is. That is the key information, because if you don't know what the device is, you can say it's compliant.

B

You can say that devices are supposed to be accessing your application right. So that is the basis of everything that we're going to talk in this in this session. So what we do, what condition our access can offer uh in terms of uh in terms of device, so this is the old stuff or in the past, Azure ID was only able to save via conditional access. Oh is the device compliant or is the device hybrid jointed? Only these two rules. This is the past, so you should not use that anymore.

B

We introduced it some time ago what we call device filtering, where you can use this and much more, so you can use um so think about now we know about the device. If you know about the device, we can use any attributes from this device to create rules. Based on that, so you can create rules from manufacturers. You can create rules from the operating system that they're running the version of the operating system. You can use trust type, so, oh, is it hybrid jointed? Is it a head registered?

B

Is it Cloud join, so you can use that there you can check if the device is compliant so is compliant. It's just an attribute there. So you say: oh if you want to create a rule that says that the device is compliance, you just create a device filter and use that you can use extension attributes. Imagine that you have kiosks that you want to to control the access, so you can use one of the extension attributes and say set an attribute saying this is a kiosk device or it this is a in our shared device.

B

You can use that or it's a dedicated workstation. You can use these attributes to extend the conditional access rules right. So this is very powerful and the key thing for your application, in terms of your application, is being able to tell that story to Azure detail this device's status to Azure ID, so that Azure ID can apply the rules and if it doesn't work, you see what happened during the demo.

B

Another important concept you need to know a mobile application management or map. Mem is a in our case in the case of azure. Id is actually applied by InTune and is not protecting the device is protecting the application itself. Mum requires the device to be registered but doesn't require the device to be managed all right. So we need to know the devices too, but we don't need to manage the device.

B

So if you look into that, you can protect the application like enforcing a pin controlling the sharing of data between applications, enabling uh you enable application via the InTune SDK. So this is nothing. This is a completely different story right. You need to download the internet. Sdk implement the internet. Sdk in your app, uh this is only available for IOS and Android. So I need that's an important thing. The device doesn't need to be enrolled in InTune or mem. There is a catch by the way uh in on Android to use Mom.

B

It requires you to install the company portal, but that's about libraries, so you don't need to re to register. You don't need to use the company portal at all, but you need the application installed because of the libraries right. So it's uh don't don't get confused in terms of oh, you need to register or you connect to internet. That's not the case. You just need the application sitting there. You just put the application on the mobile device and should be it.

B

You don't need anything anymore and when you're using mom conditional access work works on a different way. So there are two other options that you can apply right. So there are two options that you can use. So there's one that's called required, approved, client and another one is required. App protection policy when you use require approved client. That is actually a fixed list of application. There is a list of applications that is in the article there that will tell you what are the applications that are approved with clients.

B

That is not great, because it just means that the application can use man, but it doesn't. It doesn't mean that the application has any policy. It's been enforcing anything so think about that. This is like the outlooks, the teams or the words, so the office applications, so they are all in the approved Client List. But if you apply, if you check that box and use that box, it will not protect you're, not protecting the app. You just know that the app is capable of being protected.

B

So that's why we have the second option, so the second option requires not only the app to be approved but can also be applied to any application, even the ones you develop as soon as they have a policy applied, so the intern manager goes. There creates an application policy assigned a policy to your application and when you, whenever you open that application, that application will receive a policy so that status actually inside our chip data inside Azure ID, we can actually check okay you're connecting from an app that is protective.

B

So has the internet SDK and downloaded a policy and enforce it a policy, so it has I'm sure that it has a pin. It has uh uh I know it's blocking blocking copy and paste and stuff like that. There is a catch, the UI is misleading. So if you look into the UI, you see, the two check boxes are selected and the option down there says require one of the selected controls. That's actually not really true.

B

As soon as you select required application, protected application protection protection policy, any approved, Client app, will require a policy right. So if you use the first option alone good, if you check the second box, it doesn't matter what the application is. uh The applications that you develop or Microsoft applications or the approved list is not only Microsoft but the approved at least everyone needs to have a policy. So if you don't have a policy, even if it's word or if it's Outlook, they will be blocking right.

B

So you need to apply a policy, that's um kind of a side saying so a lot of a lot of application. A lot of developers look into the internet SDK to protect the application without needing to protect the device or being so so invasive and trying to uh to control the device of the user. That is uh the approach, in that case much more complex to implement on on compared to the things we're going to talk about today.

B

So now, let's start the demo part. So it's not like a it's like a big demo, I'm showing you. The goal here is to show you everything that happens in each one of the scenarios. So every time we have something or in a scenario, what will happen. So what? What is this structure? So, what's what are you going to see? There is a conditional access policy in place that conditional access policy is actually protecting our Cloud applications for selected users, so only the user that is running the demo.

B

So there is a device filter that excludes registered or jointed applications, so that kind of policy is not recommended. It's just for demo, demo purposes we're actually just showing okay. If the device is registered, if the Azure agent knows about that or if it is domain join it, we will allow them to access. Otherwise we will block access so, in other words, we're saying that only registered devices for selected users can access my applications. So that's it! What about the devices you will see in the demos?

B

So there is an iOS device that iOS device is registered so that device is registered using Microsoft authenticator app right. So inside authenticator the device registered to Azure ID Android same thing registered to authenticator app, so registration can happen using the InTune company portal, but that's not the case. The device that we're working here doesn't have the company portal. It's only a register, so it's the basic setup and on Windows we have on a Windows device that is azure, adjoined, no hybrid. So it's just connected.

B

It's a it's a Windows device that you log on with the cloud account perfectly fine corporate device that it does. That can be managed by InTune or not- that's not the case here. So it's just John.

B

So before we move on, there is one exception to the rule because of one of the demos the iOS device is actually enrolled into InTune, or so you understand why later, but it's related to the Apple Oso login SSO plugin. So you as we move on you understand the reason, but it's a decision you need to to make when, when you're, creating or working with your apps. So let's start with the first, uh the first scenario, so we have a web-based adopt right.

B

So it's a browser app and that browser app doesn't have anything special you're doing MSO uh you're doing a public library doesn't require anything Microsoft you're, just running a browser, application, uh JavaScript standard stuff right.

B

So what happens with these applications when, when they start to run on the devices, so the first device we're going to look, is Safari so Safari on iOS. You have this browser app. Remember our conditional access policy, uh then device tries to connect to the application and get success block it right. So you see that this is the screen that the user will see if they're trying to to access your application straight away, so that will not work so for the app for your application, your brow, your web browser application to work.

B

You require something called the Microsoft Enterprise SSO plugin for iOS part of the Microsoft authenticator app Remember to install the Microsoft authenticator app for the device registration that feature actually is based on the Apple extensible frame and Enterprise SSO. It's something that Apple developed and we just configure that on the iOS device and by configuring this this plugin. We will allow single sign up, so we will recognize the device and the device will be compliant. Okay, that is a catch.

B

So the only way to push that configuration into a device is by using an MDM right. So you need an MDM doesn't need to be in tune, but you need something to that. Will push that config or that configuration tell what is your domain? What's your tenant so tell that configuration to your device so that when Safari opens Safari is compatible to that the Enterprise's Apple Enterprises so and because that plugin is already configured, you will be able to do it to perform SSO to your application. So in terms of application, development, nothing is required.

B

Is an admin same, so the administrator will actually needs to set up to manage the device and ship the the Enterprise SSO plugin into iOS. What about Chrome Chrome is similar so same, but the user experience is different. So when you try to access an application that is protected, that requires device authentication in in Chrome. That's the first. The first screen is the one that you're going to see.

B

So there will be it's a misleading screen, so it will actually tells you, oh, uh you need to sell a certificate to move on, but there's no certificate, so you can't choose anything so that is the catch with scroll Chrome there there's something in Chrome called uh enable browser access, so we in Chrome you need to click click on a button that button is available in uh needs to be done manually. It's available on authenticator, app and also in the com into the company portal. Do you just go there after your device is registered?

B

You click on a button and that button installs the certificate you see on the second screenshot right. So now you have the device certificate and, unfortunately, that's the user experience in Chrome, so the user tries to sign in if it pops up select the certificate you click on allow and then you click on connect to the application.

B

uh If I'm not mistaken, that only happens once after you did the first time it stores that information and doesn't require again, but at least the first time the user will see the prompt for choosing the certificate, even if you only have one. Unfortunately, that's that's how it works.

B

What about Edge so Edge will work on every interface, so Edge works everywhere, so it doesn't matter. So, if you're trying to use Edge on Android on iOS uh that will and there's a small difference is just that uh on Android. It will force you to to register the device to sign in before you use Edge. If that happens, you know on iOS. You can browse anonymously and then you can sign in, but it's just like a user experience. Designing will happen after you. Sign in everything is fine.

B

The device information is sent to Azure ID and your application will work. What about Windows 10, so Windows 10 uh is a bit different, so Windows 10 has native support on edge right. So, if you're using Edge, we'll connect straight away, remember the scenario um our machine is cloud joined so because it's Cloud joined Edge is capable of understanding of interacting with the OS and doing what it needs to be. What needs to be done? An edge does single sign-on with device information.

B

Everything is fine if you're using other browsers, so Firefox enabled that support after version 91. So if you're using Firefox in a recent up version that will just work, Chrome requires an extension, so you need to install the Windows 10 accounts extension from Chrome web store.

B

um If you're an administrator, you can ship that, via condition uh I, don't know DPO, there's a registry key that Chrome's use to install extensions. The link there will give you the hints on how to do that. After you install the Chrome extension, it will work just like Edge and Firefox, so we'll just sign in to any application. The way it's supposed to do so these are the web scenarios. So from the developer perspective, there's nothing to do is uh is more on a miserchief scenario.

B

So, but you are as a developer, you need to understand the impacts of your choice right. So, if you're dealing with a with an administrator, if you're building an application to a company, that's using conditional access and reinforcing devices, you need to know what will happen and what tell to the administrator that they need to do. Chrome is a quite common scenario right, so you create an app your app works on edge and then someone calls you and say well, but I'm, trying, Chrome and Chrome is not working.

B

Well, you need to know that you need to install the extension on Chrome so that Chrome can do single sign-on and share the information uh of the device with Azure aging right. So that's the idea of this this section. The next section of this webinar is more focused on the native clients. So this is where the developer has choices. So in here you will understand what you need to do to make your application work correct.

B

So the first thing you need to know is about embedded web UI, so embedded web uis are blocked and lock it into your application. So it's not. They are not shared uh within the device. Let's run these videos and you see the user experience, so your user tries to authenticate. This is the simple app that we're using. We will choose to use embedded browser, so you will see on the switch screen switch. So the screen is the same. So you didn't leave the application right.

B

The whole screen is your application, but now, if you try to log in from there, it will fail right because embedded web UI cannot access or cannot talk about, cannot share the device information. So that's exactly what will happen. You try to connect your application and the access will be blocked. Remember the pattern that we talked in the beginning. You try silently silently fails. You fall back into UI, that's exactly what happened here. So we try remember our device is registered.

B

We do single sign-on, so we try to log in it failed and then we get back so you don't see the screen switch. You will see the difference now when we go to the system web UI. So if your application so is selecting to use the system browser, not an embedded browser and by the way this up, this application is using msol and in MSO you can choose which one to use the default system web right. So the default is the one that works.

B

It's not the one that doesn't work but works, but we need to be careful. I'll just run the video and keep on talking about what's happening here. So we're going to use the system browser. You will see the application switch right. So that's the user experience. You see this. The switch now you're seeing the browser opening so you're, not on your application anymore, and you try to access the application and it fails right why you fails because the browser is the browser that you saw in the previous part, the previous section of the the web.

B

So if the browser is not configured correctly, your application will also fail. So what we need to do for an application that is running on iOS that uses the system browser to work. Remember Enterprise, SSO plugin. Without the plugin, your app will not work. What needs to happen on Android. You need to click on that button. Enable browser access. If you don't enable the browser access, your browser cannot authenticate. So your application cannot also authenticate too right. So now we rely on the browser. That's why we started with the browser.

B

So if you understand how the browser works, you understand why your app is not working and that's painful. Let's keep on going is Mario two more scenarios before we fix everything, so this is Windows. Uwp uwp is a PC because it doesn't use system browser at all. So you can't use system browser with uh with uwps you're limited to using better than web UI, and guess what you already know about the browser saying about how browsers work, what you expect that will happen here. It will not work.

B

So you see everything, that's already bad news, because the application already asked it for a username. Remember this is a domain jointed machine, though you should have single sign-on. So the fact that it required a user authentication was bad news. Now it's doing the whole passwordless authentication scenario: passwordless will work, so you will authenticate to to the user authenticates you see, authentication pass it bang. You cannot do anything.

B

You cannot access this right now, so that message is because we're using the embedded web UI- and we know now that the embedded web browser cannot talk about device information so that application will not work right or not on this way. So nothing that you saw here till now is a dead end. So there is a solution, we'll talk about in a minute, so now I'm telling you everything that doesn't work so that you can choose correctly and understand why the app doesn't work quite common.

B

So that's where I started talking about so quite common with Windows developers. So if you have an application that is created on premises, so this is not a vwp. This is a regular Windows application. A regular Windows application can perform what we know as Windows integrated Windows application, cables and tlm this kind of things. So, although you will have single sign-on, so the application will actually authenticate.

B

So you will say that uh you can select integrated application. We can click on login, but that will actually fail because integrated Windows authentication is purely on premises right. It doesn't use Azure ID. So what happens? Remember the pattern from MSO uses. Try silence. Iwa is actually a silent method, so it doesn't need a UI. It tries silent, it fails a UI interaction required and then, when you go to the interactive logo, it shows you the browser so that application works.

B

I can tell you so if I disable the conditional access policy, it will do single sign-off, but whenever the conditional access policy that requires device information is started, your access is blocking. So your single sign-on will not work. So it will be you you need to see. We need something else right, so I hope it's very clear to you. What happens in this thunder scenarios. So all of this is a standard. It doesn't require exactly MSL. As a library, so that could work with any library that just supports the browser.

B

What we're going to talk about is something that is more specific to Amazon, something we have to fix all of this and we'll have the we give the best user experience compared with any any other thing you already saw. So we have the complex the concept of what we call authentication Brokers, so Brokers are actually an application that will run on your device or a model. Let's, let's call it a Model A model that runs under your device and that model will take care of the authentication part.

B

So your application will actually relay the request, the authentication request to that model or in the browser or to the broker. Let's say this way and the broker will do the authentication for you. The application will receive back whatever it's needed, so on iOS the broker is part of authenticator, so you install authenticator. Remember you register your device, you get a broker, so the broker knows about the device and that will just work just a difference in terms of the radio I. The operating system works in iOS.

B

The the broker actually Returns the access token and the refresh token to the app on Android. We have two Brokers and that's also leading to confusion. It's the same broker, but it can be installed via the authenticator app or via the company portal. You don't need both. One of them is good enough. Whoever installed first will be the active broker. So if you install an authenticator app and then you install the company portal, the broker in use will be the authenticator one.

B

So if you installed on the other way around, so if you install company portal first, you will see you and then after the install authenticator app, the brokering news will be the company port. That is tricky because sometimes you want to look into the authenticator app and you just don't see any user account. But that's because the brokering uses the company portal and the company portal doesn't need to be logged in by the way you don't need to to register on the company portal.

B

Just install the company portal will install the broker and then the device can be registered and do everything. So you don't even need to sign into the company portal, you just need to install it and that will do it different in sound level asking for other OS implementation in Android. You only have the the access token I should have triggered the video. So you see, how is the user experience there? You go so the application you select to use the broker.

B

You click on login, you see the application switch, but now the application switch is on Authenticator right. So you don't switch to the browser anymore. You switch to authenticator, you do the whole authenticator settings security settings. You will be able to authenticate. So you see that we didn't type password that was single sign-on with Device authentication. We went just to the broker to select from the account, so we could perform single signal. So straightforward you, the user, sees the switch, but it's pretty quick.

B

What about Windows so Windows also has a broker, so nothing is lost in Windows. So Windows has something window. Windows doesn't need an application, so it's built-in, so the broker on Windows is called Web account manager or one one is part of the operating system and for any Cloud joined device or hybrid join a device. They are actually using One automatically. So that's why the browser, when you, when we're talking about browsers on Windows, uh just work it because the browser relies on the one.

B

So when you open the browser and then you try to log onto your application, one takes comes to play and then authenticates the device so tells Azure ID about your device. And then you can do single sign-on and use your device information, so everything works. So how do we use that in your application? We need to use msol or Implement. Wemo indirectly will be a bit more difficult, but everything is baked up in install you just select one click on the button. The best experience compared to anything else. You saw just click on a button.

B

The access token is there. So there's nothing to do so. You just say use the broker. Obviously you need to configure hair direct URLs, but you have. We have all the documentation for that. Oh it's, not the purpose of the call here, but it's just to show you that that is possible. So it's the easiest, the best user experience. So we have layer a Windows application, Windows native application. That would also work for embedded for everything if you just choose to use the broker by the way.

B

The code is the same on all platforms, so it's just an option called use broker and that will actually do you don't need to change the code if you're using iOS, Android or Windows there's one platform missing. That is Mac OS for Mac OS. We don't have a demo, but let's just walk through it and explain how it works. Micros is a bit different from everything that we talked about so far.

B

Mac OS doesn't have a broker right, so there's no broker for that, but we we do have the same Enterprise SSO plugin that we have for iOS. We do have on Mac OS, but this is actually installed via the intern company portal right. So you install InTune company portal on your Mac OS, you log into the company portal. In the InTune company portal and that will register the device, the problem is that we will actually not make everything work so because of the Enterprises so plugin. You need to configure that via NDM.

B

You will need to enroll the device not only about device registration. Obviously, there's we have a partnership with jams. Jamf can push that through windtune, so that will also work so InTune gems just configure they will. They can configure the company portal configure the Enterprise SSO plugin and your application will be able to do everything as you should right, but that needs to be done via MDM. So without an MDM, let's say it should not. Work should not because I'll show something on the next slide, so with Mac OS.

B

There is one important thing, because there is no broker. You can't do single sign-on, but the fact that you use the company portal to register the device not in row will actually install the device certificate into keychain in applications we'll be able to use device authentication by using keychain. So the user may see the prompts the keychain prompt, because we want to read a certificate and that will work. There is a catch.

B

We are working, you know in um in moving forward and not making that possible anymore and you need to to use the Enterprise SSO plugin, because we registration doesn't mean much it's just like we're accessing. We don't know much about your device, so that will actually change in the future.

B

So beware that this may work, but you should not rely on that going uh going forward, so try to go back fall back into the into the Enterprises, so plugin, that's the way to go all right so with that we actually reach it kind of the end of the session. So quick, summary authentication endpoint will send back HTML and JavaScript right, so it will go through the interaction the browser will be will will render the UI into the browser itself for the web control.

B

That's where you saw in all demos uh and advantages that we do have for that, so password, never stored by the application. Will you see all you'll be able to use passwordless methods, all the hit directions for devices and everything will run you have full support for conditional access. Users can change password when they are expired, so that web experience can change the UI you have branding.

B

You can change logo images, even the layout with the new features were just released, so you can change the whole CSS for the login page users can just can do all the the content experience through the web UI. So if consent is required, will not block your application from work and fully supports B2B accounts. One of the demos was a bit quick, but one of the demos that you saw was actually using uh a guest account right. So this is a table.

B

You get the deck, so this is a summary from everything that that we tested. So what scenarios work? What doesn't work in each one of these? The things that you saw you can check that table later without any problem, and if you want to try yourself these two applications that we're running on the demo. They are available on GitHub, so you can just take it configure and use it. So you can try it on your own run.

B

Your demos test conditional access on all scenarios you can choose which method to use and then just make it to make sure that uh the application work with that we're going to use our like last minutes for questions right. Yes, yes, it's a lot of content to try to make it as possibly good.

A

Yes, there were some questions on the chat and uh I see. Kyle has answered and as well as Mukesh, so another request, please, uh you know, go to this link and fill in the survey for us. This really helps us guard uh the current sessions and plan out the upcoming sessions. uh We we have recorded this video. As you can see it's going to be put into the YouTube channel, AKA dot, Ms, slash, M365, PNP, slash videos go ahead and subscribe. uh You can follow me on LinkedIn at nandi. Swami.

A

To get updates on latest calls events hackathons that we do on identity platform. Our next call uh is gonna, be on March 16th uh same time. uh We are designing and planning something cool and interesting uh stay tuned. As always, you can just follow up. If you have any questions offline as well, here is my email ID. You can just send out an email and happy to uh you know, Loop in with Marcus or any other experts that uh that are required.

A

uh Based on your question, thanks a lot for joining everyone uh see you in the next one have a good time weekend thanks everyone bye foreign.