Page 10 - MSDN Magazine, September 2017

Cutting EdgE DINO ESPOSITO
Cookies, Claims and Authentication in ASP.NET Core
Most of the literature concerning the theme of authentication in ASP.NETCorefocusesontheuseoftheASP.NETIdentityframe- work. In that context, things don’t seem to have changed much or, more precisely, all the changes that occurred in the infrastructure have been buried in the folds of the framework so that it looks nearly the same on the surface.
If you look at user authentication in ASP.NET Core outside the comfortable territory of ASP.NET Identity, you might find it quite different from what it was in past versions. ASP.NET Identity is a full-fledged, comprehensive, big framework that’s over- kill if all you need is to authenticate users via plain credentials from a simple database table. In this case, you’ll see that the overall approach to authentication is still based on familiar concepts such as principal, login form, challenge and authorization attributes, except that the way you implement them is radically different. In this month’s column, I’ll explore the cookie authentication API as made available in ASP.NET Core, including the core facts of external authentication.
Foundation of ASP.NET Authentication
In ASP.NET, user authentication involves the use of cookies. Any users that attempt to visit a private page are redirected to a login page if they don’t carry a valid authentication cookie. The login page, after having verified provided credentials, emits the cookie, which then travels with any subsequent requests from that user through the same browser until it expires. This is the same basic workflow you might know from past versions of ASP.NET. In ASP.NET Core, it only looks different because of the different middleware and the different configuration of the runtime environment.
Figure 1 Registering Middleware for Cookie Authentication
There are two major changes in ASP.NET Core for those coming from an ASP.NET Web Forms and ASP.NET MVC background. First, there’s no longer a web.config file, meaning that configuration of the login path, cookie name and expiration is retrieved differently. Second, the IPrincipal object—the object used to model user identity—is now based on claims rather than the plain user name. To enable cookie authentication in a brand-new ASP.NET Core 1.x application, you first reference the Microsoft.AspNetCore.Authentication.Cookies package and then add the code snippet in Figure 1.
MostoftheinformationthatclassicASP.NETMVCapplications stored in the <authentication> section of the web.config file are configured as middleware options. The snippet in Figure 1 com- prehends canonical options you might want to choose. Figure 2 explains each in more detail.
Note that path properties are not of type string. LoginPath and AccessDeniedPath are of type PathString, which, compared to the plain String type, provides correct escaping when building a request URL.
The overall design of the user authentication workflow in ASP.NET Core gives you an unprecedented amount of flexibility. Every aspect of it can be customized at will. As an example, let’s see how you can control the authentication workflow being used on a per-request basis.
Dealing with Multiple Authentication Schemes
By setting AutomaticChallenge to false, you instruct the middle- ware not to react to the [Authorize] challenges by performing, say, a redirect. If no middleware will handle the challenge an excep- tion is thrown. Automatic challenge was the norm in past versions of ASP.NET and there was almost nothing you could do about it.
InASP.NETCore,youcanregistermultipleanddistinctpieces of authentication middleware and determine either algorithmically or via configuration which middleware has to be used for each request. When multiple authentication middleware is used, AutomaticAuthenticate can be true on multiple middleware. AutomaticChallenge, instead, should only be enabled on zero or one middleware. For more details, see bit.ly/2tS07Sm.
Common examples of authentication middleware are cookie- based authentication, bearer authentication, authentication through social networks, or an identity server and whatever else you can ever think to implement. Suppose you have the following code in the Configure method of your startup class:
// This code is for ASP.NET Core 1.x
public void Configure(IApplicationBuilder app) {
app.UseCookieAuthentication(new CookieAuthenticationOptions {
AutomaticAuthenticate = true, AutomaticChallenge = true, AuthenticationScheme = "Cookies",
CookieName = "YourAppCookieName",
LoginPath = new PathString("/Account/Login"), ExpireTimeSpan = TimeSpan.FromMinutes(60), SlidingExpiration = true,
ReturnUrlParameter = "original",
AccessDeniedPath = new PathString("/Account/Denied") });
}
6 msdn magazine