All right, so the music fade out means that is my cue. So my name is Ken Dale. You can find me on all the various interwebs places. Ken Dale IV. If you're wondering what the IV is for, it's a suffix on my name that's a four. So I am the fourth Ken Dale.

That said, my talk today is we replaced a multi-application homegrown authentication system. That's a lot of big words, but I'm sure you can handle them all. So a brief agenda for today. I'm just going to start off with any good talk. You start off with the starting point. So the starting point being our existing system,

our existing authentication authorization system. I'm just going to talk about that so you know where we were, to know where we were going to. I'll look at the different choices that we had at our disposal to explore, and the different ones that we looked at, and what we ultimately chose. As part of that, we'll then look at the implementation of that choice.

And finally, we'll look at a deep dive into impersonation, or assuming someone else's role while you're developing a web application, or simply just assuming the role of the user in production. So we'll start with the starting point, because that seems like a good place to start.

So our prior solution was a custom-built, centralized solution that was built on ASP.NET forms off. So I'm going to try to illustrate what it looked like here. So we had our centralized server, if you will. And that had a bunch of different applications.

So all of the authentication was handled centrally in the server. And then each individual application handled its own roles-based authorization. So in each application, we'd call stuff like user

is in role, and we'd look at things like administrator, or manager, or staff. But that was all handled on a per-application basis. But when a user would log in, they would go from the app back to the server, and it would redirect them to a login page. They would have to fill in their credentials, and then they would get redirected back

to the application. So then it also cached their login credentials. So if they were to log in with another application, they could make that same round trip, but it would no longer prompt them for their credentials, provided that it was within the cached window. So that was kind of where we started. So now that you fully understand where we were starting,

you can kind of get a feel for where we're going. So traditionally, if you're not familiar with ASP.NET forms authentication, it's typically something you would wire up into a single application only. But in our case, we had a custom-built homegrown solution that was built on top of that, which added that centralized authentication layer.

So just to reiterate the point, centralized authentication per application authorization. I'm going to keep coming back to that throughout the talk, so it's important that you kind of have that fundamental understanding as to what we were working with. So our rationale, at the end of the day, why did we want to do this?

Primarily, we wanted to be able to support new scenarios. So there's all sorts of different ways to log in. If you go to stackoverflow.com and you're logging in to ask a question or provide an answer, you're probably logging in with your Google account, or your GitHub account, or your Facebook account. I'm sure many of you are familiar

with that whole concept of not actually having an account at a website, but using something like your Twitter login to be able to create an account. And that was a capability that we wanted to have in the future. We're not currently using it, and we're not currently there, but we wanted an easy path forward in terms of being able to provide those social logins.

In addition, we also have Active Directory as part of our environment. We're primarily a Windows-based environment in terms with the office and those computers and whatnot. So in the morning, users come in. They log into their machines with their Active Directory credentials, their username and their password. And then they would come over to all of our web

applications. Not only did they have to log in again, but they had to log in again. But it was a completely different set of credentials. So you can imagine what kind of annoyances that creates whenever users have one set of credentials that they log into their machine with. Then they have a completely different set of credentials that's for the web applications.

Those may not be in sync, and they each have their own password rotation requirements, which I don't even recall if they lined up. But either way, it's just not a great scenario. So we wanted to be able to utilize our existing Active Directory logins, as well as be able to use the functionality in the browser to be able to flow the user's credential right

into the login. So when we were all done, we essentially were able to log in staff by just clicking on the magical little Staff Login button, and everything worked great. Also, we wanted to be able to support SPAs going forward, SPAs, the single-page applications, where you download all of the application's code whenever the page loads in the browser,

and then it makes calls out to web APIs and various other resources to be able to actually run the application. But we really didn't have any capability of doing that with ASP.NET Forms Auth. At least I'm not aware of any way of doing it, and I don't recommend that you would attempt it. So we wanted to be able to support the SPA applications

going forward. We're not doing those currently, but it's something we're looking at for the future. So a lot of this was building out for the future in terms of where we're going and what we want to do as a business. So that said, we looked at various options. And basically, if you're writing a new authentication system these days, it's pretty much

