ASP.NET 5 Identity 3 and new authentication / authorization toolkit

Life in Las Vegas is not limited to gambling. Despite the glory of the gambling capital, events are taking place here entirely from other spheres of life. In particular, the annual DEVIntersection conference, which this year was attended by a team of our developers. And here we want to talk about all the most important and interesting things that they learned at the conference.

ASP.NET 5 Changes

In the context of ASP.NET 5, all components of the stack have been updated or completely rewritten. Changes are not spared and ASP.NET Identity, which can not but rejoice. In particular, the authorization system has been updated, and these are really qualitative changes (IMHO). Next, we consider exactly what changes were made to the authentication and authorization systems.

ASP.NET Identity

On Habré was already an overview article on the topic of ASP.NET Identity, so skip the introductory part.

ASP.NET Identity provides tools for working with users and their authentication. This system consists of the Microsoft.AspNet.Identity library with a description of the main classes and abstractions in the form of user store interfaces, etc. Microsoft.AspNet.Identity.EntityFramework is a library that contains the user / role implementation and repositories based on the Entity Framework 7.
')
The first thing you want to pay attention to is the lack of interfaces for users and roles. Identity does not dictate to us what our user should be. When setting up, it is enough to indicate which user classes and roles we want to use. This is achieved due to the fact that the UserManager class delegates the user’s read / write properties to the repository. For example, such operations of the UserManager class as GetUserName , SetUserName and ChangePassword
ChangePassword
lead to calls of the same type from UserStore.

The repositories of users and roles do not have to describe all possible operations. In one application, a user only needs to have a name, password and the ability to log in using them, while in the other one it is necessary to have various authentication options and support a lot of other possibilities. For our application, we just need to choose the appropriate storage interface and implement only it.

List of user storage interfaces:

• IUserLoginStore
IUserRoleStore
IUserClaimStore
IUserPasswordStore
IUserSecurityStampStore
IUserEmailStore
IUserLockoutStore
IUserPhoneNumberStore
IQueryableUserStore
IUserTwoFactorStore
  
  In the simple case, we only IUserStore
