Autorisation basée sur les rôles dans ASP.NET Core

  • Article
  • 7 minutes de lecture

Lorsqu’une identité est créée, elle peut appartenir à un ou plusieurs rôles. Par exemple, Tracy peut appartenir aux Administrator rôles et User alors que Scott ne peut appartenir qu’au User rôle. La façon dont ces rôles sont créés et gérés dépend du magasin de stockage du processus d’autorisation. Les rôles sont exposés au développeur via la IsInRole méthode sur la ClaimsPrincipal classe. AddRoles doit être ajouté aux services de rôle.

Bien que les rôles soient des revendications, toutes les revendications ne sont pas des rôles. Selon l’émetteur d’identité, un rôle peut être une collection d’utilisateurs qui peuvent appliquer des revendications aux membres du groupe, ainsi qu’une revendication réelle sur une identité. Toutefois, les revendications sont destinées à être des informations sur un utilisateur individuel. L’utilisation de rôles pour ajouter des revendications à un utilisateur peut confondre la limite entre l’utilisateur et ses revendications individuelles. Cette confusion est la raison pour laquelle les modèles SPA ne sont pas conçus autour des rôles. En outre, pour les organisations qui migrent à partir d’un système hérité local, la prolifération des rôles au cours des années peut signifier qu’une revendication de rôle peut être trop volumineuse pour être contenue dans un jeton utilisable par les autorités de service. Pour sécuriser les fournisseurs de services, consultez Présentation de l’authentification pour les applications monopage sur ASP.NET Core.

Ajouter des services de rôle à Identity

Inscrivez les services d’autorisation en fonction du rôle en Program.cs appelant AddRoles le type de rôle dans la configuration de Identity l’application. Le type de rôle dans l’exemple suivant est IdentityRole:

builder.Services.AddDefaultIdentity<IdentityUser>( ... )
    .AddRoles<IdentityRole>()
    ...

Ajout de vérifications de rôle

Vérifications d’autorisation basées sur les rôles :

  • Sont déclaratifs et spécifient des rôles dont l’utilisateur actuel doit être membre pour accéder à la ressource demandée.
  • Sont appliqués aux pages, aux contrôleurs ou aux Razor actions au sein d’un contrôleur.
  • Impossible d’appliquer au niveau du Razor gestionnaire de pages, il doit être appliqué à la page.

Par exemple, le code suivant limite l’accès à toutes les actions sur les AdministrationController utilisateurs qui sont membres du Administrator rôle :

[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
    public IActionResult Index() =>
        Content("Administrator");
}

Plusieurs rôles peuvent être spécifiés en tant que liste séparée par des virgules :

[Authorize(Roles = "HRManager,Finance")]
public class SalaryController : Controller
{
    public IActionResult Payslip() =>
                    Content("HRManager || Finance");
}

Le SalaryController rôle est accessible uniquement par les utilisateurs qui sont membres du HRManager rôle ou du Finance rôle.

Lorsque plusieurs attributs sont appliqués, un utilisateur accédant doit être membre de tous les rôles spécifiés. L’exemple suivant nécessite qu’un utilisateur soit membre à la fois du rôle etControlPanelUser du PowerUser rôle :

[Authorize(Roles = "PowerUser")]
[Authorize(Roles = "ControlPanelUser")]
public class ControlPanelController : Controller
{
    public IActionResult Index() =>
        Content("PowerUser && ControlPanelUser");
}

L’accès à une action peut être limité en appliquant des attributs d’autorisation de rôle supplémentaires au niveau de l’action :

[Authorize(Roles = "Administrator, PowerUser")]
public class ControlAllPanelController : Controller
{
    public IActionResult SetTime() =>
        Content("Administrator || PowerUser");

    [Authorize(Roles = "Administrator")]
    public IActionResult ShutDown() =>
        Content("Administrator only");
}

Dans le contrôleur précédent ControlAllPanelController :

  • Les membres du Administrator rôle ou du PowerUser rôle peuvent accéder au contrôleur et à l’action SetTime .
  • Seuls les membres du rôle peuvent accéder à l’action AdministratorShutDown .

Un contrôleur peut être verrouillé, mais autoriser l’accès anonyme et non authentifié à des actions individuelles :

[Authorize]
public class Control3PanelController : Controller
{
    public IActionResult SetTime() =>
        Content("[Authorize]");

    [AllowAnonymous]
    public IActionResult Login() =>
        Content("[AllowAnonymous]");
}

Pour Razor les pages, [Authorize] vous pouvez appliquer les éléments suivants :

[Authorize(Policy = "RequireAdministratorRole")]
public class UpdateModel : PageModel
{
    public IActionResult OnPost() =>
         Content("OnPost RequireAdministratorRole");
}

Important

Les attributs de filtre, y compris AuthorizeAttribute, peuvent uniquement être appliqués à PageModel et ne peuvent pas être appliqués à des méthodes de gestionnaire de pages spécifiques.

Vérifications de rôle basées sur des stratégies

Les exigences de rôle peuvent également être exprimées à l’aide de la syntaxe de stratégie, où un développeur inscrit une stratégie au démarrage de l’application dans le cadre de la configuration du service d’autorisation. Cela se produit généralement dans le Program.cs fichier :

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireAdministratorRole",
         policy => policy.RequireRole("Administrator"));
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseAuthentication();
app.UseAuthorization();

app.MapDefaultControllerRoute();
app.MapRazorPages();

app.Run();

Les stratégies sont appliquées à l’aide de la Policy propriété sur l’attribut [Authorize] :

[Authorize(Policy = "RequireAdministratorRole")]
public IActionResult Shutdown()
{
    return View();
}

