Hi, welcome Much better. Thank you. So this is actually for me like like kind of a historic talk, I think I started talking about claims-based identity and you know token based authentication and

Resource based authorization all these things I started talking about that like in 2006 and this is now the very first time all of these concepts really Come together in a mainstream product. So it just took six ten years. It's great

Yeah So yeah I totally liked the new changes in security in 8.5 and MBC six. It's all new. It's like file new project It's actually so much stuff in there that it it wouldn't be probably possible to talk about all of it in in 60 minutes

so right after this talk there's Barry sitting here who actually works for the ASP net team and he's responsible for some of the features so and and he will talk about More security. Okay, so this is more like the overview and then later on Barry

We'll have a full hour just to talk about data protection and authorization and some other bits and pieces I guess Yeah, cool. So Right Just to to you know, let you know this is where ASP.NET lives You probably all have heard it's open source now

It's on github and so on and there's the ASP net Organization on github that there's a home repository which tells you where you know where to find what as you can imagine There are a number of different repositories implementing different things There is for example one called, you know, are that the one we care about mostly are called security and

This is where you find all of the security bits and pieces Source code, you know, you can open issues you can comment, you know all these things Another thing you'll find up on github, which is probably important for many of you is the roadmap

We've been waiting for that for quite a while now But you know all as all the good things in life they take a little bit longer But we are right now in RC1, yeah release candidate That's what it means There will be an RC2 soon in February, which will change it by a couple of things

And there will be hopefully 1.0 in Q1 which probably means like the last day of March I guess or something So just that, you know where we are right now, okay So if you want to start with the new stuff right now, it's not a bad time. We are pretty much close to you know

to being done Okay, cool, so The only really important thing here is if you want to have the slides They are on speaker deck comm slash lease privilege. That's where you can get the slides from

Otherwise you can write me an email if you want or you can read my blog as well So so just to get like an you know, like right now we have kind of like three Main lines of ASP.NET to choose from if we want to build an application, right? So there's the ASP.NET classic kind of yeah That you know was around since ever then there's ASP.NET 4.5 plus a thing called katana

And there's the new ASP.NET 5 which you know will be soon released So just to get an idea how many of you are using, you know Web forms MVC like the old MVC ASP.NET style of building applications Okay, how many of you have bought into the katana model to add security features? Okay a couple. Yeah, and

Who is on ASP.NET 5 already? Four you you don't count Okay, cool. So who is planning to use it pretty soon ASP.NET 5 Okay, cool So just in order to give you a little bit of you know history that that's the old ASP.NET 5, right?

You create an empty web application You got three or five pages of config file and a bunch of really weird assembly references from you know technologies from the yesterday's System dot enterprise services and you know all these kinds of things. Yeah, that's the old ASP.NET 5 and you know

Microsoft knew that, you know, we want to change it at some point and want to modernize that and so on But it was a big step to go from there directly to what ASP.NET 5 will be Yeah, so that there was something in between called katana and katana they call it a stepping stone

Yeah, because the hop from here to here is so big you could you could hop here first and then hop on so to speak So katana has many of the concepts already especially in security that are now in ASP.NET 5 so if you are using katana today and

And you'll see the Delta is not that big if you are on the old ASP.NET 5 and want to go to it Sorry on the old ASP.NET 4 ish And when I go to ASP.NET 5 then there will be quite of a you know a learning curve Um, what was katana in in in one slide well it in it introduced a new model how to build an HTTP pipeline

And that was you know, something called middleware and middleware are just you know, tiny little classes that process the HTTP request and add features to it either pre-processing or post-processing and

Typically at the end of this middleware chain, there was an application framework, which was the thing that was generating The response so to speak. Yeah, you know people who didn't know before it Connect is a similar idea and so on. Yeah, the the fundamental mind shift here is That in the old ASP.NET you got everything out of the box

Yeah, like you had your modules and handlers and everything was wired up and you know You had to basically figure out what you don't need and turn it off Whereas with this model here and also with ASP.NET 5 that the new model is you get nothing out of the box and you wire up What you need? Okay, which you know leads to I think a much much more efficient web application in the end

