Access Control List - Proposel

[Forte]

Ich habe mir die Zeit genommen, und die Zend_Acl etwas studiert. Ich
finde das verwendete Konzept gut (wie könnte es anders sein). Dennoch
würde ich für eCamp minimal davon abweichen. (Nur in der technischen
Umsetzung)

Kurze Zusammenfassung von Zend_Acl:
- Es gibt Resourcen; in der Regel eine Entität, ein Controller, ein
Service, ...; grundsätzlich, etwas dass alle gerne nutzen wollen,
jedoch nicht alle dürfen.
- Es gibt Rollen; jedem nutzer wird eine Rolle zugeteilt; in unserem
Fall User/Admin resp. AL, LL, Leiter, Gast, ....
- Es gibt ein Regelwerk; dieses definiert, welche Rollen welche
Resourcen benutzen dürfen.

Diese Angaben werden all in eine Instance von Zend_Acl abgelegt.
Zend_Acl werted die Regeln aus und entscheidet für jede Rolle, welche
Resourcen gebraucht werden können, und welche nicht.

(Was ich bis jetzt unterschlagen habe, dass die Resourcen noch in
Privilege unterteilt werden können; Zum Beispiel kann ein
KommentarController die Privilegien "KommentarErstellen" und
"KommentarLöschen" haben. Zend_Acl lässt es zu, einer Rolle jeweils
nur eine Teilmenge aller vorhandenen Privilegien zu erteilen/
verbieten)





Nun zum Vorschlag, wie dies für eCamp genutzt werden kann/soll:

Als erstes möchte ich festhalten, dass wir wahrscheinlich zwei
AccessControlList's führen werden müssen.
(Eine auf der User-Eben [Admin, User, Anonymous] und eine auf der Camp-
Ebene [AL, LL, L, Gast, ...])

In diesem Proposal konzentriere ich mich auf zweitere Liste (Camp-ACL)


Resourcen / Privilegion:
- Resourcen: Jeder Controller ist eine Resource
- Privilegion: Jede Action auf dem Controller wird einem Privileg
zugeortned somit gilt #(Actions) >= #(Privilegion)

=> Dies wird ermöglichen, dass aufgrund des HTML-Requests entschieden
werden kann, welche Resource und welches Privileg verwendet werden
möchte.


Rollen:
- Rolle: Wird zu einer Entität im DOM. Jedes Camp hat eine Liste von
Rollen; Jede UserCamp definiert, welcher Rolle ihr zugewiesen ist.

=> Die Anzahl und Namen der Rollen kann von Camp zu Camp varieren;
=> Beim erstellen eines Camps wird eine Std. Liste geladen. Diese kann
dann von einem User mit entsprechender Berechtigung angepasst werden



Regeln:
- Regel: Wird zu einer Entität im DOM. Jede Regel gilt genau für eine
Rolle und eine Resource und ein Privileg dieser Resource;

=> Das Property des Privilegs kann auch NULL sein, dann gilt die Regel
als default-Wert für die Resource.




Technische Umsetzung:

Resourcen/Privilegien:
Die Menge der Resourcen und Privilegion ist endlich und statisch. Sie
können im DOM abgelegt werden, es ist jedoch nicht notwendig.
Alternativen könnten folgende sein:
- Hard coded
- INI-File
- JSON
- DOM
- DocBlock der Controller

Gerade für die Entwicklung könnte es praktisch sein, wenn man die
Resourcen und Privilegien im Controller definieren könnte.
Die Angaben könnten dann vom Computer via Reflection von dort gelesen
werden (und in gewünschte Form abgelegt werden (JSON, ...))

Beispiel:

/** @AclResource Comment */
class CommentController
{
/** @AclPrivileg Read */
public function showAction()
{ ... }

/** @AclPrivileg Write */
public funciton createAction()
{ ... }

/** @AclPrivileg Write */
public function saveAction()
{ ... }
}


Rollen:
- Da jedes Camp die eigenen Rollen definieren kann, ist die Menge
nicht endlich. Die Rolle wird daher zur Entität.
- Die Rolle hat eine ID
- Die Rolle hat einen Namen
- Jede Rolle gehört immer genau einem Camp.
- Jede UserCamp Entität referenziert immer genau eine Rolle.
- Jeder Rolle geörte eine Liste von Regeln an
- Die Rolle "Ersteller" kann nicht entfernt werden
- Die Rolle "Ersteller" hat immer alle Rechte


Regeln:
- Regeln sind Entitäten
- Regeln haben eine ID
- Regeln haben einen Bezeichnet ("Allow" oder "Deny")
- Regeln verweisen auf eine Resource
- Regeln können auf ein konkretes Privileg verweisen
- Jede Regel gehört genau einer Rolle an




Einbindung in eCamp3:

- Die Überprüfung, ob ein User das gewünschte Privileg auf der
gefragten Resource hat, kann durch diese Struktur vor dem Dispatchen
passieren.
- Die Angaben, welche Resource/Privileg genutzt werden soll, ergibt
sich aus dem Request-Objekt (Controller/Action)
- Die Überprüfung wird also idealerweise in einem Plugin gemacht.
Dieses Plugin wird beim Front_Controller registriert.
- Entscheidet das Acl_Plugin, dass eine unerlaubte Abfrage gemacht
wurde, so kann dieses die Abfrage auf's Abstellgleis führen und diese
Loggen ;)


Wie kommen die Regeln von DOM/DB in die Zend_Acl?
- Erst die notwendigen Regeln von der DB laden (alle, welche von der
Entität Rolle gehalten werden)
- Jede Entität wird eins zu eins in die Zend_Acl abgespeichert.
- Dies kann Teil des Plugins oder Teil des Bootstraps sein...




So, ich hoffe, dass das einigermassen klar wurde....
Ansonsten kann ich das UML nachliefern....


Gruss Forte

[Forte]

Als Ergänzung, das ganze als UML....