you look at OpenID Connect, and you say yes. There's all sorts of different ones. You could look at something like SAML, but no, just don't. Just use OpenID Connect is at least my advice in that matter. So we wanted to be able to follow this modern spec that is moving the web forward and that everybody seems

to be migrating to and supporting these days. So if you're not familiar with OpenID Connect, OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. I'm sure that clears everything up perfectly. So you may already be familiar with OAuth 2.0, whether you know it or not. If you've ever done the sort of Facebook login

where you go to Stack Overflow, it redirects you to the Facebook login page, you put in your Facebook credentials. That, in a sense, is OAuth 2.0. So if you're familiar with that whole delegated login where they trust Facebook, you trust Facebook, everybody trusts Facebook, and everything just happens to work, that's kind of what you're looking at with OAuth 2.0.

So then OpenID Connect adds a simple identity layer on top of that. So you've got options in terms of moving forward. In terms of the background image here, you could protect your applications by a guy with a sword. Guy with a sword has some fundamental problems.

Guy with a sword does not scale. And guy with a sword can kind of tire after a while, especially if he's got that two-hand claymore. He's gonna, it's gonna be slow times for your application. Plus you're gonna have to keep them caffeinated like 24-7, 365, it's not a good idea. So some actual real options. You could write it yourself.

And I said real options, but I should probably take a step back and say this is not actually a real option. This is a real option if you're a security researcher, if you know what you're doing. The fundamental problem here is there's all sorts of unknown unknowns that you just don't even know about. You might fully understand the idea that yeah,

you don't store passwords in clear text because that's, everybody knows that's terrible. But there's all sorts of various things that go with that. You don't wanna store them with reversible encryption. You need to be able to store them with a one-way hash. And even that, you could even choose a weak hashing algorithm. You need to fundamentally make sure you're doing things correctly.

And a lot of these decisions and implementations, if you just use somebody else's library, things are just gonna work out a lot better for you. So even the Azure documentation is pretty much even saying don't roll your own. So it's probably good advice. If it's in the Azure documentation,

Microsoft is telling you don't roll your own, it's probably some pretty good advice. So that said, you can also find a reliable open-source implementation. So there's all sorts of different open-source implementations of OpenID Connect out there for the various platforms, whether you're doing .NET,

whether you're doing server-side JavaScript, there's all sorts of these. But I recommend finding a good reliable one if you're looking to self-host and kind of go that route. Or a third option is you could just let someone else deal with this stuff entirely. And in terms of that, it's basically finding an online service.

There's one and only one I'm a little bit familiar with, and that's what, Auth0. So this is the kind of thing, I think if you're a startup and time to market is extremely important to you, and you're, at the end of the day, you just want to check the box that you're able to log in users, and cost is no object, and you don't really

have a lot of customer requirements, and you're not a big enterprise, Auth0 might be something to really look into or another service like that. But just weigh the different options. You're all smart people, take advantage of your research capabilities and figure out what would work best for you. So in terms of our organization and our team,

we decided to cloud host some open source. So we ended up using Identity Server, and then we coupled that with the Brock Allen membership reboot library. So this pretty much makes up the bulk of our authentication system. So, Identity Server, has anybody attended like any of the training this week

with Brock Allen and Dominic? Yeah, so this is basically kind of what we did at the end of the day, so it's pretty cool stuff. It seemed to work out really well for us, and we've got it in production today, and to my knowledge, I've been gone since Sunday, and to my knowledge, nothing bad has happened. So I'm still comfortable with recommending this

as a solution, yeah. So with all great development projects, you can sit around and you can talk around the campfire all the live-along day, but at the end of the day, you need to make a decision. So way back when, which was way back when is like last year, so in terms of like internet years, that's what, like 30-some years or something.

So way back when we made that decision, you know, we decided what we're gonna do, so now it's time to get started, time to move forward. And I wanna caution you, this stuff is gonna look easy. So you're gonna see across the bottom, we have users, we have clients, and we have scopes.

So we all know what users are, we think we know what clients are, and scopes, I think I'm kind of familiar with those, because it's like, I've done some JavaScript, and I understand the difference between block scope and function scope, so it's not really the same, but I kind of know what the word scope is, and like there's like a mouthwash that's called scope,