so Using that model ASP.NET 5 is the new thing. There is more to that than just a new HTTP pipeline It's now designed to be cross-platform Yeah, there's this thing called the DNX Which is a hosting environment which gives you additional features on top of what you might know from from dotnet like

in memory compilation bad example, maybe but Assembly Resolving assemblies in a different way new get being a first-class citizen in that in that world

Bring your own CLI. So the DNX is an abstraction on top of the CLI it loads different types of CLRs like the dotnet full framework as they call it or Mono or the core seal are that the new cross-platform sealer and it's heavily inspired by what katana did before Okay So the architecture for isn't five

Pretty much looks like this. Yeah, so there's a host that runs DNX Which is the dotnet execution environment, which will soon be renamed to something else in RC 2 and DNX runs your web server and

inside of the web server you have the middleware pipeline and Again at the end of the pipeline typically is an application framework, which is in the Microsoft world MVC 6 the other notable thing is that now di is baked into the architecture and Many of the security services you will get over di now as opposed to you know, kind of wiring them up or

instantiating them or Configuring and so on. Okay, so that's that's the the idea So on top of that we have a new security architecture as I said Everything is now based on on claims

So there's this class called claims principle Which was introduced with dotnet 4.5 in the framework and that is now the new base class for everything Okay, so every application will be based on claims based identity There is no more custom eye principle. So if you are having investments into your own eye principle identity Implementations they won't work anymore. You need to be running on claims principle now, okay

All of the runtime services are now implemented as middleware like authentication, you know cookies external authentication Couple of other things and as I said

Many of the security related servers are now coming from dependency injection like Logging and encoding and anti forgery protection and these things There's a brand new data protection API, which is really good There's a brand new authorization API, which is even better and Barry will talk about these things in more detail

They are really good and nice to use so Yeah, the other thing that's new from a security point of view there's a new class called HP context I mean, it's the same name as before but it's different and When we have a look at that

You know request response and so on what you would expect but the thing we really care about is now this guy The authentication manager so that is now baked into the runtime a thing That you talk to when doing anything authentication related

so, you know before back in the days there was the forms authentication module which had its own API or The session authentication module or the WS Federation authentication module and they had all this that their own API's Now there's only one API now and that talks to the so-called authentication middlewares

What's the authentication manager It's basically a class that has you know Security gestures on it. Yeah sign in sign out, you know challenge Authenticate and so on

So the idea is now that you know All of the low level authentication details are implemented in this thing called middleware You don't have to know exactly how they work internally But you're calling maybe the authenticate method and that dispatches the right middleware to do its job Okay And that obviously gives you things like, you know in the future new middlewares can come up new authentication providers

Whatever your application doesn't care as long, you know as you can just call authenticator challenge or whatever so that is like The guts of it. Yeah, you're writing your applications. You have a new HTTP context class It has the dot authentication property and from there you control all of the authentication related things

Cool so let's just do that I guess Let's have a look how that looks like So here's an ASP.NET 5 bare-bones Application and for those that did katana you will see the Delta is pretty small for those who haven't done katana

This is all new So there's a startup class think of the startup class as the new global ASA X or auto exec But if you're even older than that And It basically is the first thing that runs in your web application and it wires up the pipeline

Okay, so by default the pipeline is empty. There's nothing in it No And then you start wiring up the things that you that you use and there's this thing called configure method Yes, the I Application builder which is your pipeline and then you start, you know wiring up middleware and there's a pattern

It's called app dot use middleware one, two, three, whatever and they run in the pipeline in the order you wire them up The other thing which is new for katana people is this thing called configure services That's the DI system for it here. You put stuff into the DI container for example Data protection. Yeah, so you need data protection at some point in your application

Somebody you've configured it here put it into the eye and whenever you need data protection, you just get it from there Or authorization for example is another example for that Okay, what else do we have We have controllers, here's our home controller, you know, that looks pretty much like it did before

There's still an authorized attribute. We'll get to that in a in a in soon But right now what it does it still does the same thing as before it basically means I don't allow unauthenticated access to this controller

What else do we have? We have an account controller which has a login method and a logoff method and we have we have a few a Login view okay, which we're going to use later on to to implement authentication So when I run that now and try to access the secure

