Entries:
Comments:
Discussions:

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

ASP.NET Core Authorization with Barry Dorrans

49 minutes, 55 seconds

Download

Right click “Save as…”

In this video, I had the chance to have a look at ASP.NET Core's new authorization model with Microsoft's crack security analyst Barry Dorrans (emphasis crack).  I learned about how to properly configure ASP.NET Core to authorize access to web applications.  I also discovered how to send the correct HTTP response codes for Forbidden and Not Authorized access. It was super enlightening! (There is another part to come).

Tags:

Follow the discussion

  • Oops, something didn't work.

    Getting subscription
    Subscribe to this conversation
    Unsubscribing
    Subscribing
  • Thanks for making auth much more professional and powerful. I've worked with auth since the first membership API and have done custom Auth attributes and custom principals.

    I have clients that would want to change the auth requirements for a section of the app by using an admin page...meaning I wouldn't hard-code the claims/policies in ConfigureServices at startup.  I'm guessing I could build claims/policies at runtime (database-driven) and could dynamically wire them up on startup, meaning if they make changes in the app the app would require a restart to take effect.  Curious, would there be a way to make the changes work without the app restarting (without needing the configuration to be done only in Startup.cs) ?

  • First off, Barry is Hilarious (cannot reproduce).

    Secondly, this is one of the best and most helpful videos I have seen in a *long* time.  

    I spent a couple of days on a weekend trying to figure out how to do this and came out with a hacked-together and mildly incorrect (yet "working") version of Authorization code.

    At the end of all that, I tried to push an update to the github docs and was lightly chastened for my total misunderstanding of the way things work. (If I look back over the conversation in the github issue, as it turns out, by @blowdart himself :))

    This topic is *really* important and in terms of the available documentation it is still difficult to parse out all the things that need to be done, *especially* with the high level explanations with "theoretical underpinnings."

    The "why" of this stuff is critical as well.

    I would love it if the content of the AspNetAuthorizationWorkshop  was somehow folded into ASP.NET Docs repo aspnet/Docs especially considering the workshop will be (mildly) out of date as soon as RC2 ships (at the very least,  namespaces changing to AspNetCore).

    I think I'd also like to see at least another episode around Claims, EntityFramework Authorization, caching of claims/userinfo and,

    How do I ensure performant authorization when using a database? Would I query claims every request? decode decode them from the cookie? Could I trust that? 

    What about database driven policies & claims? Surely there's some way to "build policies from database" as opposed to manually coding them in the Startup.cs?

    What about Authentication with APIs? REST - I've seen some things work with tokens and an authorization header instead of a cookie.

    How about integrating an IDP for example: github/IdentityServer/IdentityServer4 (I'm assuming that IDS4 would just be another ClaimsIdentity)

    Or some other third party SSO?

    Forgive me if ant of this is covered in the last 9 minutes of the chat, I've gotten too excited.

    Any ways, thanks so much Seth & Barry I've really loved this one!

     edit: Ooooh! there's a part 2 coming!!! When?! 

  • Ron OsmoRon Osmo

    I was very happy to see that Barry and Seth are tackling this subject, i haven't seen much since Auth 2.2.1.

    I come from the old school and have built apps for corporate customers with Roles, Permissions and Users. What we used to call Role Based Access Security or RBAC.

    Many questions arise when looking at this new work. How can you give fine grained access security without some permits? Permits usually have ways of specifying what parts of an application you can access, down to which attributes of a data-source you can read and update. These are great pieces of information for an application to have to configure itself correctly. Can this detail be held in a set of "Policy" objects? Or is "Policy" just a piece of code that returns a bool? I would like a web server/controller to be able to pass a full packet of information with permissions arising out of a set of Policy decisions for a client to use if its built properly. The web server / controller can enforce the Policy rules, but how can a friendly client configure itself in a nice way?

    Claims seem to be a great way to configure policy based on what you actually know about a user. Do 3rd party authenticators send claims all the time, do we need to store them in a database or is it handled for us developers within the Core infrastructure? For instance when a user logs in through Facebook, are we given the Facebook groups to which she can post?

    I could see how certifications can be pushed into the "claims" and that can flow through to "Policy". Some other claims are simply appointments. Like:

    In a scenario i am developing for volunteer fire fighters, the "Captain", "Communications Officer" roles etc, are crucial to their team safety. Essentially they are appointments made by some higher authority following extensive workflow, certifications and deliberation.

    Finally I would like to know if we can build mobile apps with similar facility? Can the claims be sent to the web servers/controllers and to the client?

  • blowdartblowdart Peek-a-boo

    @Genesis1:The authorization handlers support DI. So in the construction you'd take an instance of your repository for your rules data, then check it during handle. You'd still have authorize atributes in your controller with hard coded policy names.

    If that's not flexible enough in RC2 you'll be able to change everything with a policy provider. We'll give you the name of the policy from the attribute and you can build the policy on the fly, adding and removing requirements as you see fit.

  • blowdartblowdart Peek-a-boo

    @alexchesser01: Now you're dipping into authentication really. Which wasn't my area *grin*

    I will say the cookies are encrypted and signed with a key generated by asp.net, which rotates (see the Data Protection documentation). So that can be trusted. Now, caching is really application dependent. Some folks don't care, others do. We can't really make that decision for you.

    For REST you ought to be moving to bearer, as it removes CSRF vulnerabilities. The standard approach is JWT and we provide middleware to validate it, but nothing to issue, as again, that depends on your app and situation. We recommend IdentityServer for that, or Azure AD

  • blowdartblowdart Peek-a-boo

    @Ron Osmo:The next section will cover writing policy handlers. Hopefully it will address your questions, but yes, it's basically code that returns Succeed. Or nothing. Or fail. The video will make it clearer.

    If you need something more configurable wait for RC2 when you can write your own policy provider, you get the policy name and return a policy configured as you want, so that would support client configuration.

    As for claims and 3rd party auth, it depends on the 3rd party. The vast majority will, but you're dipping into authentication at this point. Facebook has a concept of scopes, but once you have logged in you would get an access token back which you can use to walk their graph API to get more details. Of course the user can simply refuse to grant you those permissions, they are in control. Google and Azure AD act in much the same way. If you had an identity service provider which fire fighters logged in through it may in turn give you their certifications and roles as claims.

    As for mobile apps, well, not really. How it tends to work is the mobile app does an authentication dance, and then gets a bearer token, which you send with every request. Or the mobile app goes through your web site, which then prompts the oauth dance, your web site gets the tokens and identity back, and then your web site gives your mobile app an identity token, which you marry up on the back end to the identity returned from the oauth login.

  • @blowdart:thanks very much for replying.  I know this will be a very common scenario in the enterprise (like I am).  It would be great if you could make a quick/dirty sample of this (or at least show pseudocode).  I've watched ALL of your videos on this, and I understand DI, but I don't get how you'd do it like you said.

    Thanks.

  • blowdartblowdart Peek-a-boo

    @Genesis1: For DI see the samples at https://github.com/blowdart/AspNetAuthorization-Samples/tree/master/src/AspNetAuthorization

    https://github.com/blowdart/AspNetAuthorization-Samples/blob/master/src/AspNetAuthorization/Authorization/BuildingEntryAsEmployeeHandler.cs takes an EmployeeRepository via DI.

  • @blowdart:

    perfect!  Thanks very much for pointing me to the examples for DI.

Remove this comment

Remove this thread

Close

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.