Identity in Azure with Christos Matskas

Episode #6 Published Wednesday, July 29, 2020

This week, I'm talking with Christos Matskas about Identity in Azure. We spoke about Azure Active Directory, (AAD), AAD B2C, Azure Key Vault, ASP.NET Identity Provider, Azure Managed Service Identities and the new Microsoft.Identity.Web that you can use to secure your applications.

This week, I'm talking with Christos Matskas about Identity in Azure. We spoke about Azure Active Directory, (AAD), AAD B2C, Azure Key Vault, ASP.NET Identity Provider, Azure Managed Service Identities and the new Microsoft.Identity.Web that you can use to secure your applications.

Christos Matskas is a software devoloper, dad, blogger, husband, speaker and all around geek. He currently works as a PM in Developer Advocacy for Microsoft Identity helping developers and teams leverage the power of Azure. Before joining Microsoft, he was a successfull entrepreuner collaborating with companies such as MarkIT, Lockheed Martin and Barclays. He's been building software for over 15 years and he's a passionate Open Source advocate. He contibutes regularly to numerous OSS projects and works closely with the developer community to make the space bigger and better. @christosmatskas

Show resources:

Full transcript:

Barry Luijbregts  0:23  

Welcome to another episode of developer weekly. This week, I'm talking with Christos Matskas about identity in Azure and other things. Christos works at Microsoft as a program manager for Microsoft identity. Welcome. How are you doing?

 

Christos Matskas  0:41  

I'm good. Thank you for having me.

 

Barry Luijbregts  0:45  

It's definitely my pleasure. You know, at the moment, I'm actually looking at my wife who is playing with my new Oculus quest device. You know, it's a VR headsets. I bought it yesterday. It's totally off topic, but it's so funny to see It's amazing. Have you  tried any VR?

 

Christos Matskas  1:04  

I've tried it a few times, I don't own any VR headsets or devices I would love to. But it means I would have to fork out a significant amount to upgrade my hardware and get the devices. I do have a PlayStation so I could get a VR headset for the PlayStation. But to be honest, these days, time is so limited. And sounds crazy because because of COVID and the pandemic, we're actually stalking the house. But it's a great opportunity for me to spend more time with the kids and the family and, you know, catching up with them. So no VR for me, but I would love to something I would definitely look into. So

 

Barry Luijbregts  1:42  

yeah, definitely. Well, we also don't have a lot a lot of time we just do it now here in this hour. We're sorry that before we go to bed, and I mean, this might be great

 

Christos Matskas  1:53  

to do a podcast on a VR environment, right? Oh, absolutely.

 

Barry Luijbregts  1:57  

Yeah, definitely. That would be awesome. This might be actually a great device because this is this is wireless. It's not even connected to PC right now. It's totally standalone. Yeah. That's why I wanted it because I don't have a big gaming PC or anything.

 

Christos Matskas  2:12  

So you don't need a beefy hardware to run it.

 

Barry Luijbregts  2:14  

Now you can do it, you can plug it into hardware, now you can run these amazing games and stuff, but you don't have to really

 

Christos Matskas  2:22  

so well. Something to look into then there you go. Definitely.

 

Barry Luijbregts  2:26  

Yeah, definitely. So well. So let's get to today's topic, and that is identity and identity in Azure. Let's say, let's just start with, you know, let's say I have an application, a web application. And I want to run that in Azure, because you know, I like to run things in Azure. Sure. How would I go about securing that? Because I have lots of options. I need ident I need to log in somewhere. And I need to make it secure. What are my options there?

 

Christos Matskas  2:54  

Well, again, security touches so many things like identity. So it's a it's available. big subject and maybe we need to scope it down a little bit from an authentication and authorization perspective, then Azure AD ease is a great solution. If you are trading line of business applications or business to business applications, then as rabies is a great solution, it provides you with a way to register your app, and then it gives you an app ID. And depending on the flow, sometimes you have a secret as well. And then you configure this in your application, you use their appropriate libraries, depending on which version of dotnet what kind of application of dotnet could be a console, it could be a web could be a demon, it could be an Azure function. All these different things have different kind of libraries to allow you to do the authentication. And then from that point onwards, once you're authenticated and you are authorized your users, you can add some additional functionality like calling into graph or calling into other API's and extending that and we have the Microsoft authentication library, Amazon these days, that allows you to do that quite easily. So you grab a token, right you get a token, that token has your permissions, your your user ID, your your API permissions as well. And then from that point onward all you do is send your token with your requests and based on your permissions can do things. So from authentication authorization perspective as radies a start for line of business. We also talked a little bit about b2c just prior to starting the show and business to consumer is for these people that are writing applications that are going to run outside the premise of an enterprise. So you know, you have your your podcast, your website, maybe you want to get people to authenticate to your website, and leave your comments or put requests to, to be on your show. In that scenario, you will be using something like BTC to allow these users to log in with their own username and password and maybe their social accounts, Facebook, Twitter, Google and then you have, again you get a token in your application and use that token to identify those users and give them appropriate permissions.

 