action method That's what happens now by default nothing. Okay. Why well because it's it's it's it's secured And I'm anonymous. Yeah, so when we look at the actual HTTP

You see we're getting back a 401 unauthorized Okay, so in other words right now There's nothing in the pipeline that knows how to deal with authenticating users. And that's the thing we're going to add now Let's do that So another thing that might be new for you is desk this class called project or Jason, which is pretty much the

Replacement for packages dot config. Well, it's more than that but part of it. It manages your dependencies. Yeah, and there's a middleware That deals with cookies. So let's do that first. Let's sign in a user with a cookie. Okay, so

We're gonna add that We're now going to our Pipeline so one thing is important. It's order. So you're creating a linked list of middlewares in your pipeline So you want to make sure that the cookie stuff runs before your application? Okay, that's just a common mistake that some people do so you want to run it before?

MVC or if you want to run it before static files, then even your static files are protected by the cookie Okay, so let's do it here App dot use cookie authentication and Then you pass in some configuration options

That's another nice pattern that got introduced in a speed net that you have an action of option so that Navigates around the problem that you you know, don't need to know where the namespace is But it's options class listen that's going away as well. So what does cookies do? Well, you know

You see what you would typically do with a cookie like what's the cookie name the cookie, you know Is it HTTP only, you know all these things? So what you what you typically configure first is the so-called authentication scheme so in katana and also in a snit 5 you can have more than one authentication method living at the same time in your

application which is a huge thing because You know back in the days there was you know in in the conflict authentication mode equals forms or windows And you had to choose what what do you want right now in this new world? You can have more than one. Yeah, so you but if you have more than one everyone needs it

A name so to speak. Yeah, so you can distinguish between them Let's first call this cookies What else can we do we can say options dot login path, so if authentication is required Where is the login page? No, and that's a thing called a path string

Let's do slash account slash login Another nice thing is There's also now an access denied path So maybe you remember back in the days when a user logged into a speed net And he hit a page which he wasn't allowed access to what happened

Back to the login page right because that's the right thing to do right you just log in again. No, maybe not So now there's a there's a condition where a student said, okay, you are already authenticated But you're trying to do something which is not allowed. Let's bring it to access denied instead of login

Now which you know is an improvement Path string, you know, whatever account flash forbidden Another thing that is conceptually different

You can now control should this middleware run Directly on the way on the way in for example Like validating your cookie turning the cookie into an identity and on the way out For example redirecting you to the login page and that is called authentic care automatic authenticate which is the way in and automatic authenticate sorry challenge

Which is the way out and they are both turned off by default So you have to turn them on otherwise this thing does nothing. Okay. Why are they turned off by default? I guess that when you start adding more than one authentication method you don't accidentally, you know

It's the safe default I guess right No, no, no No, it's still false I don't come I think it's fine No Okay, cool. So now we have cookie middleware. We have an authorized attribute

So let's say let's let's let's see what happens now, so I'm going again to my to my secure action What's happening now is well two things are happening a I get redirected to the login page and this return URL thing

Gets appended to the URL so I know afterwards where to go back to after the authentication has happened But that's pretty much like forms authentication used to be it's just the modern version of that. Okay So on the account controller now your joy your your job is to validate the user's identity, you know

Don't do that but good enough for now So I said earlier everything is now based on claims So in other words, you know, you know, you know who the user is and then you now decide which which identity data of the user

I want to remember across post bags. Yeah, so back in the days again forms authentication The only thing you could remember was the user name Yeah, and now you can do whatever you want. Don't go crazy. But you know, you can do whatever you want So let's create a new list of claim and you know do a new claim

There's a very important claim called the subject claim, that's your you know, your user ID your unique identifier for the user You know, maybe you want to have a display name Dominic Maybe you want to have an email address, whatever typing and standing is hard

And you know a role why not a role? Yeah roles are cool like this

and Claims identity ID equals new claims Identity you pass in the claims that you just created and you know, you give it some Some authentication type like password now or two-factor authentication, whatever that's up to you. It's just a string

