Consentire a una persona di gestire attività per conto di un’altra può rispondere a un’esigenza aziendale reale, ma non dovrebbe comportare la condivisione di password né concedere accesso generale all’account. In un’applicazione PHP, una delega sicura deve chiarire chi agisce, chi rappresenta, su quali risorse può intervenire e per quanto tempo. Deve inoltre poter essere revocata e sottoposta ad audit.
L’obiettivo è autorizzare un’azione specifica mantenendo l’identità di entrambe le persone. Questo richiede più di una schermata per concedere permessi: riguarda il modello dei dati, ogni punto di autorizzazione, le operazioni asincrone e i test. Progettare insieme questi elementi riduce il rischio che una delega valida in una schermata si trasformi, attraverso un percorso alternativo, in un accesso eccessivo.
Distinguere delega, impersonificazione e accesso condiviso
In una delega, chi avvia l’operazione mantiene la propria identità autenticata. L’applicazione registra inoltre che agisce per conto di un’altra persona, in base a un’autorizzazione limitata. La persona rappresentata non ha effettuato l’accesso e non deve comparire come autrice diretta della richiesta.
L’impersonificazione modifica l’identità effettiva con cui il sistema tratta una richiesta e può nascondere chi ha eseguito l’azione se non viene implementata con controlli specifici. L’accesso condiviso, per esempio tramite la consegna delle credenziali, elimina la separazione tra utenti e rende più difficile revocare o attribuire le attività. Per un normale flusso di delega, nessuno di questi approcci sostituisce un contesto esplicito di attore e principal rappresentato.
È opportuno assegnare nomi distinti a entrambi i ruoli nel codice e nei log. Per esempio, actor_id identifica chi ha eseguito l’operazione e principal_id la persona per conto della quale è stata eseguita. Evita nomi ambigui come user_id nei log in cui potrebbero riferirsi a entrambi.
Definire ambito, risorse e durata prima dell’implementazione
Una delega utile descrive con precisione che cosa autorizza. «Gestire l’account» è spesso troppo generico. Si può invece limitarla ad azioni come esaminare attività, aggiornarne lo stato o rispondere a una richiesta. Se le azioni hanno conseguenze diverse, modella permessi separati invece di raggruppare lettura, modifica, approvazione ed eliminazione in una capacità generica.
Definisci anche l’ambito delle risorse: un’organizzazione, un progetto, una coda di attività o un insieme specifico di record. Il permesso di modificare le attività di un progetto non dovrebbe abilitare la lettura dei dati di un altro progetto solo perché lo stesso utente delegato può accedervi tramite un’altra funzionalità.
La durata deve avere un inizio e una fine chiari, oltre a uno stato che consenta di revocare la delega prima della scadenza. Decidi quale fuso orario usare per mostrare le date e mantieni coerenti i confronti interni. Se la policy richiede un’approvazione o impedisce le deleghe a catena, trasformala in una regola esplicita e verificabile; non lasciarla come semplice convenzione dell’interfaccia.
Modellare l’autorizzazione e verificarla per ogni operazione
Uno schema relazionale può rappresentare una delega con campi quali identificatore, attore autorizzato, principal rappresentato, ambito, azioni, data di inizio, data di scadenza, stato, creatore e data di revoca. La struttura esatta dipende dal dominio: le azioni possono essere salvate in una tabella correlata o in un altro formato convalidato, ma devono poter essere consultate e verificate senza interpretazioni ambigue.
L’autorizzazione deve separare i privilegi del principal dall’autorizzazione delegata all’attore. Per l’operazione richiesta, verifica che il principal rappresentato avrebbe normalmente accesso alla risorsa e che le regole aziendali applicabili lo consentano. Quindi verifica che l’attore autenticato sia il destinatario di una delega valida, non revocata, e che questa autorizzi quell’azione su quella risorsa. Il permesso effettivo è limitato dall’accesso del principal e dall’ambito della delega: questa non può concedere all’attore più azioni o risorse di quante il principal possa autorizzare, né più di quelle indicate nella delega stessa. Non richiedere che anche l’attore abbia accesso diretto alla risorsa: può agire proprio grazie alla delega. Applica invece le restrizioni pertinenti all’identità dell’attore, come l’autenticazione, l’appartenenza al contesto richiesto o i controlli di sicurezza dell’operazione.
In pratica, la verifica dovrebbe includere:
- Che l’attore sia autenticato e che la delega sia a lui intestata.
- Che il principal rappresentato sia valido in quel contesto e abbia accesso ordinario alla risorsa richiesta.
- Che la delega sia attiva al momento dell’operazione, non revocata e ancora valida.
- Che l’azione richiesta e la risorsa rientrino nell’ambito concesso, senza superare i privilegi del principal.
- Che siano rispettate le restrizioni aziendali e di sicurezza applicabili all’attore e all’operazione.
Centralizza questa decisione in un servizio di autorizzazione o in una policy riutilizzabile, invece di ripetere condizioni parziali nei controller. Invocala comunque per ogni operazione rilevante: una vista protetta non protegge automaticamente un’API, un download, un’azione collettiva o una route di amministrazione. In PHP, il controller può recuperare l’attore autenticato, risolvere il contesto di delega e chiedere al servizio di autorizzare l’azione sulla risorsa specifica. Anche il livello di dominio può imporre invarianti critiche quando un’operazione ha conseguenze importanti.
Non fidarti di un principal_id inviato dal browser come prova di autorizzazione. Il server deve verificare la relazione tra attore, principal, delega, risorsa e azione usando dati attendibili. Non presumere nemmeno che nascondere un pulsante nell’interfaccia impedisca di invocare direttamente l’endpoint.
Mantenere l’attribuzione negli audit e nelle operazioni asincrone
Un log utile consente di ricostruire quanto è accaduto senza confondere le identità. Per ogni evento rilevante, conserva l’attore, il principal rappresentato, l’azione, il tipo e l’identificatore della risorsa, la data, l’esito e un riferimento alla delega applicata. A seconda del rischio, registra anche il motivo dell’operazione o l’identificatore di correlazione. Evita di salvare segreti o dati personali non necessari nello storico.
L’attribuzione deve sopravvivere alle code e ai job in background. Se una richiesta delegata pianifica un’attività, il messaggio dovrebbe trasportare un contesto verificabile con attore, principal e riferimento all’autorizzazione, senza dipendere dalla sessione web, che nel frattempo non sarà più disponibile. Quando esegui il job, decidi se verificare di nuovo che la delega sia ancora attiva. Per un’azione che può ancora essere annullata, una verifica al momento dell’esecuzione spesso evita che una revoca lasci in sospeso un’attività con un’autorizzazione obsoleta. Se l’operazione è già diventata irreversibile, documenta questo limite e registra il momento dell’autorizzazione.
Proteggi i log da modifiche non autorizzate e limita chi può consultarli. L’audit dovrebbe supportare le indagini e la responsabilità, ma non trasformarsi in una copia indiscriminata dei dati operativi.
Progettare scadenza e revoca come parte del flusso
La scadenza e la revoca non sono semplici cambiamenti di stato in una schermata. Una sessione che conserva un contesto di delega può continuare a mostrare opzioni obsolete; per questo, l’autorizzazione lato server deve verificare lo stato corrente a ogni richiesta, anche se l’interfaccia viene aggiornata. Se i permessi vengono memorizzati nella cache, definisci come invalidarli e quale ritardo massimo sia accettabile prima che la revoca diventi effettiva.
Quando revochi una delega, registra chi l’ha fatto e quando. Valuta esplicitamente le sessioni attive, i token emessi, i job in coda e i link temporanei associati. Non presumere che chiudere una sessione o modificare un dato nel database invalidi automaticamente tutti questi elementi. La risposta adeguata dipende dalla progettazione, ma deve essere definita prima di mettere il flusso in produzione.
Testare i limiti e i casi che spesso passano inosservati
I test devono verificare sia le azioni consentite sia quelle negate. Includi almeno una delega non ancora valida, scaduta o revocata; un attore diverso da quello autorizzato; una risorsa fuori ambito; un’azione non concessa; un principal errato o privo di accesso ordinario alla risorsa; e l’accesso diretto a endpoint non mostrati nell’interfaccia. Includi anche un caso positivo in cui l’attore non ha accesso diretto alla risorsa, ma il principal vi ha accesso e la delega copre l’azione e la risorsa. In questo modo verifichi che il sistema non confonda i permessi propri dell’attore con i privilegi delegati.
Aggiungi test per i limiti temporali, le modifiche concorrenti e gli effetti indiretti. Per esempio, verifica che cosa accade se una delega viene revocata mentre è in corso un’operazione o mentre un job è in attesa, e se un’azione su un’attività innesca notifiche, esportazioni o modifiche secondarie. Controlla che questi effetti mantengano la corretta attribuzione e non amplino l’ambito.
Separa i test unitari della policy di autorizzazione dai test di integrazione che attraversano route, persistenza e code. Un test che verifica solo il metodo decisionale non dimostra che tutte le route lo invochino; nemmeno un test dell’interfaccia dimostra che il server sia protetto.
Checklist prima della messa in produzione
- Attore e principal rappresentato sono chiaramente distinti nel codice, nell’interfaccia e nei log di audit?
- Ogni delega limita azioni, risorse e durata, impedendo le combinazioni non valide?
- La policy verifica l’accesso del principal e limita l’attore all’ambito delegato, senza richiedere che abbia accesso diretto alla risorsa?
- Ogni operazione lato server verifica identità, stato, tempo, ambito e azione?
- La revoca si applica a sessioni, token, cache e job in sospeso secondo una policy definita?
- I log consentono di attribuire le azioni senza memorizzare informazioni non necessarie?
- I test coprono i dinieghi, i limiti temporali, le deleghe valide senza accesso diretto dell’attore e gli effetti indiretti?
Una delega è sicura quando non viene confusa con l’accesso all’account di un’altra persona e quando ogni azione può essere giustificata dai privilegi del principal e da una delega valida e limitata. Se il team non è in grado di rispondere con precisione a chi ha agito, per conto di chi, su quale risorsa e con quale autorizzazione, il flusso richiede ancora una progettazione più approfondita prima di arrivare in produzione.
