AUTORIZZAZIONE
SICUREZZA NELLE FASI DI AUTENTICAZIONE E AUTORIZZAZIONE
L’autenticazione a due fattori richiede le credenziali utente e inoltre di esibire qualcosa che si possiede come uno smartphone con il suo codice di autenticazione. L’identità dell’utente è protetta anche dopo il login, perché abbiamo visto che viene emesso un cookie di autenticazione, che ha un contenuto protetto, cifrato impossibile da manomettere.
Dopo la fase di autenticazione ne segue sempre un’altra, l’autorizzazione che consiste nel determinare se un’utente può o meno compiere una certa operazione. Un utente è autorizzato quando innanzitutto si è autenticato, poi bisogna vedere se ha associati dei Claim, come ad esempio l’appartenenza a un ruolo. Nella nostra applicazione i Claim sono memorizzati su un supporto decisamente valido come il cookie di autenticazione.
REGOLARE L’ACCESSO DEGLI UTENTI
Il centro di tutto è l’attributo Authorize, che determina quale entità devono essere protette.
L’attributo di per sé verifica se l’utente ha fatto il login, ma non si accerta se possiede dei Claim nel cookie di autenticazione. Authorize lo possiamo utilizzare a prescindere dal tipo di autenticazione usato perché fa parte di ASP.NET Core e non di Identity. Dopo aver messo l’attributo nelle Action del CoursesController, l’utente anonimo viene rimbalzato alla pagina di Login. Essere un utente autenticato non è sufficiente per creare un corso, ma deve possedere dei claim come, ad esempio, il ruolo di docente. L’attributo Authorize è solo un marcatore, il lavoro lo svolge l’Authorization Middleware che decide se l’utente può compiere una certa operazione.
Di fronte tutta questa apparente semplicità si celano dei rischi, se ad esempio tra due anni nel Controller creiamo un nuovo metodo che espone dati riservati e ci dimentichiamo di porre l’attributo Authorize di fatto stiamo divulgando dati sensibili. Per rimediare a questo problema basta porre l’attributo Authorize sul Controller, in questo modo tutte le Action sono protette e usare l’attributo AllowAnonymous per gli utenti anonimi che devono poter accedere a determinate Action. Grazie ad esso un Action diventa pubblicamente accessibile.
Se vogliamo che tutti i Controller siano soggetti ad autorizzazione usiamo del codice nella classe startup.cs.
Preciso che un filter è un pezzo di codice eseguito prima di ogni Action.
REGOLARE L’ACCESSO A RAZOR PAGES
La domanda è questa, quando ci basta che l’utente sia soltanto autenticato per fruire di una funzionalità? La risposta è: quando ad esempio, vogliamo mostragli funzionalità che lo riguardano, come l’elenco dei corsi che ha acquistato, oppure una funzionalità nuova che permette all’utente autenticato di porre una domanda al docente.
Se fosse rivolto anche a utenti non autenticati il Form, potrebbe attirare gli spammer che invierebbero contenuti poco carini ai docenti, il docente potrà vedere il nome e l’e-mail in quanto si tratta di un utente autenticato e conosciamo queste informazioni. Creiamo il Form di contatto con le Razor Page e una directory Page con dentro la Razor page Contact. Ora nei metodi OnGetAsync e OnPostAsync non possiamo mettere l’attributo Authorize in quanto le Razor Page hanno questa limitazione.
L’altra alternativa sono i filtri visti anche con MVC.
Siccome gli endpoint routing sono gli stessi sia per MVC che Razor page non accorre duplicare il codice già visto per MVC. La pagina della Privacy deve essere consultabile da tutti, ecco un modo semplice per farlo.
LINK AL CODICE SU GITHUB
Scaricare il codice della sezione18 oppure il ramo master o clonare il repository GITHUB per avere a disposizione tutte le sezioni nel tuo editor preferito.
Scrivi un commento