and now the new authentication manager comes into play so often HP contacts dot authentication dot sign in async So what you now do is basically you tell The system so to speak sign in this user Okay, but you have to you know, remember we can have more than one authentication method now

So you have to tell them which middleware should sign in the user and we call this thing cookies Okay, and we pass in a claims principle that wraps our ID and that's async and

That's how you now sign in the user okay, so what happens is now that this claimed identity will be turned into a cookie and every time the cookie comes back into your application it will be Rehydrated into the claims identity and your code has access to it Another really nice addition is now so what would you do now after you're done?

Typically Redirect to the return URL, but you should make sure that it's a local return URL, right? So that nobody has hacked up your query string parameter and now it points to you know Something dot I don't know dodgy, so there's a new thing called a local

Redirect result Which basically does that check for you? Okay, so If it's not a local URL, I guess it throws an exception if it is it does the redirect for you. Yeah, which is quite nice

Cool. So now we're going back to slash home secure. So what's happening on slash home secure? That's the other side of the coin so to speak now that the consumer of identity and now Since everything is based on claims principle The user property of the controller is a claims principle as well as the user property on the view

Which makes it really natural now to interact with that. It's just user dot claims Okay, so that's how you get back to the to the claims in a spin at five so By the magic of Roslyn, I don't have to compile now. I just save the file and

log in my super secret password algorithm should kick in The magic of rosin as well and here we are Okay So now we are on our page and now all of the rest of our application now has access to the identity

established by the login page Okay, very similar to what we did before just modernized based around claims based around middleware and so on Any questions on that?

Yeah Yes, they are basics before encrypted Yes, they are they are encrypted and signed or are yeah in that order, right?

And the data protection API is used for that which will Barry will talk about much more later on. Yes They are any other question like on that model That's that that's the model now for for going forward. Yeah, you you want to do something you add a middleware That's how it works. Basically. Yeah. Okay, cool Let's do the next thing which is you know, what what what people you know, like right after day, you know

Have reached all the goals in life. The next thing they want to do is social authentication, right? So let's do a Google login or a Facebook login or whatever Yeah And Microsoft ships actually with in the box with support for Google Facebook Twitter and Microsoft account

And again as you would guess they are just middlewares. Okay, so you want to add support for that add a middleware for that So Let's do that Let's do that. Let's add Google Google and then we do app dot use

Google Why is there no Google? So the same idea you need to give that middleware a name. Okay options authentication scheme is

Google now The Google middleware only implements the protocol to talk to Google once we are done

We want to sign in the user again locally into our application and that is done by the cookies middleware. So that is now called Sign in scheme. So that basically means When you are done hand over whatever came back from Google To the cookies middleware. Yeah that that was used to be called sign in as authentication type for the immediate shorter. That's good

You Have to register your application with Google to be able to do that. I just did that Early on and they give you a client ID and the client secret and that you shouldn't put that into you know in clear text into your config files, but there's also a

Yeah, you shouldn't put it into the config file there are config files Yes But there's also a new way to do you mention that the user secrets There's there's a new feature in a Smith 5 which allows you to get these secrets out of your local

Configuration so like if you check it into github and so on that you don't check in your passwords and so on happened before right Okay so if we look If you look on our login page, there's a link called sign in with Google and this goes to an action called Google

Oh, you know what? I actually forgot to show something else Log off we're gonna do that quickly because it's a one-liner So, how do we get rid of the local cookie by calling await? HTTP context authentication dot sign out Async and we pass in the name of the middle where that should do the sign out

Return redirect like this Okay, let's add a new action for Google Let's call that Google and you know in in the spirit of of the API you can you can now do

HTTP context dot authentication dot challenge and pass in the name of the middle where That you want to use now to challenge the user to send the user to a different server to authenticate

with With you know, in that case Google, yeah, so that there's an issue here What will happen is now that you know, we will send the user to Google We'll sign in and we'll come back to our application then the Google middleware will catch that callback and then we'll send him back to the page he came from and

What will happen next? We're gonna send him to Google, right? So that's like an infinite loop here So you have to tell the middleware where to go after you're done with the whole Google Handshake and there's a class called proper authentication properties and