so I figure putting those two pieces of knowledge together kind of probably get me somewhere close here. And I know what a fingerprint is, because I have all sorts of those, and I like paired my fingerprints with my phone this week, like that was fantabulous. And there's someone there with a tray, a guy or gal that is like bringing me food, so I'm familiar with that concept, clearly.

And there's just like security there at the top. So clearly I know what I'm doing, it's gonna look super easy, because these high level diagrams, they're really deceptive. You think you know what you're doing, and then you're gonna see another diagram when you go trolling through the documentation. You're gonna see the one, so let's pretend

we have a browser application here, and we're gonna talk to a web API. Well, you just use OAuth 2, what's the problem? It's not a big deal. And then, oh, you wanna call a web API to call another web API? Well, you just need to use OAuth 2. What's the problem? One of the problems here is you don't fully understand,

you don't even know the right questions to ask. So when that one web API calls the other web API, is that using some sort of pre-shared key, or is that flowing over the user's credentials? And what goes along with flowing the user's credentials, I don't know, because that kind of makes my head hurt. We went through that a little bit, and it was just like, I don't even, I don't know.

But there's all sorts of these unknown unknowns, and these diagrams are gonna make it look easy. And then you're gonna start the real work. So this is an ASCII diagram directly out of the OpenID connect specification. So if we see the RP, I think I know, that's like relying party, I know that one, I think,

if somebody wants to shout me down if it's actually wrong. Like OP, I think that's like overpowered or something. So there's like this overpowered thing here on the right. We have this auth n. Okay, I see auth n and auth z, so I can kind of figure out what those are. So it makes a request. And then we wait on the end user, so is that like a workflow?

What is that? Because it's not an instantaneous thing. Our users aren't that caffeinated, so we do have to wait on them a little bit. So what happens in that weird limbo state? And then like some other magical things happen. So I mean, this is the very beginning of it just escalating or it's getting to the point

where it's like, I'm starting to get a little concern, like things are starting to get hard. Okay, I have to take a sidebar here. So we started this thing at work where it's just a blank. So you fill in the blank, whether it's just a link, it's just a table, it's just a whatever, it's just a protocol, some crazy example.

So in this case, this is kind of the really extreme example of it's just a spec. Like, what's your problem? Like, why don't you have this done? Like, everybody's already done all the hard work for you. If we look real carefully here, it's the OpenID Connect Core 1.0

Incorporating Aratus Set 1. Like, you don't even have to do any thinking. Like, all the experts have already done it. Like, go read through the spec and implement the spec. What's the problem? You'd be done by lunch. But that spec, when you start looking through it, it's actually pretty dense and kind of terrifying. But I think part of it is security, it's hard to do

because you need to do it in a manner that is fundamentally secure, which you're constantly battling between easy and secure, and they're trying to bridge that gap and have your Facebook account not just get hacked by some random person who has nothing better to do with their time.

So sometimes it's tricky simply knowing what to do. So after you get bombarded with those simple diagrams and then the more terrifying diagrams and then the terrifying spec, you just sit down at your computer and you're like, yeah, so now what?

I think we, like, create a new project, maybe. I think I wanna do C-sharp today, pick that. And you can kind of get into this notion where it's like you feel like fundamentally stuck and it's like this big insurmountable task. It's like it seems simple, so you feel kind of dumb in a sense because it's like, well, it's just that simple

little diagram of authentication. Like, why haven't we finished this? Like, it's Friday, like 2.30, like, let's go. But it's tricky simply knowing what to do. So there's various ways to get unstuck. You know, you can watch various training things, you can read some books, chat with your colleagues,

go out for tea, do whatever you'd like. So this is, yeah, this is how you're gonna feel. You're gonna feel like the very regal dog here. And if this speaks more to your sensibilities, we also have the dog playing the Guitar Hero guitar. I don't know how he, I mean, as humans, some people have problems with like the fifth one,

but I think the dog's just gonna have problems with like all of those. It's just gonna be a bad time. You probably don't want him in your rock band band either, unless you like give him the drumsticks or something. So expert help, even if you're experienced, this can be really valuable to get off the ground. So those of you that attended the, you know,