Barry Luijbregts  5:06  

Right. So let's see if I understand that we're talking about Azure Active Directory. And you can use that to authenticate users, but also to authorize users, right. And authorization means that you define roles or rights that they have, that you can then use in your application to say, hey, this guy is an administrator, for instance, or, yeah, power you too. And so he can see this menu and somebody else got right. And you will figure all that in Azure Active Directory, you just click some buttons included there.

 

Christos Matskas  5:37  

Correct? Yeah, I mean, we do have a straightforward process for creating roles. We can also use group assignments. So some sometimes if you are creating an application that is going to run against Azure AD for authentication, then you can also use the the group assignments or for a specific user to allocate permissions within your application. And the nice thing about ASP net and dotnet In general is the fact that they have a built in system for doing role based authentication. So once you assign a role to a user, then they get easily surface through the user object inside dotnet. And then all you have to do in your controllers is say, I want to authorize this user. So you only accept authenticated users in your solution. And then you say, I want to check on specific roles. And then as long as the user is within a set of roles that you permit in your app, then the user either has access or doesn't have access to a specific action.

 

Barry Luijbregts  6:32  

Right. And I want to dig into that a little bit more later, as well how you do that, let's say from ASP. NET, for instance, sure library using what what tax you do. So in Azure Active Directory, you then store your identities in there, that means you have the user object, including the password and everything is all in there, right as it takes care of all that.

 

Christos Matskas  6:52  

Yes, that's delegated authentication for you. So you don't have your application doesn't need to have a local database of users. It doesn't have to have a local database. So for roles and groups and permissions and what have you, so it becomes easier for enterprise that has hundreds or even thousands of applications to manage the users in one central location. And then the developers that create applications can use that centralized system to code around there permissions. So one of the one user can be in, say, invoicing or HR, then that user can access a set number of applications, but they won't have permissions to access other applications because they don't have the right roles or the right group assignments. And it becomes easier for developers to just focus on not adding quickly authentication to their solution. And then moving on to the next task, which be adding features to that application and specific functionality.

 

Barry Luijbregts  7:46  

Right. And then, once your user is in Azure Active Directory, they can then log in with, let's say, an email address and a password.

 

Christos Matskas  7:55  

Well, the nice thing about having Azure AD is if you are running an on premise, Sorry, on an enterprise environment means that you most likely get single sign on, right? So for us at Microsoft, we have so many applications, we'd only have to put a username and password, because of maybe everything that is part of the domain automatically has single sign on. At the same time, because we're using Azure AD, we also have incremental permissions. So if a specific application now needs to go and access my calendar, for example, then they can request that automatically for free for me, or on behalf of me when I try to access the application next time. They also have two factor authentication, you get all these things for free without the developers needing to explicitly code for these things. Right?

 

Barry Luijbregts  8:49  

Yeah, and that's a fun thing because you're then logged into your laptop, let's say with crystals, blah, [email protected] And during user object is [email protected] And then Therefore, you are already logged in there with the enterprise version of Azure Active Directory.

 

Christos Matskas  9:05  

Correct? Yeah, it's a it's an Azure AD joint machine. And that means that every time I tried to access any internet application, in fact, I can't even remember my password. Let's not say that. Because Hello

 

Barry Luijbregts  9:15  

is working so great.

 

Christos Matskas  9:17  

It's surprising if you go on holiday for an extensive time, like you have paternity leave or whatever and come back. Sometimes your passwords expire. And then nothing works. Because, you know, hello, and pins work so great that people don't have to use their 16 digit character, their password. But yeah, a funny too. I have a password, and I can use it.

 

Barry Luijbregts  9:38  

Yeah, right. And now you mean Windows Hello, where you just look into the camera, and it says, Hello, you're logged in now. Yeah, exactly.

 

