Die anspruchsbasierte Autorisierung in ASP.NET Kern

Aus meiner persönlichen Erfahrung gibt es nur sehr wenig durch eine richtige Erklärung der Forderungen und wie diese auch wirklich benutzt werden. Also ich werde meine Erklärung durch ein Beispiel. Es nutzt die Standard-ASP.NET MVC-Kern-Projekt erstellt in Visual Studio 2015.

Der wesentliche Sache zu erinnern, ist hier ein Benutzer kann über viele Forderungen. Er kann den Anspruch auf "administrator" und den "Namen" gleich "bhail" etc. Daher auch der Grund, warum verwenden Sie das Wort behaupten. Das interessante an der Sache ist, dass Behauptet werden kann, bereitgestellt von der ASP.Net Anwendung oder auch aus anderen Quellen wie Facebook, Twitter, etc. Dies ist sehr wichtig, da wir mit der SPAs-und Mobile-Apps, die tokens, die wiederum einbetten Ansprüche. Aber das ist für einen anderen Tag.
Im Beispiel unten habe ich geändert, die Standard-AccountController zu reservieren eine Anzahl von Forderungen zu einem Benutzer, wenn Sie registrieren:

    //POST: /Account/Register
    [HttpPost]
    [AllowAnonymous]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Register(RegisterViewModel model, string returnUrl = null)
    {
        ViewData["ReturnUrl"] = returnUrl;
        if (ModelState.IsValid)
        {
            var user = new ApplicationUser { UserName = model.Email, Email = model.Email };
            var result = await _userManager.CreateAsync(user, model.Password);
            if (result.Succeeded)
            {

                await _userManager.AddClaimAsync(user, new System.Security.Claims.Claim(ClaimTypes.Role, "Admin"));
                await _userManager.AddClaimAsync(user, new System.Security.Claims.Claim(ClaimTypes.Name, "Bhail"));
                await _userManager.AddClaimAsync(user, new System.Security.Claims.Claim(ClaimTypes.DateOfBirth, "18/01/1970"));
                await _userManager.AddClaimAsync(user, new System.Security.Claims.Claim(ClaimTypes.Country, "UK"));



                //For more information on how to enable account confirmation and password reset please visit http://go.microsoft.com/fwlink/?LinkID=532713
                //Send an email with this link
                //var code = await _userManager.GenerateEmailConfirmationTokenAsync(user);
                //var callbackUrl = Url.Action("ConfirmEmail", "Account", new { userId = user.Id, code = code }, protocol: HttpContext.Request.Scheme);
                //await _emailSender.SendEmailAsync(model.Email, "Confirm your account",
                //   $"Please confirm your account by clicking this link: <a href='{callbackUrl}'>link</a>");
                await _signInManager.SignInAsync(user, isPersistent: false);
                _logger.LogInformation(3, "User created a new account with password.");

                return RedirectToLocal(returnUrl);
            }
            AddErrors(result);
        }
        //If we got this far, something failed, redisplay form
        return View(model);
    }

Toll ! Wir haben nun Ansprüche gegen einen Nutzer gespeichert. Diese wiederum befinden sich in der persistent store (Datenbank). Die Tabelle XXX _Security_User_Claim. Ich habe XXX als ich-Präfix alle meine Tabellennamen einschließlich der Identität Tabellen, so kann ich mehrere clients, die mit Sicherheit auf die gleiche Datenbank zu vermeiden, hosting-Kosten. Sollte die Tabelle enthält die Einträge:
1 http://schemas.microsoft.com/ws/2008/06/identity/claims/role Admin 2
2 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name Bhail 2
3 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth 01/01/2000 2
4 http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country UK 2

Nun sind wir fertig mit dem, was der Benutzer tun können, die wir brauchen, um unsere Aufmerksamkeit zu, wie der Server verarbeitet diese. Also müssen wir, um Richtlinien zu erstellen. Eine Richtlinie ist eine Sammlung von Forderungen. Also im Systemstart.cs

    public void ConfigureServices(IServiceCollection services)
    {
        //Add framework services.
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

        //Adjustment to params from the default settings
        services.AddIdentity<ApplicationUser, ApplicationRole>()
      .AddEntityFrameworkStores<ApplicationDbContext, int>()
      .AddDefaultTokenProviders();


        services.AddMvc();

        #region Configure all Claims Policies

        services.AddAuthorization(options =>
        {
            //options.AddPolicy("Administrators", policy => policy.RequireRole("Admin"));
            options.AddPolicy("Administrators", policy => policy.RequireClaim(ClaimTypes.Role, "Admin")); //This works the same as the above code
            options.AddPolicy("Name", policy => policy.RequireClaim(ClaimTypes.Name, "Bhail"));

        });
        #endregion

        //Add application services.
        services.AddTransient<IEmailSender, AuthMessageSender>();
        services.AddTransient<ISmsSender, AuthMessageSender>();
    }

Der wichtige Punkt zu erinnern ist, die Richtlinien sind fest verdrahtet. Und Sie sollten die PolicyTypes das sind die gleichen, wie Sie dem Benutzer zugeordnet sonst funktioniert es nicht richtig.
Der Letzte Schritt besteht darin, die Politik gegen die contorllers und/oder Aktionen, die überprüft wird. So in der HomeController, die ich Hinzugefügt habe folgende Richtlinie Überprüft:

public class HomeController : Controller
{
öffentliche IActionResult Index()
{
return View();
}

    [Authorize(Policy = "Administrators")]
    public IActionResult About()
    {
        ViewData["Message"] = "Your application description page.";

        return View();
    }

    [Authorize(Policy = "Name")]
    public IActionResult Contact()
    {
        ViewData["Message"] = "Your contact page.";

        return View();
    }

    public IActionResult Error()
    {
        return View();
    }
}

Dort gehen Sie ! Im Grunde Richtlinien sind Sammlungen von Forderungen. Kontrollen sind gegen die Richtlinien. Und die Forderungen selbst sind zugewiesen an Benutzer. Im Gegensatz zu den Rollenzuweisungen Sie haben jetzt die Kraft und die Flexibilität zu tun, viele zu viele, Genehmigung aus einer Vielzahl von Quellen.