IUserStore
and IUserPasswordStore .
  
  • IUserStore - user name and ID management.
  • IUserPasswordStore - set and read the password.
  
  ASP.NET 5 provides its infrastructure for configuring the application pipeline and its services (built-in DI container ).
  
  Connecting services:
  
  

   public void ConfigureServices(IServiceCollection services) { // more here //   Identity services.AddIdentity<ApplicationUser, IdentityRole>() //  UserStore/RoleStore   EF .AddEntityFrameworkStores<ApplicationDbContext>() //     .AddDefaultTokenProviders(); // more here } 

  
  Activation of middleware authentication:
  
  

   public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { // more here app.UseIdentity(); //  Cookie Auth Middleware // more here } 

  
  This is the default setting.
  
  Due to the modularity and use of ASP.NET DI itself, Identity allows you to replace your components without complete rewriting. For example, we want to change password hashing, user validator (verifying uniqueness, etc.), connect our user and role repositories, and also specify your Claim type for storing roles:
  
  

   services.AddScoped<IPasswordHasher<User>, MyPasswordHasher>(); services.AddIdentity<ApplicationUser, IdentityRole>(options => { options.Password.RequireDigit = true; options.Password.RequiredLength = 8; options.SignIn.RequireConfirmedEmail = true; options.ClaimsIdentity.RoleClaimType = "MyRoleClaimType"; }) .AddUserStore<MyStore>() .AddRoleStore<MyRoleStore>() .AddUserValidator<MyUserValidator>() .AddDefaultTokenProviders(); 

  
  
  Many Identity components have a separate extension method for customization, but not all. As with IPasswordHasher , we have no extension method. In this case, to register, we need to register the password hash service before Identity does it.
  
  Configuring Identity is now done using Action, .

, . UserManager , , , , . , IdentityOptions .

Identity: Identity 2 , NameNormilized EmailNormalized . UserManager , IUserStore . , UPPER() . , , .

, Identity . / ASP.NET 5. , , , . : , MembershipProvider (.NET 2.0): - , UserManager NotSupportedException .

Action, .

, . UserManager , , , , . , IdentityOptions .

Identity: Identity 2 , NameNormilized EmailNormalized . UserManager , IUserStore . , UPPER() . , , .

, Identity . / ASP.NET 5. , , , . : , MembershipProvider (.NET 2.0): - , UserManager NotSupportedException .



  Next, we proceed to authentication.

  
  In the example above, in the Configure method, we call the app.UseIdentity() extension method. Under the hood of this method, middleware is connected, setting up the authentication cookie pipeline:
  
  

   var options = app.ApplicationServices.GetRequiredService<IOptions<IdentityOptions>>().Value; app.UseCookieAuthentication(options.Cookies.ExternalCookie); app.UseCookieAuthentication(options.Cookies.TwoFactorRememberMeCookie); app.UseCookieAuthentication(options.Cookies.TwoFactorUserIdCookie); app.UseCookieAuthentication(options.Cookies.ApplicationCookie); 

  
  In turn, UseCookieAuthentication connects middleware:
  
  

   app.UseMiddleware<CookieAuthenticationMiddleware>(options); 

  
  To interact with middleware authentication, you must use the AuthenticationManager class, which hangs on the HttpContext . Suppose we do not want to use Identity to manage our users, but prefer to do it ourselves:
  
  

   // SignOut    var authenticationDescriptions = HttpContext.Authentication.GetAuthenticationSchemes(); foreach (var authenticationDescription in authenticationDescriptions) { HttpContext.Authentication.SignOutAsync(authenticationDescription.AuthenticationScheme); } //    ASP.NET    ClaimsIdentity //  ClaimsIdentity     var claims = new List<Claim> { new Claim(ClaimTypes.NameIdentifier, "123"), new Claim(ClaimsIdentity.DefaultNameClaimType, "MyUserName"), new Claim(ClaimTypes.Role, "Administrators"), new Claim("Lastname", "MyLastName"), new Claim("email", "bob@smith.com") }; var id = new ClaimsIdentity(claims, "MyCookiesScheme", ClaimsIdentity.DefaultNameClaimType, ClaimTypes.Role); var principal = new ClaimsPrincipal(id); //  ClaimsPrincipal HttpContext.Authentication.SignInAsync("MyCookiesScheme", new ClaimsPrincipal(id)); 

  
  SignInManager from ASP.NET Identity also operates in approximately the same way. During authentication, we need to indicate with what kind of authentication scheme we log in the user. Based on this parameter, the AuthenticationManager determines which middleware to interact with.
  
  The scheme of work is almost identical to MVC 5 and OWIN.
  
  

  Authorization

  
  If for Identity and authentication, the general principle of use remains about the same, then authorization has undergone much more significant changes. And for the better!
  
  In applications with a large number of roles, there is the problem of using the [Authorize] attribute and checks of the type user.IsInRole . When security requirements change, making changes to the application is an extremely time-consuming and error-prone process. It is necessary to find all the places where this or that role is used, or it is necessary to find and change all the places where a particular function of the application is accessed. Those. authorization code is blurred by application.
  
  Let's get started In addition to checks on user membership, we have new authorization tools in the roles. By default, the [Authorize] attribute now accepts not a list of roles, but “policies”.
  
  (attribute [Authorize(Roles=””)] supported for backward compatibility)
  
  

   services.AddAuthorization(options => { options.AddPolicy("SuperAdministrationPolicy", policy => { policy.RequireRole("Admins"); policy.RequireClaim("adminlevel", "Level1", "Level2"); }); options.AddPolicy("RegularAdministrationPolicy", policy => { policy.RequireRole("Admins"); }); }); 

  
  AuthorizationPolicy contains a set of Requirements (requirements). By default, we have Requirements for checking roles, brands and usernames. You can also describe Requirement as a separate class:
  
  

   public class AdminLevelRequirement : AuthorizationHandler<AdminLevelRequirement>, IAuthorizationRequirement { private readonly string _adminLevel; public AdminLevelRequirement(string adminLevel) { _adminLevel = adminLevel; } protected override void Handle(AuthorizationContext context, AdminLevelRequirement requirement) { var user = context.User; if (user.IsInRole("Admins") && user.HasClaim("adminlevel", _adminLevel)) { context.Succeed(requirement); } } } //  requirement     options.AddPolicy("AdminLevel1Policy", policy => { policy.AddRequirements(new AdminLevelRequirement("Level1")); }); 

  
  In this example, we inherit AuthorizationHandler<> and IAuthorizationRequirement , but this is not necessary. Here, the AdminLevelRequirement describes both the request and the request handler. In the simple case, this is quite a suitable solution. But if you need more flexibility, then we can separate the requirements and processors. The class of our requirement (Requirement) must be inherited from the IAuthorizationRequirement (marker interface), and it will carry only the description of the parameters of the requirement. For example, the administrator level, his access level. In turn, the classes for processing requests inherit AuthorizationHandler<> and contain only methods Handle() .
  
  Example:
  
  

   //    public class AdminLevelRequirement : IAuthorizationRequirement { public string AdminLevel { get; } public AdminLevelRequirement(string adminLevel) { AdminLevel = adminLevel; } } //   public class AdminLevelRequirementHandler : AuthorizationHandler<AdminLevelRequirement> { protected override void Handle(AuthorizationContext context, AdminLevelRequirement requirement) { var user = context.User; if (user.IsInRole("Admins") && user.HasClaim("adminlevel", requirement.AdminLevel)) { context.Succeed(requirement); } } } //     policy.AddRequirements(new AdminLevelRequirement("Level1")); //        services.AddInstance<IAuthorizationHandler>(new AdminLevelRequirementHandler()); 

  
  The handler can return AuthorizationContext.Suceed() or AuthorizationContext.Fail() . If we have described several handlers for one requirement, we can perform them on the principle of OR or AND. For execution in the OR style, handlers can only return Succeed() . If you need AND processing logic, then we can use the Fail() return. Those. if Fail() never called in the handlers, then if any of the handlers are successfully tested, the user will be granted access.
  
  We proceed to use.
  
  Using authorization policies in a declarative way using an attribute:
  
  

   [Authorize("PoliyName")] public IActionResult ActionName() 

  
  An authorization service has been added to the toolkit, which can be obtained by declaring a dependency in its class:
  
  

   //    public class HomeController : Controller { private readonly IAuthorizationService _authorizationService; public HomeController(IAuthorizationService authorizationService) { _authorizationService = authorizationService; } } 

  
  Let's use the service to check the user's compliance with the authorization policy:
  
  

   if (await _authorizationService.AuthorizeAsync(User, "MyPolicy")) 

  
  In addition to security policies, we have access to resources based authorization (Resource Based Authorization). It applies in cases where authorization depends on the object to which access is provided. To use this type of authorization, we need to implement our own handler, which handles a specific Requirement / Policy and resource:
  
  

   public class TenantAuthorizationHandler : AuthorizationHandler<OperationAuthorizationRequirement, Tenant> { protected override void Handle(AuthorizationContext context, OperationAuthorizationRequirement requirement, Tenant resource) { if (requirement.Name == "Update") { if (!context.User.HasClaim("adminlevel", "Level1")) { context.Fail(); return; } if (!context.User.HasClaim("region", resource.Region)) { context.Fail(); return; } context.Succeed(requirement); return; } context.Fail(); } } 

  
  Such a handler differs from the usual only in that it also accepts an instance of the resource to which it is being accessed.
  
  OperationAuthorizationRequirement is the default requirement class that has only the Name property. This class can be used for simple scripts and user access checks for named operations, for example, Read , Update , Delete and so on. Of course, in this case we can also describe our own classes of requirements.
  
  The new approach allows you to centrally manage authorization and minimizes the need to change the code of the main application when changing security requirements. All code with access rules can be put into a separate assembly and encapsulated authorization logic.
  
  Useful links:
  
  • docs.asp.net
  • leastprivilege.com
  • github.com/aspnet/identity
  • github.com/aspnet/security