Here's a thing called redirect URI and we want to go when we are done. We want to go to home slash secure Okay, so we could pass that in here. I think No, there. There's an easier way to do that. And that's an MBC feature not not an 8.5 feature There's a thing called a challenge result

And here you pass in I think the properties first, right? No Google and then The properties okay, and that gives you like your you know, the usual action result programming model But it really what it really does is it it calls this here. Okay

So let's run that and see if it's working so secure Sign in with Google Hey

Google Yeah, yeah, yeah and here we are Okay, so now our our user our user property now has the claims coming from Google. So, you know

my first name last name full name email address and the most important thing my Google Plus profile page Okay, so that's basically, you know, and if you now would want to support Facebook authentication You would exactly do the same thing, right? You would have a face login with Facebook link

Called challenge pass in Facebook, you know, and that's how it works. Okay. Oh signing out maybe log out and that's That's a configuration thing on the middleware So by default Google gives you back first name last name email address and the Google Plus profile

But you can configure for more and then Google will show you like a consent screen saying are you okay handing out your? Telephone number to Dominic's application or something like that. Yeah, you yes that that's the default. Yeah So

Let's just do that again This this constant screen you only get when you're running on localhost I don't know why Google is doing that But once you would deploy your application to a real server that that screen wouldn't come again and again and again It just comes once on the first time

so, you know What's different now? Well, first of all, the claim types are totally different, right? I mean before that we had these nice little claims like name and given name and email and so on And now we have this weird looking claim types here which come from a you know, look like as they come from from a bygone era

So that's the claims that the middleware produces for you and you you know, you can't directly you know That's just the way this yeah So you might not like this claim types. Maybe you you don't need all the extras data Maybe you don't you maybe you don't care about my Google Plus profile. Yeah, maybe you know

You want to do some post? Processing on these claims before the act before the user actually becomes signed in into your application Maybe you want to do something like, okay This is Dominic. Okay. He has a Google account That's that's good. But now I want to make him my user because I need his credit card number or you know

he he has the register first before he can become my user and That might involve showing a UI yeah multiple UIs maybe a whole registration workflow things like that And there's a pattern that is built into the the middleware Did the authentication middleware or the authentication infrastructure that allows you to do that?

Okay, and that is you know, I want to show that to you because that is just a fundamental thing So in essence what's happening? Yeah with what what we just did is we are now using this thing called Google to directly produce our

Trusted application cookie, right? So what we want to do basically is you want to have something in between? Yeah before going to from Google to us There should be some layer in between and the way this works is it looks weird at the first time you're doing it but it's actually a nice pattern you're adding a second cookie here and

This time the cookie Has a different name. It's let's call it, you know temp temporary cookie, you know and Quite deliberately, yeah, we also do

Options dot automatic authenticate Equals false, even if it's the default it might change we never know Yeah, you don't want that this guy gets automatically authenticated. You want only you want to use it as a temporary Container for claims so to speak and then you tell the cookie middle added the Google middleware

Use this cookie instead our temporary cookie don't jump directly to our trusted application cookie, okay So Let's go to the account controller Let's do this. Let's add a new action method Let's say for registration. Okay. Let's call it register and

Instead of going back to home secure. We go to account register now like this and now we can say, you know, what's our external identity and now the that the last of the

Methods come into play on authentication manager. No, not this guy HP contacts dot authentication dot Authenticate async and you say you know what? Let's have a look if there's something in our temp cookie Yeah, that means somebody just came from from Google and now we want to inspect that identity coming from Google before we make

The transition to our real identity our application identity. Yeah, and that is Async as well So and what's coming back here? What do you think? It's a claims principle

Okay. So now what you would do is yeah something like, you know Check the ID of the external user, you know go to your database See do we know that user already if yes, let's map him to our user if it's a brand new user Yet, let's show him the register UI and you know make him type in all kinds of things

You might want to use the the Google claims to pre populate the form Yeah for you know, because being nice, you know, like first name last name and these things are already filled out But at the end of the day, this is just a temporary container for identity And when you're happy with that, you just sign the user in locally as we did before

So I just copy that code from here like this Okay, so maybe you know our our internal user ID stays the same, but maybe we want to source The name from