expert help, if you will, you've kind of already gotten the jumpstart on having the expert help. But we essentially, as a team, we had the expert help come on site for a period of one week and really shot us into gear in terms of getting the project off the ground.

So I think on some level, like there's this whole notion of developer laziness, and it's not like terrible slobberly laziness. It's just like you can defer things, et cetera. You know, you're using your brain. But it's like, if you know you have an expert coming, it's like, do you really wanna make a whole bunch of progress and like try really hard when you know somebody's gonna come and like give you all the answers?

So it's like, nah, we'll just kind of wait. But the one week period of having the onsite consultant for us, that was absolutely amazing. So we pretty much launched the project. And what it looked like was it was mob programming where I was the guy who was the keyboard operator. I had my boss and a coworker who was the project lead.

I mean, this was a pretty small knit team that we worked on this with. It was pretty much me just slamming at the keyboard as fast as humanly possible, trying to keep up with the consciousness of three people. And at the end of the day, like I have no regrets because at the end of the week, like we had something like really fleshed out and solid and like we were well on our way.

And all it took was like a week of consultant time. So that experience in and of itself was extremely valuable for us. And honestly, every person that was on that team in a primary fashion, we were all experienced developers. Like we know what we're doing. We're not struggling with the mechanics of the language

or the syntax or anything, but still having that, someone who's dedicated their career and their passions in terms of the thing you're trying to implement, don't underestimate the power of what that can bring to your project. And I keep saying all these terrifying things and it sounds like gloom and doom.

And it sounds like, oh, I'm never gonna be able to do that. But honestly, like if you're in this room or you're watching this video here or online, like you are the people that are able to do this. Like I believe in you, like just by virtue of you watching me, that means you're fully capable of this. So, but don't plan to ship it in a week though.

Like this is not, you know, there's the notion of writing Facebook on over a weekend. You know, you can write Twitter on your lunch break and yeah, maybe you can, maybe you can't, whatever. I'm not here to debate that, but don't plan to ship this thing in a week. Even if you have a full and complete understanding of it, there's a lot that you need to, you know, fully investigate and make sure

you're making the right decisions. And you need to test the thing like crazy. Cause if you switch out an authentication system and something doesn't quite work right, like there's like bugs in production and then there's like, everything is totally broken. Nobody can log in and it's a Monday morning. You probably don't want that.

So kind of shifting gears. Security is hard, make it easy for your clients. So what's going on here is people are apparently driving up to this gate and they either have ability to raise the gate or don't, who knows. And instead it's just easier to just turn your wheel to the right and then turn the wheel back to the left.

And apparently you can just go right around that. I'm not saying you do that in your authentication system, but making it easy for your clients, meaning other developers on your team and even yourself as a developer or future you, cause future you is essentially you that wasn't involved on the project anyhow.

So security is hard, make it easy for your clients. What does that mean? To me it means choosing your own abstractions. So everyone, those of us that work on computers, we work on top of so many levels of abstraction. It's crazy. Like I couldn't imagine working on a computer if I had to manipulate things at the file system level,

like twiddling bits on disk every time you saved a file. Like you'd never get anything done and your job would just, it'd be terrible. Like nobody wants that. So in terms of choosing your own abstractions, so you may or may not be familiar with this. This is an ASP.NET startup class.

So it's like the Owen thing. So this code runs on application startup and this does two simple things. It grabs our authentication system configuration and then it applies it in the standard manner in which we've defined for our organization. So there's all sorts of magical code

that's under this use standard vorg auth with roles. But at the end of the day, we've already fundamentally made the decisions as a team. So now we're able to just use those in a really easy reusable fashion. So I can now tell any developer on our team to go wire up our authentication system

and this is literally all they have to do is just go into an application, create a startup or edit it, the one that is already there and just add this stuff in here. So what's going on here is the org config get from app settings. We host primarily on Microsoft Azure

and we found that app settings seems to be the best way for us to manage our QA and our production and keep everything in sync and have the settings be changeable. Basically the only real way we found is to be to just use app settings. So we try to name space them and be all fancy about it but it's just a bucket of configuration

at the end of the day. But you can use whatever method of configuration you want but you have it behind this abstraction of just getting it from wherever. And then use the standard vorg auth with roles so it takes in the configuration and if you remember back on my scribble diagram how each individual application handled its own roles.

