Autorizzazione

Approfondimento

Nel contesto Architecture Coffee

L'autorizzazione risponde alla domanda «questo soggetto può compiere questa azione su questa risorsa?». La decisione applica le regole di accesso usando i fatti rilevanti, che possono includere ruolo, appartenenze, relazione con la risorsa e condizioni dell'operazione. Un'identità autenticata è un possibile elemento della valutazione, non un permesso generale. Esempio ipotetico: un'operatrice è autorizzata a disporre rimborsi fino a 500 euro soltanto sugli ordini della società italiana. Un rimborso di 120 euro per un ordine della società francese resta vietato, anche con login valido e ruolo corretto. Accedere alla funzione non equivale a poterla usare su qualunque ordine. L'architettura deve distinguere chi fornisce i fatti, chi valuta la regola e quale componente server applica l'esito prima dell'operazione. Nascondere un pulsante non sostituisce questo controllo. Sono responsabilità distinguibili anche nello stesso modulo applicativo; non implicano l'introduzione di un servizio di policy. Va distinta anche dai vincoli del dominio. Nel caso proposto, il limite personale dell'operatrice è una regola di autorizzazione; non rimborsare più dell'importo incassato è un vincolo dell'operazione. Un ruolo più potente non rende valida un'operazione che viola quel vincolo. Riferimenti: OWASP, Authorization Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html ; OWASP, API1:2023 Broken Object Level Authorization — https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/