Christos Matskas  9:45  

Yeah. And the applications can also leverage that as well. Right. So again, it can be Hello. It can be a pain, you can have feitos you can have hardware devices for two factor authentication. So it doesn't have to be username and password and the nice thing is that libraries that we have for dotnet. And node and everything else do support this kind of a, you have an app that tries to authenticate against Azure AD, we will give you all the things for free, doesn't matter where you come from.

 

Barry Luijbregts  10:12  

Alright, so can you then also store biometric data in Azure AD to login to let's say, fingerprints and stuff?

 

Christos Matskas  10:20  

I think no, you can do that. But it's your device that defines that as a the extra factor authentication, right. So if your device has a fingerprint, login, then that becomes part of your login process. And what we store in US release your object, your object for the domain,

 

Barry Luijbregts  10:41  

right? Yeah. So as your Active Directory b2c business to consumer, that's different, right? You don't log in with your ad Microsoft account with something else. How do you log in there? Correct. So

 

Christos Matskas  10:54  

Azure AD b2c, it's a separate resource to Azure AD. Totally. To imagine that you're spinning up a new website or a new database, it's not managed by Azure AD. So it's a totally different kind of authentication system. And the whole goal there is to make it easier for developers to manage and create an authentication system, an identity provider that is centralized again, but it's aimed for consumers and anyone that needs to log into a website that is not part of their ad domain or an enterprise. So if I go to say to Walmart and I want to buy something I need to create an account, then most likely, Walmart will have a b2c tenant that I create an account for the first time I can choose to use a social media account maybe I want to log in with my facebook so I don't have to go and create everything from scratch. Or I can use a an email and password. Sometimes the login process or the signup process, may ask for additional information like my my actual name Maybe my home address. So it will make easier for me to check out from normal without having to enter that information 20,000 times. So you can have the login system, but it also becomes a bit of a database and account database where you can enrich the information of the user. So you make the hauling that action easier.

 

Barry Luijbregts  12:18  

Right? And then you basically just store all the user information in Azure Active Directory b2c, right? You don't need an additional database for that per se.

 

Christos Matskas  12:27  

Exactly. Yes, everything is managed there. Again, delegated authentication. The nice thing about this stuff is like you don't have to worry about PII. Or how how do I allow my users to sign up for GDPR requirements, right, so maybe I want to delete my account. I don't want to be there anymore. It provides you with a straightforward process. And also, as a developer, you don't have to worry about how am I storing my passwords? How am I storing my emails? Are they secure enough? What happens if an attack takes place? Am I hashing the passwords appropriately? Why am I even hashing the password because we've seen many, many companies They're not storing information securely.

 

Barry Luijbregts  13:03  

Yeah, still people not having their passwords. Oh guy. Oh, yeah,

 

Christos Matskas  13:07  

yeah, I think if you follow Troy hunt, I don't know if you ever had his database he's Have I been poned database is growing exponentially with so many attacks taking place and I don't name companies but he's still advocate advocating loud enough for center center companies that are still getting it wrong. And they're storing passwords in clear text.

 

Barry Luijbregts  13:33  

Right? So yeah, Azure AD is a really good option, right? But there are a lot of issues. You can also use your own database like if an ASP. net website and I use ASP. NET forms authentication, that that was what it was called back in the day. I don't know what it's like to know,

 

Christos Matskas  13:53  

what's the identity provider for ASP. net and ASP. NET Core. So it's still a very valid service. Are you you might not want to use Azure AD for whatever reason, or maybe you're not running on the cloud, or you can run on the cloud yet. So we do have a template straight out of studio or the COI that allows you to create a local authentication system where you have an identity provider that runs against a local database, that database houses and protects your passwords. In fact, we added GDPR to our templates, as well. So if you go to manage your account, once you create your account in that system, also allows you to delete that automatically. So developers don't really have to worry about that. But you're still running a database locally. So that can always be an issue if you are quite aware and security aware. Also, it doesn't scale as well, right? So imagine you've had thousands or millions of users, suddenly your application needs to manage that. And the other problem there's a as a company, you're probably running an identity provider Anyway, you probably have somewhere an active directory that manages your organization three, right? So now you have two systems where you need to manage users. And you have to do systems you have to manage groups and roles and what have you. So it's not particularly would advise people to do that. It's not the best solution. But if you have a small kind of an app that you have 10 users or 100 users, and you don't expect it to grow significantly, then that's that's an option.

 

