Zend_Acl: controllo degli accessi

Zend_Acl fornisce una semplice ma robusta implementazione per la gestione delle liste di controllo degli accessi (Access Control Lists - ACLs). ACL rappresenta una soluzione flessibile per il controllo degli accessi: tutto ruota intorno ai concetti di "ruolo", "risorsa" e "privilegio". Un "ruolo" normalmente rappresenta un gruppo o una classe di utenti, una "risorsa" rappresenta qualcosa all'interno del sistema che necessita di una protezione (come un'azione in un controller o dati nel database) e un "privilegio" rappresenta una tipologia di accesso, come ad esempio "scrittura", "lettura", "creazione" o "modifica".

Per impostare il controllo degli accessi con Zend_Acl abbiamo bisogno di una lista di ruoli ed una lista di risorse. La prima cosa da fare dunque è impostare i ruoli che rappresentano gli utenti nella nostra applicazione. Creiamo innanzitutto una istanza di Zend_Acl :

[...]
		$acl = new Zend_Acl();
[...]

Ora che abbiamo l'istanza di Zend_Acl possiamo aggiungere i ruoli:

[...]
		$acl = new Zend_Acl();
		//creiamo il ruolo "registrato"
		$acl->addRole(new Zend_Acl_Role('registrato'));
		//creiamo il ruolo "admin"
		$acl->addRole(new Zend_Acl_Role('admin'));
[...]

A questo punto abbiamo creato i ruoli "registrato" e "admin" richiamando il metodo "addRole()" fornito dal componente Zend_Acl. Come vediamo dal codice, a questo metodo passiamo un'istanza di Zend_Acl_Role: questa è una classe molto semplice che memorizza il nome del ruolo. Due importanti precisazioni: una volta che il ruolo è stato creato non è più possibile cambiarne il nome, inoltre tale nome deve essere univoco nel contesto della ACL.

I ruoli possono essere organizzati secondo una struttura gerarchica di relazioni padre-figlio, in cui il ruolo figlio eredita i permessi del ruolo padre. Supponiamo ad esempio di aggiungere il ruolo "editore" al nostro applicativo:

[...]
		$acl->addRole(new Zend_Acl_Role('editore'), 'registrato');
[...]

In questa situazione il nuovo ruolo "editore" ha come padre il ruolo "registrato", dunque un "editore" eredita tutti i privilegi di un utente "registrato", oltre chiaramente ai permessi specifici che saranno impostati per il ruolo di "editore".

Come abbiamo già visto una "risorsa" è qualcosa che vogliamo proteggere: normalmente in ZF una "risorsa" è un controller o una "action" di un controller. Vorremmo ad esempio che solo dli utenti amministratori possano visualizzare la lista di utenti memorizzati nel nostro database: Zend_Acl_Resource è il componente che ci viene in aiuto nella definizione di "risorse", ed è una classe semplice quanto Zend_Acl_Role, infatti anche in questo caso il solo compito che gli è assegnato è quello di memorizzare il nome della risorsa.

Vediamo il nostro esempio:

[...]
		$acl->add(new Zend_Acl_Resource('utente'));
[...]

Anche in questo caso utilizziamo il metodo "add" della classe Zend_Acl, ma questa volta gli passiamo una istanza della classe Zend_Acl_Resource che rappresenta la risorsa "utente". Anche in questo possiamo organizzare gerarchicamente le risorse che vogliamo proteggere, esattamente con la stessa tecnica che abbiamo adottato per la definizione dei ruoli.

Ora che abbiamo definito i ruoli e le risorse ci resta l'ultimo passaggio per configurare l'oggetto Zend_Acl: dobbiamo specificare quali permessi ha un determinato ruolo su una determinata risorsa, cioè dobbiamo definire i "privilegi". Il "privilegio" è un tipo di accesso richiesto, e nella maggior parte dei casi sono legati alle operazione che possiamo compiere sulla web application, come creare, modificare o eliminare delle informazioni.

Zend_Acl dispone di due metodi per impostare i privilegi: "allow()" e "deny". Il metodo "allow()" permette di impostare una regola di accesso mentre il metodo "deny()" viene utilizzato per rimuovere o negare privilegi. Vediamo alcuni esempi:

[...]
		//(1)
		$acl->allow('admin', 'utente', 'list');
		  //(2)
  	$acl->allow('registrato', 'messaggiInterni', 'read');
		//(3)
		$acl->allow('editore', 'messaggiInterni', array('create', 'modify', 'delete');
[...]

La gestione dei privilegi segue la struttura gerarchica eventualmente impostata durante la configurazione dei ruoli, per cui un ruolo figlio, oltre ad avere i propri privilegi, eredita anche quelli del ruolo padre. Nell'esempio subito sopra, la seconda regola assegna agli utenti di tipo "registrato" la possibilità di eseguire la action "read" del controller "messaggiInterni", supponendo che la action "read" non faccia altro che stampare a video una lista di messaggi interni. La terza regola, invece, imposta i permessi degli utenti che rientrano nel ruolo di "editore": questi possono creare, modificare ed eliminare i messaggi interni, ma essendo figli della categoria "registrato" ereditano chiaramente anche il privilegio di leggerli, e dunque non è necessario ridefinire questa regola per un "editore".

Con la prima regola invece assegnamo agli utenti con ruolo "admin" la possibilità di accedere alla funzionalità "list" del controller "utente": in altre parole, solo gli utenti "admin" potranno eseguire l'action "list" implementata dal controller "utente", e dunque vedere stampata a video la lista degli utenti registrati nella nostra web application.

Ora che abbiamo tutti gli elementi possiamo apprezzare come sia semplice, intuitivo ed efficace il meccanismo di protezione delle risorse in ZF. Grazie all'implementazione del pattern Front Controller possiamo impostare i nostri controlli di sicurezza in un solo posto per tutta la web application, appoggiandoci ad una serie di plugin dedicati per la gestione di queste funzionalità.