So now that we're upgrading that we also need to take that same level of functionality and provide that with our upgraded application. So in terms of this, this is a funk that takes in the current user and then it returns the roles for that current user.

So it could do anything like looking at the users email address and doing some sort of where contains or where ends with, that sort of thing. Or it can make a database call or it could do both. Whatever that application was originally set up with it'll continue to do the same thing. So it allowed us to kind of move forward without fundamentally mutating the security requirements

of all of our applications. So authentication and authorization. So when you see auth n, I kind of covered that a little bit earlier but when you see auth n, it's authentication. When you see auth z, it's authorization. And these things are somewhat unfriendly and part of it, it's just by design.

And what I mean by design is if you have a 16 character password and you type 15 of your 16 characters it doesn't matter that you got close. Like you don't get points for trying. This is not everybody gets a trophy. It's no, you don't get allowed in and nobody explains why.

It's just fundamentally, it's just not gonna happen. So what this looks like in terms of, if I'm having a conversation with the server, let me snag some water here. So if I'm having a conversation with a server,

it looks like me asking the server, excuse me server, do you have the time? And the server just replies 401 unauthorized. So if the server knew who I was but it wasn't gonna let me know who at the time was, it would have told me 403 forbidden. But in this case, it doesn't know who I am so it's just, I'm not even listening to your request

because I don't know who you are or you're just fundamentally not allowed in. So 401 unauthorized. So I try with the password. So I say, hey server, well the password is this. And I get a 401 unauthorized and I'm like, you know what, maybe I misspoke or mistyped the password so I try it again and I get another 401 unauthorized

and I go, wait, did I have to change my password last week and naturally because you have the 90 day password rotation, you just take your password and you just manipulate it that small little way and then you don't tell anybody about it but we all do it. Maybe it's that other password and you try that again. And you're like, oh wait, I know, I'm doing bearer tokens

so I need to take the authorization request header, I need to add the word bearer and then I need to put the value after our space and you try that and you get the same predictable response. It's not giving you any information as to if you're close or what the real problem is. And you're like, wait, I remember way back when we used to do basic auth and that was like a thing. You would take the username and then you put a colon

and then you do a password and you base 64 that whole string and you try that and of course that doesn't work. And this point you're basically reminiscing of your days in the 90s with Collective Soul Y part two and you're all like, tell me why. And it doesn't tell you why. It just says 401 unauthorized.

And at this point you're pretty much on the verge of a nervous breakdown and you just get 401 unauthorized. So this can be kind of frustrating when you're trying to figure out why your authentication system isn't working and it's fundamentally just saying, nope, nope, nope, like no help, nothing.

And what is the cause of most of these problems? It's almost always configuration. And I'm not exaggerating. I feel like most of the problems we've had where we've had either a problem in QA or a problem with production or even a problem on your development machine, it's always something that's misconfigured

and it's super annoying. Like you think, oh, maybe there's something wrong with some library or blah, blah, blah, somebody else's problem. Of course it's not. It's your configuration and it always is and it always will be. So annoying, so unfortunate. Seriously, it's configuration. So that said, the less configuration you have,

the less chances you have to twiddle the wrong knob or make a horrible, horrible mistake. So I advise anywhere where you can simplify your configuration, do it. So if you have multiple URLs that have the same domain but then they have the same predictable path,

like the path to getting an access token or this, that, the other thing, shorten those all down to one single, provide the domain and then hard code in the paths or something like that. And if you have configuration that you know is never going to change, perhaps just hard code it. Even if you do decide to make a change later, I mean, yes, it's a deployment,

but it's not like you can't change your mind, but at least you don't have to remind yourself about that annoying decision that you made to never change it every single time you set something up. And the one time that you forget it, then something is horribly, horribly broken. And while I'm talking about configuration, just keep your secrets out of it.

It's just a bad idea all around. It's like having the connection string with the password in it, having the secret key in your app settings. Like, yeah, source control might be a protected thing, but having things in source control is generally just a bad idea because you kind of forget what's in there, in a sense, and it's like, ah, maybe we should turn this repo