Barry Luijbregts  15:27  

Right? Yeah. I don't know. There's just something icky about storing passwords in a database, even though it's secure, and hash and everything. It's just once you can query it and concedes, I don't know, I don't get a good feeling about that. Let's be able to touch

 

Christos Matskas  15:42  

exactly and also the fact that your admins now need to backup the database, they need to manage the database, they don't have visibility about what's happening in that database. So you know, if you have 10 apps, that they all have their own databases back there, then you know, it becomes a little bit of a problem because companies grow over time. Sometimes developers are not aware of other systems. I've worked in very large companies like say, Barclays in the past, where there were so many disparate teams doing their own thing. And nobody talks to each other because it's hard to have visibility across everything, that everybody had their own kind of a system that was doing those duplicating functionality. So what I'm saying here is that if you decide to go down the route of self managing the the user database, then it might not scale well as the company grows,

 

Barry Luijbregts  16:31  

right. Plus, if you have your own database, you also need to have your own login page and own password reset page and all those things that those will be part of your application, right, where as you have as your ad, you will be pointed to the Microsoft login page, which is all secure and nicely buttoned up. You don't want to do all that stuff yourself,

 

Christos Matskas  16:51  

right? Yeah, in fact, I was looking at them. These

 

template builder allows you to because right now, if you create a new ASP net application or a snit core application and you say I want to have local authentication, it will create everything for you and but you won't see any pages, everything is actually part of a DLL. So you get a DLL that has everything compiled in there for you. So you get a sign in sign out, minus account, whatever that is all part of the dlo, there is an option to actually unravel all of that and have all these all these different pages, as actual pages in your application where you can tweak the look and feel you can change the design, you cannot additional functionality. It's about 25 pages because you have to have password resets you have to have email services, you have to if you want to send a password reset, for example, email, you have to have two factor authentication like right now you're starting to talk about I mean an email service and suddenly I need the texture which where I send the the the two factor authentication code and what have you. So it becomes very complex to start managing all this yourself, we give you all that for free. And even more like integrating two factor authentication to your office simple as going into Azure AD, flicking the switch and saying, you know, for this application, everybody needs to log in with Azure AD and have two factor authentication. So automatically your users do that. And they get the functionality out of the box. You don't have to have an email surveys and take surveys and what have you. I love that.

 

Barry Luijbregts  18:25  

Yeah, I love when other people do complicated stuff, especially with security because they don't want to be responsible for that.

 

Christos Matskas  18:33  

Yeah, leave that complexity to us. We give you a DLL. And that's all you have to do.

 

Barry Luijbregts  18:37  

So you talked about scalability as in, obviously, you can store millions and millions of user accounts in Azure AD. But what if you have users all around the world geographically distributed, what I would do with my application is I would put my application also near the users, maybe use something like Azure Traffic Manager or a CDN to make sure that my data is also close. What about Azure Active Directory? Because people then need to navigate to the Active Directory. Where is that physically located that surface? Well, we're we're doing all the hard work for you. So we make sure that we have instances all around the world. And what happens is when you try to log in, you'll be presented with a page, you don't you don't care where it's coming from. So because it's delegated authentication, you leave the website to go to another website, that's Azure AD, you do your authentication, and you come back with a token.

 

Christos Matskas  19:30  

You don't really care where that's happening. So you could have multiple that you have hundreds of instances running around the world. And we will make sure that the authentication is running flawlessly for you. You don't have to worry about scaling out Azure AD as well. We do it for you.

 

Barry Luijbregts  19:46  

Wow. So it's really identity as a service. Right?

 

Christos Matskas  19:49  

Yeah. And it scales with your with your needs, right. So you can have two users logging in can have hundreds of thousands of users logging in at the same time. You don't have to worry about performance. scalability backups. What have you. Yeah, I love

 

Barry Luijbregts  20:03  

that I, I once was, for one of my jobs. I was in Redmond at the Microsoft campus. And there we got like a customer tour of the security center

 

Christos Matskas  20:14  

that they have. I love that one.

 

Barry Luijbregts  20:16  