From Google Claim types dot name dot value something like this And maybe the email address would also come now from Google like this. Okay

So now we sign in the user locally and don't forget we throw away the temporary identity So we say authentication dot sign out a sink temp Like this and then we say a return we direct

Redirect to slash home secure Make sense So that's your interception point so to speak. Yeah, and since this this thing is in the cookie Yeah, this could be now, you know Multi a multi page step-by-step like a wizard Maybe you always have access again to the to the external identity and when you're done

You throw away the external one and you move him to your own identity Cool, that should work Let's try it. So let's do secure

Sign in with Google and what now what we now should see is basically This again And Yeah, here we are our own identity, but with these claims now coming from an external provider Okay And that's the general pattern you want to use if you want to do external authentication in your in your applications

cool So, let's go Where are we? Oh One thing I forgot to mention claims transformation That's another you know common thing to do and it allows you to

To modify claims of the user on the fly So we put in some claims of the user into the cookie, right? But these are more like long-lived claims because if the claims would change you would have to reissue a new cookie all the time Which doesn't really make sense. What you can also do is

You can per request run some logic that looks at the incoming claims You Know they pass you in the authenticated user and you are supposed to return another claims principle And then you can per request amend claims. For example, if that's something you want to do now, so the idea is that you return

a user Task from Result user and in the middle, you know, you can say user dot identities Dot add

Claim Why don't I get intellisense? I don't know it's weird new claim, you know now date time dot now dot to

String like this. Okay, that should work. Why doesn't it work? When you link really user dot identities

dot first dot add claim Cool, you know if we now log in you should see that there is a claim added on the fly that your application logic

We'll see but isn't really part of the cookie Yeah, so he hasn't if you have a now claim now, which you know gets updated every time okay, so that's about

The built-in, you know the social authentication Many of these social providers they abuse OAuth as an authentication protocol and as we all know OAuth isn't an authentication protocol

So but you know, it turns out you can if you do some propriety things to it You can turn it into something that is similar to that so that's what they all did so it turns out that the github authentication protocol is not the same as the Microsoft one or the Google one and so on but they are all very similar but it was a real pain in the past to write a new authentication middleware because

They differ for 90% It was the same and the last 10% were different parameter names and things like that So another new thing in 8.5 is the OAuth base middleware They call it and it provides you with the 90% and you add the 10% to it

If you want to adapt to another authentication provider and hopefully you never have to do that because there is a community project here Which you know has added a lot of the the the usual ones I mean untapped is missing so far, but we'll get to that as well. No So yeah, that's another new thing

Cool so going forward ASP.NET 5 is the brand new framework to build modern applications, right? So we are building web APIs with that we are building web apps with that which should be usable by Browsers and native apps and you know all these things and you've just seen that you couldn't you can still you know

Kind of put all that authentication logic and account linking and all of that in your local application But once you have more than one application you're starting duplicating this code again And the common pattern for that is obviously to factor out the authentication to a separate authentication service

Where you can you know hoist up that logic to a central place and all of your applications will just use that You know authentication as a service will give you a single sign-on Across your application suite and all and all that stuff, okay so The protocols that I use for this modern type of authentication infrastructure

they are called OpenID Connect and OAuth2 and These are the two main protocols today Yeah that you should know and learn a little bit and and use to build, you know These types of applications where you have multiple types of clients talking to multiple backends APIs

Delegation of tokens and all these things. Okay, in other words ASP.NET 5 to be ready for that Needs to have middleware that supports that right and they do So that's another, you know big thing. There's the OpenID Connect middleware, which is you know The authentication protocol to rule them all so to speak. Yeah

That's the way how you when you're building your own identity platforms would do authentication Same scheme, you know app.useOpenID Connect authentication you pass in the scheme you pass in the sign-in scheme You tell him to do it automatically Yeah, and then you tell him that that's the authority parameter here. Where is your authentication service?

Yeah, and then this thing just goes off and when it comes back it sends you a token and here There was the question you can specify. What do you want to know about the user? It's email address his first name his last name and so on So that's the authentication side the first hop so to speak when the user starts your application

