Una delle innovazioni più interessanti in ASP.NET Core è il concetto di Policy per quanto riguarda la gestione delle autorizzazioni.

Nelle versioni precedenti, quando dovevamo controllare l'accesso a particolari controller o action, l'unico strumento che avevamo a disposizione per differenziare gli utenti era il Role: una certa pagina o una certa API poteva essere ristretta solo agli appartenenti a un determinato gruppo.

Questo approccio aveva fondamentalmente due problemi:

• il Role era l'unico discriminante built-in che potevamo utilizzare. Regole più complesse potevano solo essere soddisfatte tramite custom authorization attribute;
• se il nome del ruolo veniva modificato, era necessario andare a sostituirlo in tutte le pagine o aree in cui era stato utilizzato.

Con l'avvento della security basata su Claim, invece, abbiamo a disposizione tutta una serie di attributi in più (i claim, per l'appunto) che descrivono l'utente in maniera più dettagliata, e permettono quindi di gestire regole più complesse, come per esempio richiedere multi-factor authentication per accedere all'area admin del sito.

Una policy non è altro che una sequenza di regole che viene dichiarata all'interno della classe startup:

public void ConfigureServices(IServiceCollection services)
{
    // .. altro codice qui ..
  services.AddMvc()
    .SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

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

Nell'esempio in alto, abbiamo creato una semplice policy chiamata AdminOnly che richiede che l'utente appartenga al ruolo Admin.

In un controller o in una action, possiamo poi referenziare la policy in alto tramite il solito attributo Authorize:

[Authorize(Policy = "AdminOnly")]
public IActionResult About()
{
  // .. altro codice qui ..
}

Le policy possono richiedere la presenza di determinati claim, possono implementare regole autorizzative complesse e persino essere combinate tra loro.

In ogni modo, anche usarle solo per specificare un semplice requisito di ruolo ci permette di astrarre la regola autorizzativa dal requisito in possesso dell'utente: se il nome del gruppo dovesse cambiare, o la regola dovesse diventare più complessa, ci basterà modificare la policy senza dover toccare i singoli controller o action dove è applicata.