Kapitel 2. Zend_Acl

Inhaltsverzeichnis

2.1. Einführung
2.1.1. Über Ressourcen
2.1.2. Über Rollen
2.1.3. Erstellen einer Zugriffskontrollliste (ACL)
2.1.4. Rollen registrieren
2.1.5. Zugangsbeschränkung definieren
2.1.6. Die ACL abfragen
2.2. Verfeinern der Zugriffskontrolle
2.2.1. Präzise Zugangsbeschränkung
2.2.2. Zugangsbeschränkungen entfernen
2.3. Advanced Use
2.3.1. Storing ACL Data for Persistence
2.3.2. Writing Conditional ACL Rules with Assertions

2.1. Einführung

Zend_Acl stellt Funktionalitäten für leichtgewichtige und flexible Zugriffskontrolllisten (englisch "access control list", ACL) sowie die Rechteverwaltung bereit. Im Allgemeinen kann eine Anwendung derartige Funktionalitäten verwenden, um den Zugriff auf bestimmte, geschützte Objekte durch andere anfordernde Objekte zu kontrollieren.

In dieser Dokumentation

  • ist eine Ressource ein Objekt, auf das der Zugriff kontrolliert wird.

  • ist eine Rolle ein Objekt, dass den Zugriff auf eine Ressource anfordern kann.

Einfach ausgedrückt, fordern Rollen den Zugriff auf Ressourcen an. Wenn z.B. eine Person den Zugriff auf ein Auto anfordert, ist die Person die anfordernde Rolle und das Auto die Ressource, weil der Zugriff auf das Auto kontrolliert wird.

Durch die Spezifikation und die Verwendung einer Zugriffskontrollliste (ACL) kann eine Anwendung kontrollieren, wie anfordernde Objekte (Rollen) den Zugriff auf geschützte Objekte eingeräumt bekommen.

2.1.1. Über Ressourcen

In Zend_Acl ist das Erstellen einer Ressource sehr einfach. Zend_Acl stellt das Zend_Acl_Resource_Interface bereit, um Entwicklern das Erstellen von Ressourcen zu ermöglichen. Eine Klasse muss nur dieses Interface implementieren, das nur aus einer einzelnen Methode, getResourceId(), besteht, damit Zend_Acl das Objekt als Ressource erkennen kann. Zusätzlich ist Zend_Acl_Resource in Zend_Acl als einfache Ressourcen Implementation enthalten, damit Entwickler sie bei Bedarf erweitern können.

Zend_Acl stellt eine Baumstruktur bereit, in die mehrere Ressourcen (oder "Bereiche unter Zugriffskontrolle") aufgenommen werden können. Weil Ressourcen in solch einer Baumstruktur abgelegt werden, können sie vom Allgemeinen (von der Baumwurzel) bis zum Speziellen (zu den Baumblättern) organisiert werden. Abfragen für eine bestimmte Ressource durchsuchen automatisch die Ressourcenhierarchie nach Regeln, die einer übergeordneten Ressource zugeordnet wurden, um die einfache Vererbung von Regeln zu ermöglichen. Wenn zum Beispiel eine Standardregel für jedes Gebäude einer Stadt gelten soll, würde man diese Regel einfach der Stadt zuordnen, anstatt die selbe Regel jedem Gebäude zuzuordnen. Einige Gebäude können dennoch Ausnahmen zu solch einer Regel erfordern, und dies kann in Zend_Acl einfach durch die Zuordnung solcher Ausnahmeregeln to jedem der Gebäude erreicht werden, die eine Ausnahme zu der Regel erfordern. Eine Ressource kann nur von einer einziger übergeordneten Ressource erben, obwohl diese übergeordnete Ressource seine eigenen übergeordneten Ressourcen haben kann, und so weiter.

Zend_Acl unterstützt außerdem Rechte für Ressourcen (z.B. "erstellen", "lesen", "aktualisieren", "löschen") und der Entwickler kann Regeln zuordnen, die alle Rechte oder bestimmte Rechte der Ressource beeinflussen.

2.1.2. Über Rollen