Totally independent of is it a web application is the native one. Is it a JavaScript based application? That's the first hop and Once the user is authenticated you want to talk to API's which means you want to delegate that identity To the back end and that's what OAuth is all about And that's the middleware in 8.5 that does that it's based on a token format

Which is the most common token format these days called chase and web tokens and you know, you see the pattern here authority Automatic authenticate automatic challenge and then it just does its work the token comes in The token gets turned into a claims principle and your API's have access to that

Okay so That is the consuming side of These protocols now What about how to issue these tokens how to authenticate these users and create these tokens that your applications can?

consume For those people who did katana there used to be an offer an OAuth authorization server middleware, which which did exactly that This has been discontinued And there's a project called identity server, which I might be involved with which is the replacement for that Okay, that's now the official

recommendation to replace the old katana token issuance infrastructure and Identity server was working for the for for a couple of you know for for the last year already on a spin at five But it wasn't running on the new sealer that the core sealer as they call it Which gives it a cross-platform features and so on and Brock and I over Christmas basically

Ported identity server over to the core sealer it's now called identity server for as opposed to free which was the you know, the katana version and You know, it's released or published as a beta one since

Beginning of the week. So if you want to implement these architectures and you need the issuing side of tokens That's now the recommended way of doing that Okay, so as a world premiere to be honest there because it's the first time I'm showing that life Let me quickly show you how I then deserve a for looks like for a snut five

Here's the project and here's a host here's a startup file as you would imagine In configure services you add identity server to the DI container because it provides services to the application you do some configuration here You configure your clients your scopes and your users and then in the configure stage is just say use

identity server and now you have a fully spec compliant actually even Officially a certified implementation of OpenID connect and OAuth 2 No, and it's a native ASP net thing so you can host it in any way as you would host

ASP net what we also published this week is A sample solution that shows you at least for now all of the stuff we support right now We which types of clients we support, you know all kinds of console clients

MVC client JavaScript clients and so on and They are pre-configured to just run against The standard identity server from from github and again same idea in the startup file Do you have the OpenID connect middleware? Which connects to identity server basically says hey?

I want to have this user give give me his profile his email address his roles and all these things and when you run that And the code of that application looks very very similar to what we just wrote this time. You press the secure button and you are now Brought to identity server, which is your identity platform that you use to provide identity for your applications

You look in you could wire up your Google authentication and your Facebook and so on but let's just use Bob And we are back Okay Same technology what we actually just call under the covers was challenge

With you know, the name of the OpenID connect middleware and that's that's it the API side of things Yes, there's a web API here You know that in the new world web APIs are done with MVC 6 as well. There's no separate web API Product anymore. It's just called MVC 6

two things here that you that are new one is the Poor the course support for a web for web API. So you think that's how you wire up your cross-origin policies and here's the middleware which basically just validates the tokens and again, you know reason you

Rehydrate so to speak to the claims principle. Oh And the controller maybe as the last thing Again, since now the user property on the API controller is a claims principle. That's how you access the claims Now it's all become much easier So if you call the API what this API is doing it just echoes back the claims

So just to prove it works and that's what it does Okay So that is token based authentication. As I said identity server being the replacement for the old one and The middle wares to consume these tokens which you know build in

Next thing just as a cliffhanger maybe to next the next session of Barry data protection is new Yeah, so the data protection in a spinet a spinet old was a bit of a sad story, right? There was this machine key thing and you just put a static

Clear text machine key in your web config and that basically controlled At the end of the day all of the security of your application, right? If I could steal your machine key, I could create cookies Which would be accepted by your application and I would be you know, just in yeah, and you know

There are even websites out there which say like hey use our website We generate machine keys for you Yeah, and maybe you want to put in the URL where you're gonna use that machine key just you know for the record You would be amazed what turns up when you do this here in Google

How many web conflicts are out there indexed by Google and you can just take the machine keys So who thought this would be a good idea? I don't know. Yeah The good news is that's gone right and Barry has all the details The last thing how are we on time? Oh

