Welcome back. This is the first episode of Montreuil five, where we're going to talk a little bit about authentication.
My objectives include taking a look at some authentication protocols, talking about what as your B to C is
understanding what APP registrations are and then jumping out to the azure portal to take a look at a demo of azure B to C and half registrations.
So to get us started, let's talk about what is authentication. I know it may seem like a pretty basic topic, but I want to go through and talk about a few things for it. Authentication is proving who you are by completing some type of challenge. Typically, providing a password to your identity or use her name
and usually associated with authentication is authorization and authorization is where this authenticated identity is then given access to do something like access a resource or make a change.
Authorization is what determines what you can do with data. Microsoft provides a platform for developers to implement authentication and their applications. This platform supports industry standard protocols like oh, off too, and open I d connect an additional open source libraries when using Microsoft as your identity platform in applications.
It's the identity providers responsibility to verify the users and the applications inside its directory
and then issues security tokens when the authentication is successful.
When using Microsoft as your identity provider, there are a couple of supported authentication types. The first is Web Service Federation or a typically abbreviated WS federation, or WS fed. This is used to enable identity, authentication and authorization across different trust realms
and a trust realm. It's just a set of authentication servers that is used to manage a set of unique identities.
So, for example, one realm could be azure active directory itself. So Ws Federation allows for user's to authenticate across different identity providers and is typically seen implemented with Active Directory Federation Service's or A D. F s. But it can be found in. Others do know, though, that Ws Fed is a little bit of an older protocol.
Our next one is open authentication or oh off,
and it's an industry standard for providing authorization to Resource is both defines the methods to obtain a user access token and then obtain access to the resource is on behalf of the resource owner Open I D Connect extends Oh off two by providing a method to provide information about the end user in an I D token.
This verified the user's identity but also provides basic profile information about the user.
Open I D Connect would be used in a Web application hosted on a server that has access via browser. Both go off and open I D Connect. Allow developers to authenticate to multiple Microsoft identities, including work or school accounts provided by as your i D
personal Microsoft accounts like outlook dot com or Xbox, or to social or local accounts through Azure 80 B to C or Business to consumer, which we'll talk about later than this episode.
Finally, we have Samel 2.0, which is used to exchange users authentication and authorization data between different systems using XML. Samuel works by taking the user's identity that's been verified by the identity provider and then transferring it to another system so user has already authenticated against their identity provider
then that is used to access another system.
Samuel is typically found in a single sign on scenario where the user does not need to type in their credentials again to access the system or application as your active directory uses the sample protocol to provide the single sign on experience for user's.
Now the less lied. I didn't mention azure be to see. So let's talk about that for a minute. As your B to C or business to consumer allows application developers to create applications where users can log into the service using their preferred identity. This could be anything from a social media account, enterprise or local identity.
Asher's be to see platform is scalable to support billions off authentication request every day and has built in monitoring capabilities
to protect against denial of service attacks, password spray or brute force attacks as your B to C can utilize authentication protocols like Open I D Connect Oath to and Samuel. And if you want to use as your B to see inside of your tenant, it requires creating a second directory inside of Azure to host the identities.
This is very similar how we created a second test directory in earlier episodes, and we're gonna cover how to create one inside this demo.
Next, let's talk about APP registration. If you're creating an application that requires authentication into azure, I D you're gonna need to create a nap. Registration Act Frustrations Allow an app to interact with Azure 80 on behalf of the user. This basically allows developers to create APS using Microsoft as the identity platform.
And inside the APPA registration, you can configure two types of credentials.
You can upload a client certificate or generate a client secret, which is like a username and password for the application that does it For some of our concepts. Let's jump out to the azure portal to create an azure, be to see directory and then also create an app registration
back here in our azure portal. Let's go create our azure. Be to see your resource first.
It was like to create a resource search for B to C.
And so, like azure active directory B to C
First, we need to create a new azure. Be to see tenant.
We need to give it an organization name
Once the directory is created, go ahead and select the Create new B to C Tenet or link to existing Tonight link up here,
we're gonna go back and link the existing Azure A D B. D. C. tenant to our azure subscription.
Here we can select the available tenants.
We're gonna associate it to our Azure standards description that we have and select a resource group. I don't have one right now, so let's go ahead and create a new one
and select the location
with our B to C directory created and associated with our subscription. Let's scroll down. Let's go to Azure Active Directory
will select Switch Directory.
You can see our default directory that we created when we created our trial tenant as well as our test one, but I don't see her be to see. So let's go ahead and refresh the whole browser.
Let's go back to switch directory
and after a refresh, weaken CR B to C tenant that we created right down here. Let's go into it real quick,
and you can see our B to see as your active directory looks a lot like our regular active directory
stuff of users, groups, rolls and administrators.
We have ability for custom domain names, company branding
and security with conditional access. An M. F. A.
Let's jump back to our default directory
back here in our default directory. We also want to take a look at AP registrations. So under manage, let's navigate to AP registrations.
We're going to create a new registration
and give our application a name,
and we have a couple options here for supported account types. This is basically who is going to be able to use the application or access the A P I.
The default option here is accounts only in this organizational directory, which is R A Z 300 Tech director. You've been working it all along?
No, they have the option to say inside of any organization. So this would be any azure, a D directory or in a multi tenant scenario,
and our third option is accounts in any organizational directory or using personal Microsoft accounts like a Skype or Xbox account.
Right now, we're just gonna stick with this organizational directory only
once a rap is created here in the overview page, we have quite a bit of information we need for the application. First, we have a client, I d. This is the I D that is going to be used inside the application in order to access Resource is inside our azure 80 tenant.
Let's go down to certificates and secrets.
This is where we can upload a certificate in order to prove the applications identity when requesting a token and trying to access. Resource is
we also have client secrets, which is basically an app, user name and password. Let's go and create a new client secret real quick.
We need to give it a description and then when it will expire one year to year or never.
Let's go ahead and add for just one year.
And here we have the description we just gave it. It expires in one year and then the value of our client secret.
And it's very important that once this pops up right here, you will need to copy this value as you're not going to see it again after you move away from this page.
So this client secret in conjunction with our client I D. That we saw in the over you page is what we'll use in our application to prove its identity when requesting a token and then going and accessing resource is
next. Let's check out a PR permissions.
This is basically the Russians that were authorizing this Web app to be able to call and use as part of the application.
For example, right now we have Microsoft Graf being able to sign in and read the user profile.
Let's go and add another permission.
Well, it's like Microsoft graph a p I
and we have two options here. We have delegated permissions, which means the application is gonna access the AP I as the signed in user to the application. Or we have application permissions where the application might run as a background service or Damon without a signed in user. I'm gonna choose application permissions because let's say my Web app is not gonna have a signed in user for it.
And then we have permissions we can assign
and we can allow this app registration read right. Access to all the calendars in the mail boxes inside our tenant.
Once our permissions have been granted for the a P. I.
You a little warning here to say Wait 10 seconds because then you have to grant admin consent for the A P I
and that Does it are Edmund Consent was completed for the requester depressions. We just added, And just to prove one thing about that app secret,
let's go back to certificates and secrets,
and you can see the value of rap Secret is now blanked out. So if you didn't copy down the first time, you're just gonna have to remove this one and create a new one that does it for our demo. Let's jump back to the slides and wrap this up.
That does it for this episode, talking about authentication and some identity topics coming up. Next, we're going to take a look at managed identities. See you in the next episode.