into a public one at some point or give somebody else code access, and before you know it, deep down in the bowels of your git history is some scary connection string that you overwrote three commits ago, so it's fine, nobody goes and looks at history, so. But yeah, just keep the secrets out of there. And I know sometimes there's technical issues

with doing it, and maybe you have problems with PHP and certificates or some shenanigans like that, I don't know, but do your best to make it possible. So logging can be super helpful when things don't work. So I'm going back to that whole example where I'm basically getting that 401 every time, and for all I know, there could be a configuration problem

that's basically preventing it from even checking whether my credentials are valid. So I was trying all those different passwords, all those different ways, and fundamentally, at the end of the day, maybe it didn't even matter because it was like a scope missing or some other magical configuration thing.

And who here, does anybody do like logging of their just unhandled exceptions in like any web applications, that sort of thing? So if you have an error and nothing handled it and the user saw a big scary error message that you like logged those things and then you're able to react to it. So that's something we do,

and we found that having things that look like this is a bad idea. So if you look carefully there, there's an actual problem, but the problem is it's in this sea of ambiguity of things that aren't actually a problem. So it's like, well, something expired. Like, well, it may or may not be a problem. We're not really sure, so we just kind of leave it in there.

And then somewhere in there, there's like everything is broken right here, but you can't really see it when at a glance. And before you know it, you're basically declaring your bankruptcy on your big list of errors. So I advise if you're running a system like this, it's a good idea to keep on top of this kind of stuff.

So that way you can spot the actual problem. And something we haven't done, but could be something for our future, is I think it might apply to more if you're more like consumer facing and you have like a million accounts and you're running like an e-commerce store, being able to analyze your login records and those sort of things

and seeing which users are using which applications at which times and being able to put that on a map and do all sorts of fancy stuff with that. That could be something that'd be pretty cool. It's something we haven't really had the need to do yet. But if you were to be able to take that log data and like siphon it into something like Elasticsearch or something else, well, Elasticsearch with like the dashboardy stuff

that they've got going on there. It might be something for our future, but if that seems like it applies to you, that might be a good direction to look. And sometimes the debugger won't help. So this is kind of the funny story about configuration. At one point I was working on a feature on my development machine

and it's like I'm going through and I'm having problems. Things are not working and I get the error message from the debugger and it said like invalid underscore scope. So it's like I didn't need the logging because I had the exact error message in front of me and it's like I know what invalid scope means, but for the life of me, I could not figure out what the problem was.

So I call over my one coworker and I don't even think he initially just picked up on it right like that. I think he might have actually wheeled back to his desk which is what, like 16 feet from mine or something like that. Open offices, good times. But yeah, so after he goes back to his desk, he has this brainstorm like,

oh yeah, you didn't add it to the list of back-end allowable scopes. I was just like, all right. I was adding bearer token authentication, added a new client, gave it the bearer token scope and then I forgot to add it to the back-end collection of stuff. So it was basically saying invalid scope

and I'm like, well, I have this scope right here. I'm looking straight at it. So coworkers, logging, those sorts of things. Anytime you can get more information, that's something that's super helpful when working with this stuff because the whole notion of having the door slammed in your face with a 401 is not particularly fun or funny.

So another tale is staying up to date. We ran into a small bug with HTTP strict transport security with Firefox. It's one of those like, okay, like it's not like a big deal but if it was a big deal, we could have had a big problem that so they fixed the bug but they fixed it in a later version than what we were using and it was a later major version

than what we were using and it kind of came with some breaking changes and we didn't really want to invest the time and effort into pulling it forward. And I think that was a tale of we could have very easily fixed a bug and just had it done but instead it kind of hung around for a little while because we didn't stay up to date but if we were a little more vigilant

about keeping all of our authentication related packages up to date, that could have been something that could have been really cool for us. Could have been an easy win and thankfully there wasn't like a critical security vulnerability where it's like, you need to upgrade everything now and patch everything now or you're gonna get completely pwned.

So that said, we got three points down and one deep dive to go. So I was playing the Star Wars music so you may or may not find that funny and if you don't get the reference, this might help. Yeah. All right, so the deep dive that I have saved here for the end

