Asset
L'identità autenticata non determina il permesso
Distinguere l'autenticazione del soggetto dalla decisione di autorizzazione su azione, risorsa e contesto, senza confondere privilegi e vincoli di dominio.
Autenticazione e autorizzazione rispondono a domande diverse
L'autenticazione verifica chi è il soggetto con le garanzie del meccanismo usato. L'autorizzazione decide se quel soggetto può compiere una specifica azione su una specifica risorsa nel contesto corrente. Un'identità valida non implica automaticamente un permesso.
Ruolo, oggetto e dominio sono controlli distinti
Un ruolo può contribuire alla decisione, ma spesso non basta. Il perimetro può dipendere da società, ordine, tenant, importo o stato corrente. Inoltre una regola di autorizzazione non sostituisce un'invariante di dominio: avere il permesso di rimborsare non permette di restituire più di quanto sia stato incassato.
Flusso di una richiesta dal soggetto autenticato alla decisione di autorizzazione e infine al controllo dell'invariante di dominio sulla risorsa.
Esempio: rimborso su un ordine
Conseguenze architetturali
- Il server deve verificare i controlli anche quando l'interfaccia nasconde funzioni non consentite.
- I fatti necessari alla decisione devono provenire da fonti affidabili.
- Decisione della policy e punto di enforcement devono essere identificabili.
- I controlli contestuali possono vivere nello stesso monolite oppure in componenti distinti: conta la responsabilità, non il deployment.
Riferimenti
Riferimenti utili: OWASP Authorization Cheat Sheet; OWASP API1:2023 Broken Object Level Authorization; OWASP Microservices Security Cheat Sheet; OWASP Business Logic Security Cheat Sheet.
Tag