Concetti progettuali¶

Le capacità di sicurezza degli oggetti di Symfony2 sono basate sul concetto di Access Control List. Ogni istanza di un oggetto del dominio ha la sua ACL. L'istanza ACL contiene una lista dettagliata di Access Control Entry (ACE), usate per prendere decisioni sugli accessi. Il sistema ACL di Symfony2 si focalizza su due obiettivi principali:

• fornire un modo per recuperare in modo efficiente grosse quantità di ACL/ACE per gli oggetti del dominio e modificarli;
• fornire un modo per prendere facilmente decisioni sulla possibilità o meno che qualcuno esegua un'azione su un oggetto del dominio.

Come indicato nel primo punto, una delle capacità principali del sistema ACL di Symfony2 è il modo altamente performante con cui recupera ACL e ACE. Questo è molto importante, perché ogni ACL può avere tanti ACE, nonché ereditare da altri ACL, come in un albero. Quindi, non ci appoggiamo specificatamente ad alcun ORM, ma l'implementazione predefinita interagisce con la connessione usando direttamente il DBAL di Doctrine.

Struttura delle tabelle della base dati¶

L'implementazione predefinita usa cinque tabelle della base dati, elencate sotto. Le tabelle sono ordinate dalla più piccola alla più grande, in una tipica applicazione:

• acl_security_identities: questa tabella registra tutte le identità di sicurezza (SID) che contengono ACE. L'implementazione predefinita ha due identità di sicurezza, RoleSecurityIdentity e UserSecurityIdentity
• acl_classes: questa tabella mappa i nomi delle classi con identificatori univoci, a cui possono fare riferimento le altre tabelle
• acl_object_identities: ogni riga in questa tabella rappresebta un'istanza di un singolo oggetto del dominio
• acl_object_identity_ancestors: questa tabella consente di determinare tutti gli antenati di un ACL in modo molto efficiente
• acl_entries: questa tabella contiene tutti gli ACE. Questa è tipicamente la tabella con più righe. Può contenerne decine di milioni, senza impattare in modo significativo sulle prestazioni

Visibilità degli Access Control Entry¶

Gli ACE possono avere visibilità diverse in cui applicarsi. In Symfony2, ci sono di base due visibilità:

• di classe: questi ACE si applicano a tutti gli oggetti della stessa classe
• di oggetto: questa è l'unica visibilità usata nel capitolo precedente e si applica solo a uno specifico oggetto

A volte, si avrà bisogno di applicare un ACE solo a uno specifico campo dell'oggetto. Si supponga di volere che l'ID sia visibile da un amministratore, ma non dal servizio clienti. Per risolvere questo problema comune, abbiamo aggiunto altre due sotto-visibilità:

• di campo di classe: questi ACE si applicano a tutti gli oggetti della stessa classe, ma solo a un campo specifico
• di campo di oggetto: questi ACE si applicano a uno specifico oggetto e solo a uno specifico campo di tale oggetto

Decisioni pre-autorizzazione¶

Per decisioni pre-autorizzazione, che sono decisioni da prendere prima dell'invocazione di un metodo o di un'azione sicura, ci si appoggia sul servizio AccessDecisionManager, usato anche per prendere decisioni di autorizzazione sui ruoli. Proprio come i ruoli, il sistema ACL aggiunge molti nuovi attributi, che possono essere usati per verificare diversi permessi.

Decisioni post-autorizzazione¶

Le decisioni post-autorizzazione sono eseguite dopo che un metodo sicuro è stato invocato e coinvolgono solitamente oggetti del dominio restituiti da tali metodi. Dopo l'invocazione, i fornitori consentono anche di modificare o filtrare gli oggetti del dominio, prima che siano restituiti.

A causa di limitazioni del linguaggio PHP, non ci sono capacità di post-autorizzazione predefinite nel componente della sicurezza. Tuttavia, c'è un bundle sperimentale, JMSSecurityExtraBundle, che aggiunge tali capacità. Si veda la documentazione del bundle per maggiori informazioni sulla loro implementazione.

Processo di determinazione dell'autorizzazione¶

La classe ACL fornisce due metodi per determinare se un'identità di sicurezza abbia i bit richiesti, isGranted e isFieldGranted. Quando l'ACL riceve una richiesta di autorizzazione tramite uno di questi metodi, delega la richiesta a un'implementazione di PermissionGrantingStrategy. Questo consente di sostituire il modo in cui sono prese le decisioni di accesso, senza dover modificare la classe ACL stessa.

PermissionGrantingStrategy verifica prima tutti gli ACE con visibilità di oggetto. Se nessuno è applicabile, verifica gli ACE con visibilità di classe. Se nessuno è applicabile, il processo viene ripetuto con gli ACE dell'ACL genitore. Se non esiste alcun ACL genitore, viene sollevata un'eccezione.