is about impersonation. So impersonation, for us it's a development time thing but in the future, I think it might morph more into our QA and production time environments because right now our QA environment is basically when you want to impersonate a user, you basically go find a known password hash and like overwrite their hash in the QA environment

and that's just kind of annoying and painful. So if we had that baked in as more of a first class concept, I think that could be super helpful for us but right now we have it available in our development environment and I'll show you what it looks like and it's an open source library and it's pretty cool and I say it's pretty cool because we wrote it so that makes it cool.

But so kind of the backstory I guess with the development time impersonation if you will, our existing system has the ability to specify what user you are running at as part of the web config. So there was like this user override section and you can basically specify I'm running as this user. Well that was,

it worked really well honestly but the problem is when you make a change in a web config, anybody who knows about ASP.NET web apps, when you make a change in a web config, it tears down your app and then restarts your app and that's not really a big deal but you know what, we can do better. So we did. So we called our library Stuntman because that name wasn't taken I guess.

So sometimes you need a stuntman before you send in real unsuspecting users. So we've got a cool logo. So that makes us legitimate. So this is actually available in nougat.org today. You can go install it in your ASP.NET web applications and use it. We've been using it in our production applications

for a little while now when everything's been working out really well. So you can just install package. It's rimdev.stuntman's package ID. So this is what it looks like when you wire the thing up. So we've got basically the options class which is pretty much the main storage of your options if you will. And then you fluently configure it.

So I hope you love fluent interfaces. So you do add user and then you add claims to the user. So in this case it's user one has a given name of John and a family name of Doe. And then you basically say and as you do with all sorts of fun own stuff you just use the thing

and that comes from some sort of using from Stuntman. And Stuntman itself doesn't take into account when you wanna display Stuntman and use it and when you do not. In this case it's doing is when debugging is enabled. Don't actually do this in production cause the problem here is

somebody thinks they're being cute and enables debugging in production because they wanna attach a debugger to it or something crazy like that. And I'm like yeah you think that's a good idea but now you've got your Stuntman thing wired up to that and all of a sudden users have this like weird user picker that they can just be whoever they wanna be. It's just bad times for everyone involved.

And then what it looks like in a razor view and don't worry about this I'm actually gonna walk through this in a demo so that's why I'm kind of paving through it kinda fast. So then you add it to your underscore layout and it's basically adding the UI component for Stuntman. So buckle your seat belts or put on your helmets or something.

So this is what we got. So this is what I was just talking about. So we got our Stuntman options class here. We can do all sorts of fun things with that. So in this case we're adding a user that's employee one. We're adding another user administrator one and then bonus round we're adding an API user one.

And each one has, in this case we're not actually setting anything about the user's name but we're just giving them roles. So we're giving the employee the employee role and we're giving administrator one both the employee role and the administrator role. And then API user one gets the administrator role

and they get a magical access token which will kinda cover that. So kinda keep that in the back of your mind. So that's kind of a cool little thing there. And that same wire up and then over in our layout CS HTML we have, yeah there's the UI wire up. So you do HTML raw

and for those MVC people in the room you're like you're returning a string that should be MVC HTML string what are you doing? So we designed it to be at a work outside the context of MVC. So if you see things like HTML raw and you're like that's kinda weird why didn't you just do HTML dot thing? So that's kind of the rationale that's going on there.

So that said I think we're ready to run this guy. I believe I already have it running. Yes I do. So this is a simple web application. It's just running locally on my machine, seek local host. That is basically saying welcome and it doesn't have the name of the user here.

And it's just describing which roles the user has at this point. So they do not have the employee role and they do not have the administrator role. So this magical little stuntman component down here gives us all this functionality. So I can now pick whether I'm the employee,

the administrator or the API user one. So I'm gonna pick employee one. We can see welcome employee one. So behind the scenes everything that is wired up as part of ASP.NET's built in authentication has now been mutated in order to use all of the stuntman authentication stuff. So now you can do something like user dot is in role

which is what's taking place here to make this. And that stuff just works. So it's like stuntman isn't necessarily tied to any sort of authentication infrastructure or framework or idea. It just works with the existing ASP.NET infrastructure in that manner. So we can see that the employee is a member of the employee role