Yeah, that's Yeah, they have all these big screens with threats on there and botnets that Microsoft is tracking and trying to destroy with legal action and things like that. It's just amazing. And, and they're they explained as well, that's because they have so much data as an Azure Active Directory is being used so many, many millions and millions of times during the day, because everybody's logging into Outlook to Office 365 to Azure, you name it. So they have all this data. And because of that they can detect anomalies as well as if I log in from Amsterdam. And then a minute later, I log in from Australia, let's say then as your ad did. Hey, that's probably very strange. That's probably not right. But yes, up to level, maybe I'll ask for a second level of authentication, maybe you need to enter a code from your SMS or something or an email. That's just super clever. I love that.

 

Christos Matskas  21:15  

Yeah. And we had to scale significantly as, especially with COVID. And everybody's starting to work from home, we saw an explosion and on the usage of teams and the usage of Azure AD, we found that VPNs could not scale as fast as companies wanted to, you know, move hundreds of thousands or hundreds of 10s of thousands into working from home and suddenly, you know, a VPN that was working for 10 or 15 people at a time now has to manage that kind of load, which meant that we had to scale with these companies as well. And we did a lot of a lot. There's been a lot of engineering effort happening in the in the past years to make sure that we can scale with the world scaling at the same time. So you know, teams, as you said, teams are using as rabee everything Like, right now I have probably 10 different apps running on my machine, and all logged in against Azure AD. So you can see how that can take a toll from, you know, so many people working remotely, but we know we scale there were no issues, no outages, or whatever. And that's fantastic for my division to know that we're doing so. Well.

 

Barry Luijbregts  22:18  

Absolutely. And it's just really, really good work. So what about alternatives we've talked about, so you can have a database with the ASP. NET system. There's also third party things like there's identity server, which is also an identity product, also external, external identity store, right? corral is a different

 

Christos Matskas  22:40  

identity server is a great solution we've used in the past I've used in the past as well. I would say that for companies that cannot really leverage the clouds for an identity provider, then identity server is a lot better than running your own local database. Absolutely. And because they use the same kind of format where you know your questions A user logs in, they get your application get talking back and then get roles and permissions, it becomes very consistent. So if you eventually decide to move to the cloud, or if you eventually decide to move to say Azure AD, then it transition is easy. But I didn't say every something that you need to manage yourself, you runs somewhere on a VM or a machine or, you know, bare bones doesn't matter where it is, that the whole point there is that you point your application again to a delegated authentication provider. And then you get talking back that says that you have authenticated that these are your claims. And from that point onward, the developer needs to decide what to do with that user object.

 

Barry Luijbregts  23:39  

Right. So that would be a good option if you're not in Azure or on premises. But you also use as your Active Directory from let's say, if I'm using AWS.

 

Christos Matskas  23:49  

Absolutely, I mean, that's, that's why we are doing these days. We're talking to developers, normally care where you're running your solutions, whether they're on prem in Ws, Google Cloud, That what we want to make sure is that if you are going to authenticate your users, you need to use a robust solution. And if you're a no developer dotnet, Python Ruby go whatever language you're using, there is Azure AD for you on Azure AD b2c, right, let's not forget the business to consumer stuff.

 

Barry Luijbregts  24:20  

It's actually used a lot b2c,

 

Christos Matskas  24:23  

it is used quite a lot. And we've seen major customers implementing b2c. In effect, anytime that you need to interact with a consumer. You need to have a solution for that consumer to be able to login easily and efficiently and in a robust way that scales with your customer demand. Again, a reminder of these times is that with COVID, we had so many people that are moving to online shopping, right? People don't go to supermarkets anymore, don't do all the foods, they don't want to go and you know, eat at the restaurants or they choose to do take out or whatever all these companies that have had to deal with user registration. And you know, I want to go and buy something from Walmart again. So Walmart has to have a solution for for me to go and authenticate and prove who I am. So they can send the food to the right place. So you know that all of these customers need to have enough in identity provider.

 

BTC is a great solution. Yeah.

 

Barry Luijbregts  25:23  

So all right, we love Azure Active Directory. I love Azure, web apps and App Service. I love this is a great solution to just pop your application in there. And then it just runs. And obviously, we can connect our application with Azure Active Directory. Let's say I have an ASP. NET Core application. That means I need to do something to the application. But there is also another option in App Service as your app service. And that's called easy authentication and authorization. tells you a little bit about that.

 

Christos Matskas  25:53  

