After learning about Authentication in ASP.NET Core, our intrepid reporter Seth Juarez wanted to dig deeper into the ASP.NET Authorization story. In the following video, he speaks with ASP.NET Security Analyst Barry Dorrans. Notes and links from their discussion follow.
Authorization verifies that a user is permitted to access functionality, and requires some form of authentication in front of it. Authentication confirms a user’s identity.
Barry pointed out that many developers in older versions of ASP.NET implemented their own AuthorizeAttribute, and did not fully implement the entire specification. In ASP.NET Core, there is an authorize attribute, and it is a marker attribute that performs no actions.
Source code and samples discussed in this video were previously shared in a workshop Barry presented and are online at: https://github.com/blowdart/AspNetAuthorizationWorkshop
Authorization capabilities for ASP.NET Core are added and configured through the use of the Microsoft.AspNet.Authorization NuGet package. The middleware used to handle cookies is delivered in the Microsoft.AspNet.Authentication.Cookies package. These packages are included by default in the ASP.NET project templates that have security enabled.
There are two HTTP Status Codes that are very important in web security:
- HTTP 401 – Unauthorized: the current user is not authenticated
- HTTP 403 – Forbidden: the current user is authenticated by is denied access
The default MVC templates are configured to redirect HTTP 401 responses to a login page that will then return the logged-in user to the previously unauthorized page.
Cookie Authentication has five options:
- AuthenticationScheme – a string that identifies the authentication provider. ‘Cookie’ and ‘Bearer’ are currently supported
- LoginPath – the path to the login page
- AccessDeniedPath – the path to the error page to show when the user is not authorized to access
- AutomaticAuthenticate – Run on every request and attempt to identify a user from a cookie’s contents
- AutomaticChallenge – Automatically redirect a 401 or 403 error to the appropriate path
There is a new AuthorizationPolicy capability in ASP.NET Core that can be defined to require authenticated users and Barry demonstrated how to use this policy in an MVC filter. The AuthorizationPolicy and Filter can then be bypassed in the controllers that allow anonymous users with the new AllowAnonymous attribute.
Everything about our identity in ASP.NET Core is now claims-based. That is: all attributes of the identity are defined as separate claims on the identity object. Barry went on to explain that a principal can be composed of multiple identities. The comparison is this: a principal is a unique individual but they may have multiple identification cards such as their driver’s license, passport, or employee id badge. Those identification cards are their identity to those issuing organizations, just like your Twitter, Facebook, or Microsoft Account ID.
Barry showed us that the redirecturl querystring passed to our login page needs to verify that the url passed in local to our application, otherwise links could be constructed to bounce through your site that look like your visitors are visiting your application and are actually redirected to somewhere outside of your application.
One authorization strategy that was discussed by Barry and Seth is a secondary authentication when a user attempts to perform a task that requires an additional level of authorization. Instead of simply rejecting a user as not allowed to access and administrative feature, you could configure your application to prompt for a two-factor authentication token or some additional piece of information.
The Authorize attribute now supports defining requirements for access using both roles or a policy. The policies can be defined in code outside of the project and can inspect the identity for claims to compare against or they can execute any arbitrary code to test against.
Barry also clarified that MVC controllers with multiple Authorize attributes decorating them are all required to be met in order to grant access to the controller’s actions.
More details about ASP.NET Core security can be found at docs.asp.net
In the next video in this series, Barry and Seth will discuss more complex authorization scenarios.