but not a member of the administrator role. And as you would predict, when I pick administrator one, true and true. So we do have some secure endpoints so I'm gonna try to access one of those. So just to show you kind of what's going on here.

We have a secure endpoint and if the user is not authenticated we'll just return an HTTP unauthorized result. Otherwise we'll give them the view. So as an employee I'm an authenticated user so if I go to home slash secure it says welcome to the secure page employee one.

However, if I go back to the main screen, give it the old log out. So now I'm a completely unauthenticated user. If I go to the secure endpoint, oh, home secure, routing. Stuntman picks up on that

and redirects you to the Stuntman login page. So it goes to Stuntman, sign in and puts the return URL so it knows where to drop you back after you've logged in. So it's kind of the, hey, you don't have access to this page but we'll let you pick what you want because this is mostly written as a development time tool at the moment.

So it's like hey, you didn't have the ability to do this but who do you wanna run as and hopefully that person has that ability too. So now we can go welcome to the secure page administrator one and my last little part of this demo is I mentioned earlier

about having the, yeah. So we have this API user one. So that user has the administrator claim and then they also have this access token. So what's it look like to use this? And for this we're gonna pop over to everybody's favorite HTTP tool, Fiddler.

I don't know, Postman's pretty cool too. So we're just gonna get rid of that. So I am calling the path that's on my machine home slash API endpoint. So I'm just gonna make a request to that and we can see that I got back a 302

that then pointed to the Stuntman login page. So that's kind of doing the same behavior as the web browser was doing. It's kind of doing the same thing in Fiddler. Honestly, this might not be the best thing to be happening in terms of what's happening because this is like going through Fiddler and not a browser. So if you wanna fix this, we totally accept pull requests

and it's an open source project. So if anybody wants to contribute, that'd be swell. But if we add the authorization header back in here and we give it bear and we match the same value that was configured in the startup CS, when I execute that, when I come over here, we can see I got back a 200 for this request

and we got back JSON that's data equals some data. So if I come over to the controller and zoom out and get rid of magnifier because go away, and go back to home controller, right there's the data sum data. So you're able to use Stuntman

for both browser scenarios as well as application to application or any sort of API scenarios as you see fit. So that's something we come up with and basically it kind of grew out of this need to maintain our existing functionality in and through our web applications that we had this thing we could do,

then we upgraded to these other open source libraries and it's like well now we have this gap and this was something that we really felt was important so we put something out there to help fill that gap and we're quite proud of our work. So that said, let's recall the things,

land the plane. So configuration, your problem is always configuration from now till the end of time. But seriously, there are other problems but with your configuration, check it. When you're done checking it, recheck it backwards. When you're done rechecking it backwards, check it forward again and copy paste it

to make sure you don't have any misspellings or any trailing spaces at the end of your secrets, those sorts of things. And simplify it where you can. So four knobs is a lot easier to keep in the right position than 18 knobs. Nobody's gonna argue that. So if you're able to simplify your configuration, I recommend you go ahead and do that.

Seriously, it's always configuration. And remember to make it easy. So not everybody on your development team is likely working on your web app or your authentication layer. And you know what, that's totally okay. Most larger teams, you're probably gonna have a few individuals that are kind of focused

on this whole open ID connect and all of this infrastructure goo and that sort of thing to get all this stuff to work. But at the end of the day, you all wanna be able to use it and you in a year might not remember a lot of this stuff. And honestly, if it's easy for other people, it's easy for you as well. So make your own abstractions. It makes everything super easy.

And we found it to be really powerful. And we've even taken it to revisiting our abstractions in a sense as you add a new feature, we would add the identity server type stuff to a new application. And then we found we were doing that in multiple places. So we actually made ourselves another abstraction to kind of evolve that into our framework, if you will.

And I don't remember if I mentioned, but we distribute all of these abstractions via NuGet packages and they're private ones. So we have like a private myGet feed. So that's kind of how you can pass that stuff around. And authentication isn't easy, just like this terrifying Mario level. But you know, you all are the people that can do it.

If you're watching this video, if you're in this room, like you can totally do this thing. And I believe in you, I'm rooting for you. He is too. And thanks so much. And I'll take any questions this time, but you can always reach out to me on Twitter, just at kendalliv. And thank you.