Ähnlich wie bei den Ressourcen ist auch das Erstellen einer Rolle sehr einfach. Zend_Acl stellt das Zend_Acl_Role_Interface bereit, um Entwicklern das Erstellen von Rollen zu ermöglichen. Eine Klasse muss nur dieses Interface implementieren, das nur aus einer einzelnen Methode, getRoleId(), besteht, damit Zend_Acl das Objekt als Rolle erkennen kann. Zusätzlich ist Zend_Acl_Role in Zend_Acl als einfache Rollen Implementation enthalten, damit Entwickler sie bei Bedarf erweitern können.

In Zend_Acl kann eine Rolle von einer oder mehreren Rollen erben. Dies soll die Vererbung von Regeln zwischen den Rollen ermöglichen. Zum Beispiel kann eine Benutzerrolle, wie "Sally" zu einer oder mehreren Rollen gehören, wie "Editor" und "Administrator". Der Entwickler kann zu "Editor" und "Administrator" getrennt Regeln zuordnen und "Sally" würde diese Regeln von beiden erben, ohne dass "Sally" direkt Regeln zugeordnet werden müssen.

[Anmerkung] Anmerkung

Da Zend_Acl das Vererben von Regeln von mehreren Rollen erlaubt, die möglicherweise miteinander in Konflikt stehen können, wird ein Weg benötigt, um diese Konflikte eindeutig auflösen zu können. Zend_Acl löst solche möglichen Konflikte dadurch auf, dass die zuletzt übernommende Rolle die höchste Priorität hat. Das heißt, sobald eine Regel für eine übergeordnete Rolle gefunden wurde, wobei bei der zuletzt übernommenden Rolle begonnen wird, werden keine anderen Regeln mehr beachtet, weil die Regel mit der höchsten Priorität bereit erreicht wurde.

2.1.3. Erstellen einer Zugriffskontrollliste (ACL)

Eine Zugriffskontrollliste (im weiteren Verlauf nur ACL genannt) kann jeden gewünschten Satz von körperlichen oder virtuellen Objekten repräsentieren. Zu Demonstrationszwecken werden wir eine grundlegende ACL für ein Redaktionssystem erstellen, die mehrere Schichten von Gruppen über eine Vielzahl von Bereichen verwaltet soll. Um ein ACL Objekt zu erstellen, instanzieren wir die ACL ohne Parameter:

<?php
require_once 'Zend/Acl.php';

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

Dtandardmäßig ist Zend_Acl eine "whitelist" Implementation, was bedeutet, dass Zend_Acl den Zugriff auf jedes Recht einer Ressource für jede Rolle verweigert, solange dies nicht vom Entwickler anders angegeben wird.

2.1.4. Rollen registrieren

Redaktionssysteme (CMS) brauchen fast immer eine Hierarchie von Genehmigungen, um die Autorenfähigkeiten seiner Benutzer festzulegen. Es kann eine 'Guest' Gruppe geben, um beschränkten Zugriff zur Demonstration zu ermöglichen, eine 'Staff' Gruppe für die Mehrheit der CMS Nutzer, welche die meisten der alltäglichen Aufgaben erledigen, eine 'Editor' Gruppe für diejenigen, die für das Veröffentlichen, Überprüfen, Archivieren und Löschen von Inhalten zuständig sind, sowie eine 'Administrator' Gruppe, dessen Aufgabenbereiche alle der anderen Gruppen sowie die Pflege sensibler Informationen, der Benutzerverwaltung, der Back-End Konfigurationsdaten und die Datensicherung sowie der Export beinhalten. Diese Genehmigungen können durch eine Rollenregistrierung repräsentiert werden, die es jeder Gruppe erlaubt, die Rechte von 'übergeordneten' Gruppen zu erben sowie eindeutige Rechte nur für deren Gruppe bereit zu stellen. Diese Genehmigungen können wir folgt ausgedrückt werden:

Tabelle 2.1. Zugangsbeschränkung für ein Beispiel-CMS

Name Eindeutige Genehmigung Erbe Genehmigungen von
Guest View N/A
Staff Edit, Submit, Revise Guest
Editor Publish, Archive, Delete Staff
Administrator (bekommt kompletten Zugriff gewährt) N/A

Für dieses Beispiel wird Zend_Acl_Role verwendet, aber jedes Objekt wird akzeptiert, das Zend_Acl_Role_Interface implementiert. Diese Gruppen können zur Rollenregistrierung wie folgt hinzugefügt werden:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

