Autorisatie op basis van resources in ASP.NET Core MVC

In dit artikel wordt beschreven hoe u gebruikers machtigt voor toegang tot app-resources.

In een app wordt een resource meestal vertegenwoordigd door een C#-klasse die gegevens bevat die zijn opgeslagen in een verzameling, zoals een byte[] matrix. De klasse bevat meestal aanvullende metagegevens met betrekking tot de resource, zoals een unieke resource-id, datums, auteurs, brongegevens en een beschrijvende naam voor weergave in een gebruikersinterface. De verzameling met resourcegegevens wordt meestal geladen vanuit fysieke bestandsinhoud, een cloudopslagobject, een in-memory object of gegevens uit een database.

Autorisatie op basis van resources vereist speciale aandacht in ASP.NET Core apps. Kenmerkevaluatie vindt plaats vóór gegevensbinding en voordat een actie wordt uitgevoerd waarmee een resource wordt geladen. Declaratieve autorisatie met een [Authorize] kenmerk volstaat niet voor autorisatie op basis van resources. In plaats daarvan moet de app een aangepaste autorisatiemethode aanroepen, een benadering die imperatieve autorisatie wordt genoemd.

Voorbeeldcode bekijken of downloaden (hoe u kunt downloaden).

Een ASP.NET Core-app maken met gebruikersgegevens die worden beveiligd door autorisatie een voorbeeld-app bevat die gebruikmaakt van autorisatie op basis van resources.

Voorbeelden in dit artikel maken gebruik van primaire constructors, beschikbaar in C# 12 (.NET 8) of hoger. Zie Primaire constructors declareren voor klassen en structs (C#-documentatie) en Primaire constructors (C#-handleiding) voor meer informatie. Voorbeeld-apps die bij het artikel horen dat gericht is op versies van .NET ouder dan .NET 8, gebruiken constructorinjectie.

Imperatieve autorisatie gebruiken

Autorisatie wordt geïmplementeerd als een IAuthorizationService, die is geregistreerd in de serviceverzameling bij het opstarten van de app op het ASP.NET Core framework. De service wordt beschikbaar gesteld aan klassen en acties via afhankelijkheidsinjectie. De volgende controller injecteert ook een documentopslagplaats, die de ontwikkelaar maakt en registreert in de servicecontainer om documentbewerkingen te beheren:

public class DocumentController(IAuthorizationService authorizationService,
    IDocumentRepository documentRepository) : Controller
{
    private readonly IAuthorizationService _authorizationService;
    private readonly IDocumentRepository _documentRepository;

    public DocumentController(IAuthorizationService authorizationService,
        IDocumentRepository documentRepository)
    {
        _authorizationService = authorizationService;
        _documentRepository = documentRepository;
    }

    ...
}

IAuthorizationService heeft twee AuthorizeAsync methode-overbelastingen. Een van de overloadvarianten neemt een resourcenaam en beleidsnaam als parameter:

Task<AuthorizationResult> AuthorizeAsync(
    ClaimsPrincipal user, 
    object resource, 
    string policyName);

De andere overbelasting accepteert een resource en verzameling vereisten (IAuthorizationRequirement) om het volgende te evalueren:

Task<AuthorizationResult> AuthorizeAsync(
    ClaimsPrincipal user, 
    object resource,
    IEnumerable<IAuthorizationRequirement> requirements);

In het volgende voorbeeld wordt de beveiligde resource in een aangepast Document object geladen. Er wordt een AuthorizeAsync overload aangeroepen om te bepalen of de huidige gebruiker het document mag bewerken via een aangepast "EditPolicy"-machtigingsbeleid. Als authorizationResult.Succeededtrue is, is de gebruiker geautoriseerd voor het document omdat hij of zij het document heeft opgesteld (Document.Author komt overeen met de Name van de gebruiker).

Note

In het volgende voorbeeld wordt ervan uitgegaan dat de verificatie is geslaagd met de User eigenschappenset.

[HttpGet]
public async Task<IActionResult> Edit(Guid documentId)
{
    Document document = _documentRepository.Find(documentId);

    ...

    var authorizationResult = await _authorizationService
        .AuthorizeAsync(User, document, "EditPolicy");

    ...
}