Yeah, the last thing which is my favorite feature is authorization. So You know we know all the authorized attribute and we know that it's really really ugly to sprinkle your code with authorized roles equals FUBA and they're all hard coded strings. And if they change you become the master in search and replace. Yeah, and

And so on so there's a complete new authorization API really nice That still exists I I heard that Couldn't get rid of because of backwards compatibility so role still work I wouldn't recommend using them in that way at least there that you

Hardcode them into your controller logic. Yeah, but they still exist but them Modern replacement for that is called policies where you basically compose Identity requirements together like you said and this user must be authenticated to start with

He must be in a department called sales He must have a status of senior and he should be over 18 things like that And then these become reusable policies that now you can put onto your controller okay, so you have one place one central place where you have all your policies and then you can use them from various places inside of

Your application and that is obviously much a much cleaner approach and the one that I am particular Proud of or You know like is the new resource-based authorization in a spinet So the the policies are all about who is the user right? He must be over 18

He must be you know senior and so on the resource-based authorization adds another dimension to it namely And what's the resource this user will do work on or you know do actions on? Okay, so the idea is you have a subject that is your user well the subject is many things typically

It's the combination of the subject of the user itself It's maybe also which application this user is using to do its work. Yeah, so maybe your desktop Intranet client is more trusted than the iPad version that coming from the App Store from some third party But it's still the same user. Yeah

And and all the other claims make up the subject identity so to speak And there's an object. That's the the thing in your code that the operation has is being executed on And there's the actual operation Yeah, and both sides subject and object can draw arbitrary data from the DI system

So no need to put everything into the claims, right? That would be madness, but you can have your eye permission repository For example where you connect to your database where you have the permissions table and you can figure out what is this user allowed to? Do in my application and so on so

these three things together Are pretty powerful now and then the idea is you're just writing Code yeah for every resource in your application. You're writing a so-called handler That's the handler taking care of documents that could there could be a customer authorization handler and the product authorization handler and you know

Whatever authorization handler and this is your implementation of the document authorization policy Okay, and what you get passed in is the authorization context. That's the subject Yeah, who is doing that the operation? What is he doing and The document or the resource on which resource is the operation being executed on

Okay, and then you throw that into the eye Yeah, so all of your handlers go into the eye and then in your Code you basically just say authorized async. That's the user. That's the resource the document

That's the operation and then the DI system is clever enough to figure out which Handler in my container takes care of documents Yeah, and it invokes exactly that handler and gives you back a true or false in the end No, and that is you know by a magnitude

Better than anything we had before in ASP.NET and I totally like it Yeah, and then you know you either say yes or no And by the way the challenge result that I showed you earlier is the thing that triggers the forbidden versus unauthorized condition So either go to login page or go to forbidden page or in the API world for all free versus for

one Okay So you like that? No, don't care. We don't do security. Okay Excellent

So we have five more minutes for questions Yeah, which API oh it's called a release candidate there will be no changes anymore

Okay, just one a good one actually Yes Yeah, there will be one change but not a breaking one, right? So yeah, next session is Barry the session after that proc will do an introduction to identity server

So if you haven't seen that and you are intrigued by these token based architectures That's proc who will show you like from scratch how it works any more questions Yeah, what is multi-tenant in your universe

So yeah, I mean that's totally doable right it did the tenant ID becomes a claim typically that that's how people implement it So you bring them to a login page, you know Do you want to have one login page per tenant or it will will there be one login page and regardless?

I mean both is possible But at the end of the day your login typically, you know Something like identity server would figure out the tenant and just put in the tenant ID as an as another claim So your application will obviously like first name last name tenant ID, for example

I mean there are many ways to implement that but that would be one option. Yeah Yeah, that's a sad story The question was what how is Windows authentication fitting in? Windows authentication was always like an odd fish in that in that scenario because it's not done in managed code

It's done in the operating system. Windows authentication is supported. Yeah, it's totally supported And I think it will even show up as an additional authentication method but due to the nature of how Windows authentication works It's still a little bit hard to mix it with arbitrary other stuff because it's it's a bit special

Yes, oh Yes, that's that's what identity server does we have a special token service just for Windows and then then it then Windows becomes just one of your

External authentication methods. Yeah Mark, okay Cool Thank you