Pour spécifier plusieurs rôles autorisés dans une exigence, spécifiez-les comme paramètres de la RequireRole méthode :

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ElevatedRights", policy =>
          policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));
});

var app = builder.Build();

Le code précédent autorise les utilisateurs qui appartiennent au ou PowerUserBackupAdministrator aux Administratorrôles.

Lorsqu’une identité est créée, elle peut appartenir à un ou plusieurs rôles. Par exemple, Tracy peut appartenir aux rôles Administrateur et Utilisateur, tandis que Scott ne peut appartenir qu’au rôle Utilisateur. La façon dont ces rôles sont créés et gérés dépend du magasin de stockage du processus d’autorisation. Les rôles sont exposés au développeur via la IsInRole méthode sur la ClaimsPrincipal classe.

Nous vous recommandons de ne pas utiliser les rôles en tant que revendications, mais plutôt d’utiliser des revendications. Lorsque vous utilisez des applications à page unique (SPAs), consultez Présentation de l’authentification pour les applications à page unique sur ASP.NET Core.

Ajout de vérifications de rôle

Vérifications d’autorisation basées sur les rôles :

  • Sont déclaratifs.
  • Sont appliqués aux pages, aux contrôleurs ou aux Razor actions au sein d’un contrôleur.
  • Impossible d’appliquer au niveau du Razor gestionnaire de pages, il doit être appliqué à la page.

Les vérifications d’autorisation basées sur les rôles spécifient les rôles dont l’utilisateur actuel doit être membre pour accéder à la ressource demandée.

Par exemple, le code suivant limite l’accès à toutes les actions sur les AdministrationController utilisateurs qui sont membres du Administrator rôle :

[Authorize(Roles = "Administrator")]
public class AdministrationController : Controller
{
    public IActionResult Index() =>
        Content("Administrator");
}

Plusieurs rôles peuvent être spécifiés en tant que liste séparée par des virgules :

[Authorize(Roles = "HRManager,Finance")]
public class SalaryController : Controller
{
    public IActionResult Payslip() =>
                    Content("HRManager || Finance");
}

Le contrôleur SalaryController est accessible uniquement par les utilisateurs qui sont membres du HRManager rôle ou du Finance rôle.

Si vous appliquez plusieurs attributs, un utilisateur accédant doit être membre de tous les rôles spécifiés. L’exemple suivant nécessite qu’un utilisateur soit membre à la fois du rôle et ControlPanelUser du PowerUser rôle :

[Authorize(Roles = "PowerUser")]
[Authorize(Roles = "ControlPanelUser")]
public class ControlPanelController : Controller
{
    public IActionResult Index() =>
        Content("PowerUser && ControlPanelUser");
}

Vous pouvez limiter davantage l’accès en appliquant des attributs d’autorisation de rôle supplémentaires au niveau de l’action :

[Authorize(Roles = "Administrator, PowerUser")]
public class ControlAllPanelController : Controller
{
    public IActionResult SetTime() =>
        Content("Administrator || PowerUser");

    [Authorize(Roles = "Administrator")]
    public IActionResult ShutDown() =>
        Content("Administrator only");
}

Dans le contrôleur précédent ControlAllPanelController :

  • Les membres du Administrator rôle ou du PowerUser rôle peuvent accéder au contrôleur et à l’action SetTime .
  • Seuls les membres du rôle peuvent accéder à l’action AdministratorShutDown .

Vous pouvez également verrouiller un contrôleur, mais autoriser l’accès anonyme et non authentifié à des actions individuelles.

[Authorize]
public class Control3PanelController : Controller
{
    public IActionResult SetTime() =>
        Content("[Authorize]");

    [AllowAnonymous]
    public IActionResult Login() =>
        Content("[AllowAnonymous]");
}

Pour Razor les pages, vous pouvez appliquer les [Authorize] éléments suivants :

[Authorize(Policy = "RequireAdministratorRole")]
public class UpdateModel : PageModel
{
    public ActionResult OnPost()
    {
    }
}

Important

Les attributs de filtre, y compris AuthorizeAttribute, peuvent uniquement être appliqués à PageModel et ne peuvent pas être appliqués à des méthodes de gestionnaire de pages spécifiques.

Vérifications de rôle basées sur des stratégies

Les exigences de rôle peuvent également être exprimées à l’aide de la nouvelle syntaxe de stratégie, où un développeur inscrit une stratégie au démarrage dans le cadre de la configuration du service d’autorisation. Cela se produit normalement dans ConfigureServices() votre Startup.cs fichier.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddRazorPages();

    services.AddAuthorization(options =>
    {
        options.AddPolicy("RequireAdministratorRole",
             policy => policy.RequireRole("Administrator"));
    });
}

Les stratégies sont appliquées à l’aide de la Policy propriété sur l’attribut [Authorize]:

[Authorize(Policy = "RequireAdministratorRole")]
public IActionResult Shutdown()
{
    return View();
}

Si vous souhaitez spécifier plusieurs rôles autorisés dans une exigence, vous pouvez les spécifier en tant que paramètres pour la RequireRole méthode :

options.AddPolicy("ElevatedRights", policy =>
                  policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator"));

Cet exemple autorise les utilisateurs qui appartiennent au ou PowerUserBackupAdministrator aux Administratorrôles.

Ajouter des services de rôle à Identity

Ajoutez AddRoles pour ajouter des services de rôle :

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDefaultIdentity<IdentityUser>()
        .AddRoles<IdentityRole>()
        .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddControllersWithViews();
    services.AddRazorPages();
}