// Füge Gruppen zur Rollenregistrierung hinzu unter Verwendung von Zend_Acl_Role
require_once 'Zend/Acl/Role.php';

// Gast erbt keine Zugriffsrechte
$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);

// Mitarbeiter erbt von Gast
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);

/* alternativ kann das obige wie folgt geschrieben werden:
$roleGuest = $acl->addRole(new Zend_Acl_Role('staff'), 'guest');
//*/

// Redakteur erbt von Mitarbeiter
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');

// Administrator erbt keine Zugriffsrechte
$acl->addRole(new Zend_Acl_Role('administrator'));

2.1.5. Zugangsbeschränkung definieren

Nun, da die ACL die relevanten Rollen enthält, können Regeln eingerichtet werden, die definieren, wie auf Ressourcen durch Rollen zugegriffen werden darf. Es ist zu beachten, dass wir keine bestimmten Ressourcen in diesem Beispiel definiert haben, das vereinfacht wurde, um zu illustrieren, dass die Regeln für alle Ressourcen gelten. Zend_Acl stellt eine Implementation bereit, bei der Regeln nur vom Allgemeinen zum Speziellen definiert werden müssen, um die Anzahl der benötigten Regeln zu minimieren, weil Ressourcen und Rollen die Regeln erben, die in ihren Vorfahren definiert worden sind.

Folglich können wir einen einigermaßen komplexen Regelsatz mit sehr wenig Code definieren. Um die grundlegenden Genehmigungen von oben anzugeben:

<?php
require_once 'Zend/Acl.php';

$acl = new Zend_Acl();

require_once 'Zend/Acl/Role.php';

$roleGuest = new Zend_Acl_Role('guest');
$acl->addRole($roleGuest);
$acl->addRole(new Zend_Acl_Role('staff'), $roleGuest);
$acl->addRole(new Zend_Acl_Role('editor'), 'staff');
$acl->addRole(new Zend_Acl_Role('administrator'));

// Gäste dürfen Inhalte nur sehen
$acl->allow($roleGuest, null, 'view');

/* alternativ kann das obige wie folgt geschrieben werden:
$acl->allow('guest', null, 'view');
//*/

// Mitarbeiter erbt 'ansehen' Rechte von Gast, benötigt aber zusätzliche Rechte
$acl->allow('staff', null, array('edit', 'submit', 'revise'));

// Redakteuer erbt 'ansehen', 'bearbeiten', 'absenden' und 'revidieren' Rechte von Mitarbeiter,
// benötigt aber zusätzliche Rechte
$acl->allow('editor', null, array('publish', 'archive', 'delete'));

// Administrator erbt gar nichts, aber erhält alle Rechte
$acl->allow('administrator');

Die null Werte im obigen allow() Aufrufen werden verwendet, um anzugeben, dass diese Regeln für alle Ressourcen gelten.

2.1.6. Die ACL abfragen

Wir haben nun eine flexible ACL, die in der gesamten Anwendung verwendet werden kann, um zu ermitteln, ob Anfragende die Genehmigung haben, Funktionen auszuführen. Abfragen durchzuführen ist recht einfach mit Hilfe der isAllowed() Methode:

<?php
echo $acl->isAllowed('guest', null, 'view') ?
     "allowed" : "denied"; // erlaubt

echo $acl->isAllowed('staff', null, 'publish') ?
     "allowed" : "denied"; // verweigert

echo $acl->isAllowed('staff', null, 'revise') ?
     "allowed" : "denied"; // erlaubt

echo $acl->isAllowed('editor', null, 'view') ?
     "allowed" : "denied"; // erlaubt wegen der Vererbung von Gast

echo $acl->isAllowed('editor', null, 'update') ?
     "allowed" : "denied"; // verweigert, weil es keine erlaubte Regel für 'update' gibt

echo $acl->isAllowed('administrator', null, 'view') ?
     "allowed" : "denied"; // erlaubt, weil Administrator alle Rechte haben

echo $acl->isAllowed('administrator') ?
     "allowed" : "denied"; // erlaubt, weil Administrator alle Rechte haben

echo $acl->isAllowed('administrator', null, 'update') ?
     "allowed" : "denied"; // erlaubt, weil Administrator alle Rechte haben