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.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire attività con Azure Container Jobs
Effettuare il binding di date in Blazor
Eseguire query manipolando liste di tipi semplici con Entity Framework Core
Load test di ASP.NET Core con k6
Utilizzare la versione generica di EntityTypeConfiguration in Entity Framework Core
Evitare la command injection in un workflow di GitHub
Utilizzare database e servizi con gli add-on di Container App
Utilizzare i primary constructor in C#
Configurare dependabot per aggiornare le dipendenze di terze parti con GitHub Actions
Accesso sicuro ai secrets attraverso i file in Azure Container Apps