Yeah, easy. auth is an easy way for you to actually implement authentication for you application without really having to change your code. So for example, assuming that you have a 10 year old solution that you decided to move to the cloud, it's been running perfectly fine on prem. And you didn't have any problems there. But suddenly, you have to put in the public domain because your company decided to move everything to Azure. Suddenly, as soon as you put into App Service, that solution becomes publicly available, right? There's a public endpoint. Yeah. Now you want to ensure that anyone that access to that application has the right permissions or they're the right account. So easy. auth allows you to set up authentication without really having to change the code. So you deploy your code and suddenly you say, you know what, I need to authenticate my users. Easy. auth allows you to go and choose the options that work best for you. So we do provide Azure Active Directory backed up authentication, which means that as long as your user is authenticated, or has has a token against Azure AD, they can go and access the application but we also give you access to social media account logins. So you can have a Microsoft account, you have a Google account, you have a Twitter account that can also be permitted to access the application, you can figure these in your app. And you can have multiple of them selected as well. The only caveat I would say is that if you decide to do that, then it's either all or nothing. So you have allow anonymous access, so everybody can access the solution, or you have authentication authorization that takes place across the whole solution. So before they even hit the first page, they have to authenticate first, you can say I want part of my solution to be anonymous, and then other parts of the solution to or the app to require authentication. So it's all or nothing. We use a bit of a trick solution, but for someone that didn't have authentication before, and now they get it for free without really having to do any code changes. It's a fantastic solution.

 

Barry Luijbregts  27:54  

Definitely. Yeah. And that stuff, of course, because as your Active Directory is then in front of your application, as well. authentication layer there. integrate into your application.

 

Christos Matskas  28:03  

Yeah. So it's a it's an interceptor, right. So there's a request coming in, we intercept the message, we check whether there are any tokens or whether there's an authentication header if you're creating an API or what have you. And then from that point onwards, we make sure that the users are authenticated before they even access the solution.

 

Barry Luijbregts  28:23  

Right. So and then the other option is, let's say I have an ASP. NET Core application, a web application, maybe even a blazer server application, which is also ASP. NET Core, then I can also connect it to Azure Active Directory. I usually do that with a wizard in Visual Studio. Sure What what happens there in the background? Ah,

 

Christos Matskas  28:45  

yeah, we we did try to make the onboarding into Azure AD much, much simpler. And the whole point there is if you are using Visual Studio, then as you create your application, there is usually an authentication option at the top hand corner. When you say I want to create an MVC or a razor page, at that point of the wizard, you can go and define what kind of invocation you you want to use. And if you say I want to use single tenant Active Directory backed up authentication, we will go and create the app registration for you. And then the application will also be populated. So if you go into the app settings or the web config, once that application registration is successful on Azure AD, then we will populate that information inside your app will also download the appropriate libraries for you. And why not the code, which means that as soon as the solution comes up, you can click Run, and then you'll be presented with a login page that runs against that operation you just did. All Out of the box without you having to write any piece of code, which is great.

 

Barry Luijbregts  29:55  

Yeah, that that is amazing. And then you can use we've talked about that In the beginning, then you can just simply put the authorize and authenticate attributes on your controllers, right? To define while this controller if you go here, which requests you need to log in, and maybe then you need to be an administrator to access this, right?

 

Christos Matskas  30:18  

Exactly,

 

yes. So I will give you a, I think if you do if you follow the wizard, then as soon as you launch the application, it will request that you login, you can change that and then say, you know what, I want everybody that hits my homepage to be anonymous. I don't want them to authenticate by once they need to access other parts of my solution, then at that point, I want them to authenticate, maybe give them access to the application data or what have you.

 

Barry Luijbregts  30:47  

So then you have all sorts of configuration values that point to your Azure Active Directory tenant and your Azure Active Directory application. Is that safe to have that all of your configuration or is there a better place? Put,

 

Christos Matskas  31:01  