Een handler op basis van resources maken

Het maken van een autorisatiehandler op basis van resources is vergelijkbaar met het maken van een handler voor gewone vereisten. Maak een aangepaste vereisteklasse en implementeer een vereistehandlerklasse. Zie Autorisatie op basis van beleid in ASP.NET Core voor meer informatie over het maken van een vereisteklasse.

De handlerklasse geeft de vereiste en het resourcetype op. In het volgende voorbeeld ziet u een handler die gebruikmaakt van een SameAuthorRequirement vereiste en een Document resource:

public class DocumentAuthorizationHandler : 
    AuthorizationHandler<SameAuthorRequirement, Document>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                                   SameAuthorRequirement requirement,
                                                   Document resource)
    {
        if (context.User.Identity?.Name == resource.Author)
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}

public class SameAuthorRequirement : IAuthorizationRequirement { }

Stel in het voorgaande voorbeeld voor dat SameAuthorRequirement een speciaal geval is van een algemenere SpecificAuthorRequirement klasse. De SpecificAuthorRequirement-klasse (niet weergegeven) bevat een Name eigenschap die de naam van de auteur vertegenwoordigt. De eigenschap Name kan worden ingesteld op de huidige gebruiker.

Registreer de vereiste en verwerker in Program.cs:

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("EditPolicy", policy =>
        policy.Requirements.Add(new SameAuthorRequirement()));

builder.Services.AddSingleton<IAuthorizationHandler, DocumentAuthorizationHandler>();

Zie Beleid gebaseerde autorisatie in ASP.NET Core voor meer informatie over het maken van autorisatiebeleid.

Operationele vereisten

Als u beslissingen wilt nemen op basis van de resultaten van CRUD-bewerkingen (Maken, Lezen, Bijwerken, Verwijderen), gebruikt u de OperationAuthorizationRequirement helperklasse. Met deze klasse kunt u één handler schrijven in plaats van een afzonderlijke klasse voor elk bewerkingstype. Als u deze wilt gebruiken, geeft u enkele bewerkingsnamen op:

public static class Operations
{
    public static OperationAuthorizationRequirement Create =
        new OperationAuthorizationRequirement { Name = nameof(Create) };
    public static OperationAuthorizationRequirement Read =
        new OperationAuthorizationRequirement { Name = nameof(Read) };
    public static OperationAuthorizationRequirement Update =
        new OperationAuthorizationRequirement { Name = nameof(Update) };
    public static OperationAuthorizationRequirement Delete =
        new OperationAuthorizationRequirement { Name = nameof(Delete) };
}

De handler wordt als volgt geïmplementeerd met behulp van een OperationAuthorizationRequirement vereiste en een Document resource:

public class DocumentAuthorizationCrudHandler :
    AuthorizationHandler<OperationAuthorizationRequirement, Document>
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                                   OperationAuthorizationRequirement requirement,
                                                   Document resource)
    {
        if (context.User.Identity?.Name == resource.Author &&
            requirement.Name == Operations.Read.Name)
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }
}

De voorgaande handler valideert de bewerking met behulp van de resource, de identiteit van de gebruiker en de Name eigenschap van de vereiste.

Uitdagen en verbieden met een beheerder voor operationele middelen

In deze sectie wordt uitgelegd hoe de resultaten van de uitdagingen en verbodsacties worden afgehandeld en hoe uitdagingen en verboden van elkaar verschillen.

Wanneer autorisatie mislukt maar de gebruiker is geauthenticeerd, kan de app een ForbidResult teruggeven, waarmee authenticatiemiddleware wordt geïnformeerd dat autorisatie is mislukt. Geef een ChallengeResult terug voor niet-geauthenticeerde gebruikers. Voor interactieve browserclients kan het handig zijn om de gebruiker om te leiden naar een aanmeldingspagina.

Note

In het volgende voorbeeld wordt ervan uitgegaan dat de verificatie is geslaagd met de User eigenschappenset.

if ((await _authorizationService
    .AuthorizeAsync(User, document, Operations.Read)).Succeeded)
{
    return View(document);
}
else if (User.Identity?.IsAuthenticated ?? false)
{
    return new ForbidResult();
}
else
{
    return new ChallengeResult();
}