if you are going to do a Spinetta syndication without really hitting any other API's or what have you, then this that the information that we store in the web config or the app settings, so Jason is just your tenant ID, and well known and public endpoint for logging in. So there will be login.microsoft.com. And there will be your client ID, which again, it's just a grid, and nothing else. So you have your tenant name. And if you use a custom domain, so it could be see mascus.on match.com. They're well known login name and URL for login at macro tocom, the tenant ID, which can be, which will be agreed, and then the client ID. If you are, however, creating a single page app, if you're creating a node app, if you're creating something that requires implicit flow, or maybe you creating a console app, right, that doesn't have user interaction, which means that the console is running as a daemon Not every half an hour, that application needs to go and authenticate against Azure AD. And then get some information out from Azure, maybe something from graph or some other API, then I definitely need to have either client secret go to our certificate, we'd recommend people use a certificates over a client ID a client secret, because the client secret needs to be long character that needs to be stored and somewhere easily accessible. And it becomes a bit of an issue, right? So the certificate takes the ownership away. So you don't have to compromise anything, as long as you configure your app registration to use that same certificate. It's very easy and straightforward. In fact, I blogged about that a few weeks ago. So it's, it's a little bit more involved because you need to have a certificate but can use any certificate can be a self signed certificate, you don't have to have a proper certificate, more pay money for it and then just upload it into Azure AD and authenticate. So There's nothing really wrong with using the wizard because it doesn't compromise security. But once you have to store client secrets, then that becomes an issue. But we also have a workaround for that as well. Then if you if you're aware of managed identities and Key Vault and what have you.

 

Barry Luijbregts  33:16  

Yeah, so Key Vault is in a secure place in Azure, where you put secrets, right? You can put passwords in there or connection strings or even certificates if you want to.

 

Christos Matskas  33:25  

Absolutely.

 

Barry Luijbregts  33:26  

Yeah. And then what is managed service identity?

 

Christos Matskas  33:30  

Well, if I'm going to use keyboard, I need to have a way to connect to that securely. And in the olden days, you would have to have client secrets or a key for that. So you would use the URL to the keyboard. And then that key would allow you to authenticate and say, you know, I, I am an owner or a user of that keyboard. The problem there is that you have to store that secret somewhere. Yes, sometimes it can get to a point and for that reason, what We did is we created this thing called Manas identity. This is again, an entity inside Azure AD that we can use to provide proof. So if you are running an app service and their specific miners identity, then what that allows you to do is to go to Key Vault and retrieve the necessary information you need, say for Azure AD or whatever, at the point of the application starting up. And that takes away the the problem that we have of storing secrets somewhere. So minus identities. He's an account that the applications running under that context and that context allows you to go and hit other services. It's not just given it can also be SQL Server. It can be your event grade. And a lot of services on Azure are starting to adopt MSI minus identities as the way forward. And that simplifies your life as a developer because you don't have to worry about monitoring secrets. You don't have to Go to your admin and say, Oh, please give me the secret to the Key Vault or the secret connection string to the database. Your MSI does it. And now if you're developing locally, you might say, Well, I'm not running on Azure. So I don't have a massive empty Visual Studio and Visual Studio Code allow you to have an account. And there's a library, therefore dotnet allows you to locally develop against the services using your account. So as long as your account is authenticated inside of Visual Studio, and you logged in with that account, and that same account is also given permissions to those same services, then visit studio and use your code will use that information to go and reach out to those services. They're not actually using MSI. But the library that we use has three different ways of authenticating. So the first time it will try to look for an MSI. Luckily, you don't have an MSI. So we'll go to the next fallback option which is a Visual Studio account. And then the next one is an associate line. So if you don't have your car, you can use the Odyssey ally, login to Odyssey ally deck. It's a local file on your system, an encrypted file on your system that the dotnet library uses to speak to other services on Azure.

 

Barry Luijbregts  36:13  

Right? Oh, that's, that's just great. Yeah. So then you don't need to store any client secrets anymore. You just use Key Vault and managed service identity, which is part of the infrastructure or locally if we run Visual Studio, Visual Studio code, and then you're all good to go to connect to whatever and Azure Active Directory, for instance.

 

Christos Matskas  36:32  

Exactly. So for people that are hearing this podcast, hopefully, it's quite a few of them, then I hope I don't see secrets in your solutions going forward, because now I told you how to do it.

 

Barry Luijbregts  36:44  

Right. Yeah, of course, nobody does that. Nobody store secrets in their codes. I never know No, I've never done that before.

 

Christos Matskas  36:53  

No, I mean, we've all done it before. But now that I mean, back in the in the olden days, we didn't know better or there was no better solution. Do it. Yeah, these days, even dotnet core has really good ways of managing secrets. Like you don't have to have a keyboard or whatever, you can have a secrets file. And then if you're running on Azure, whether it's a function or an app service, you can use environmental variables to populate those secrets in your application. So again, you don't have to share those secrets anywhere. You don't have to compromise your solution. But with Key Vault, get other benefits like central auditing, so you can see where your logins are coming from. Again, as you said earlier on having a password it people in your company can have a dashboard that checks the logins and then if something comes from say, Romania, I wasn't expecting a login from Romania because our apps are running on totally different environments. Then that can be a red herring and suddenly you can see how you know either an account has been compromised, or something else and the nice thing about keyboard is that we do automatic girl key rolling the keys for you Same for MSI MSI, were all the keys for you. So you don't never ever know what your password is for these.

 

Barry Luijbregts  38:06  

Yeah, that's all automatic. That's awesome.

 

Christos Matskas  38:09  

Yeah.

 

Barry Luijbregts  38:10  

So we are coming up to the end of this episode. So last question is, what is new in identity? What's coming up? And where can people find out more about this topic?

 

Christos Matskas  38:23  

and identity in general, we, we made quite a few announcements are built for anyone that's dealing with, with identity, Azure AD in general, not just dotnet specific. We had we announced external identities, which is something that allows companies to bring external accounts into their org. So again, if you're Walmart and you're running a internal applications, you might want to have a vendor or somebody else to log into your organization that allows external identity allows you to do that. So it's not b2c. It's not aimed for consumers, but it's more about allowing other customers or businesses to log into your enterprise environment with Excel bmps. So not mydomain.com, but their domain.com account. So that's a big one. From $1 perspective, we did have a couple of big announcements. The first one is that we are actually not for just that, that's a correction not for dotnet only, but we are announced the deprecation of a doll, the older library for Azure AD. And going forward will only be supporting emsl. This is coming to an end in June 2022. So you still have plenty of time. And if you follow our stream on tweets, then part of our efforts are helping developers to you know migrate from a belt to emcell. We're doing lots of different themes and examples about how you can do that on your technology stack. So it doesn't have to be dotnet. So that's a quick announcement I'll stand for. And so ADL is Active Directory authentication library and emcell is the Microsoft authentication library.

 

Barry Luijbregts  40:03  

Right? Yes.

 

Christos Matskas  40:03  

And and their corresponding libraries in node and dotnet. And we have Angular libraries. And we have Python, what have you. So all all technologies and all languages have their own Ada library. Now we're moving away from that to Amazon. Because people might ask, like, why would I need to move to Amazon? What's wrong with dado with emcell, you get all the things that we talked about, like multi factor authentication, fito, keys, and whatever, as you want from the newest features automatically out of the box. So the same application running today, as soon as you move to emcell, you will get all these benefits. So that's the big announcement. And then from a dotnet perspective, something that is very modern and contemporary is the fact that we have a new library called Microsoft identity, the web that bridges the gap between the the authentication and the token management Just to clarify, in ASP dotnet core, you can do authentication using the local library, read the local identity provider, you don't have to use Active Directory. But then if you need to call other services, or ms graph or whatever you had to bring down and solve, the problem there was that even with a doll, you had to had a doll to authenticate against Azure AD. And then he had to have m salt to manage your tokens, grab it talking for graph and then go do the query with Microsoft did I didn't have the web would give you one library that erupts around himself, and does both the authentication to token management. So you indicate as a user, and then you say, go and grab my token for graph and, or these scopes, whatever you decide to do in your app registration, and we'll do it for you. It's all in one library. It's all oversimplified. it rots away the abstraction. So you can have authenticated web apps can have web API's I call other web API's can have a web app that goes on other web API All in one line, they're all nicely down through the standard of CS. And we have lots of blog posts. And we're going to be doing quite a few streams on our twitch channel to talk about why and how the changes are very small. So if you are using a Delta day, it takes only a couple of lines of code and a couple of nougat packages to get migrated to a new system. And it's highly recommended. So feel free to reach out to us if you have questions about any of the things that we talked today, by the way.

 

Barry Luijbregts  42:29  

Okay, that's great. A lot of stuff. So, okay, we are at the end of the episodes. So thank you very much for teaching me everything about identity and getting me up to date. Thank you very much for your time.

 

Christos Matskas  42:44  

Thank you for having me. It's a it's been a pleasure, and I appreciate your time.

 

Barry Luijbregts  42:50  

Thank you for listening to another episode of developer weekly. Please help me to spread the word by reviewing the show on iTunes or your favorite The podcast player. Also visit www.developerweeklypodcast.com for show notes and the full transcript. And if you'd like to support me in making the show, please visit my PluralSight courses and to learn something new.