Im vorigen Tutorial „Joomla! 2.5 ACL– die richtige Herangehensweise“ wurde bereits darauf hingewiesen, dass die Rechtevergabe immer bei der niedrigsten möglichen hierarchischen Stufe/Gruppe ansetzen sollte.
In diesem Tutorial wird gezeigt, welche Auswirkungen es nach sich zieht, wenn die Rechte stattdessen über die Globalen Berechtigungen (Konfiguration) vergeben werden. Zweitens wird die Benutzergruppe „Manager“, die öfters als Mittel für den Backend-Zugriff genannt wird, eingehend beleuchtet und erklärt, wieso dieser Weg viel zu umständlich aber auch sicherheitstechnisch ein Risiko ist.
Globale Berechtigungen: Grundsätzliches
Alle globalen Berechtigungen werden unter „Site“ -> „Konfiguration“ -> „Berechtigungen“ vergeben und zwar GLOBAL.
Das bedeutet: User einer Benutzergruppe mit einer erlaubten (oder durch Vererbung erlaubten) globalen Berechtigung, haben dieses Recht im Front- und im Backend und das bezogen auf nahezu jedes Joomla! Objekt (Komponenten, Mediamanager, Erweiterungen usw.). Sie haben dieses Recht so lange, bis es wieder entzogen wird. Ein Recht wieder entziehen kann man nur mit der Einstellung „verweigert“.
Das sind schon die ersten beiden Nachteile der globalen Berechtigungen: Sie sind überall gültig und ein „Verweigert“ kann in hierarchisch darunter liegenden Stufen nicht rückgängig gemacht werden.
Administrationszugriff: Grundsätzliches
Erste Möglichkeit: Global
Der Administrationszugriff kann einer oder mehreren Benutzergruppen in den globalen Berechtigungen (unter Konfiguration) erlaubt, bzw. durch Vererbung erlaubt werden.
Das bedeutet: User dieser Benutzergruppe haben Zugriff auf jedes Joomla!-Objekt (außer auf „Site“ -> „Konfiguration“) im Front- sowie Backend. Zugriff bedeutet hier in erster Linie: „Die User haben Einblick“, teils erhalten sie damit sogar sicherheitstechnisch bedenkliche Möglichkeiten (dazu gleich mehr).
Zweite Möglichkeit: Gezielt
Der Administrationszugriff kann stattdessen nahezu für jede Komponente/jedes Joomla!-Objekt einzeln vergeben werden. Ausnahmen: „Site“ -> „Konfiguration“ erfordert die globale Berechtigung „Superadmin“ auf „erlaubt“ und auch „Site“ -> „Wartung“ scheint nur mit Berechtigung „Superadmin“ einwandfrei zu funktionieren.
Überall dort, wo dieses Optionen-Icon zu sehen ist, kann einer Benutzergruppe erlaubt werden, auf dieses Joomla!-Objekt zuzugreifen. Dazu wird der Administrationszugriff nach Klick auf dieses Optionen-Icon auf „erlaubt“ gesetzt.
Eine zusätzliche Einstellung in den Globalen Berechtigungen („Site“ -> „Konfiguration“ -> „Berechtigungen“) ist nicht erforderlich!
Backendzugriff: Grundsätzliches
Damit eine Benutzergruppe Zugriff auf das Backend erhält, sind lediglich zwei Voraussetzungen zu erfüllen:
- Die Benutzergruppe muss der Zugriffsebene „Special“ zugeordnet werden.
- In den globalen Berechtigungen („Site“ -> „Konfiguration“ -> „Berechtigungen“) muss „Admin Anmeldung“ für diese Benutzergruppe auf „erlaubt“ gesetzt sein
Mehr ist dafür nicht nötig.
Backendzugriff: Manager?
Die These den Backendzugriff derart zu gestalten, dass man eine neue Benutzergruppe einrichtet und hier Manager als übergeordnete Gruppe wählt, birgt einige Fallstricke. Eigentlich und oberflächlich betrachtet erscheint dieser Weg ja logisch: Die Benutzergruppe Manager ist die Backend-Benutzergruppe mit den niedrigsten Rechten im Backend und hat Zugriff auf das Backend. Doch wir schauen mal genauer hin.
Bis auf „Administrationszugriff“, „Superadmin“ und „Offline Zugang“ sind der Benutzergruppe Manager alle Rechte („Site“ -> „Konfiguration“ -> „Berechtigungen“) global erlaubt.
Automatisch stehen bei einer neu erstellten Gruppe alle Einstellungen in den globalen Berechtigungen („Site“ -> „Konfiguration“ -> „Berechtigungen“) auf „vererbt“. Da die neue Benutzergruppe der Benutzergruppe Manager untergeordnet wurde, beerbt sie diese. Also hat die neue Benutzergruppe dieselben erlaubten Berechtigungen, wie die Benutzergruppe Manager.
Doch damit nicht genug. Schauen wir uns an, was die neue Gruppe noch von der Benutzergruppe Manager erbt und worauf sie nicht nur Zugriff, sondern auch weitergehende Rechte hat, wenn sie sich im Backend anmeldet.
Joomla! vergibt der Benutzergruppe Manager bereits per Programmiercode Administrationszugriff auf vereinzelte Joomla!-Objekte. Also: Obwohl in den globalen Berechtigungen („Site“ -> „Konfiguration“ -> „Berechtigungen“) der Administrationszugriff „vererbt“ = „errechnetes nicht erlaubt“ steht, existieren einzelne Administrationszugriffe.
Die Benutzergruppe Manager (und somit auch die erbende neue Benutzergruppe) hat standarmäßig nicht nur Zugriff (=Sichtbarkeit) auf die folgenden Komponenten, sondern kann (durch die global erlaubten Berechtigungen) deren Bestandteile löschen, neu erstellen, sperren, frei geben, in den Papierkorb stecken, verändern und verschieben:
Kontakte (samt sämtlicher Daten), Banner (samt Bannerkunden), Newsfeeds, Suche, Weblinks, sämtliche Medien-Inhalte des Medienmanagers, Beiträge und Kategorien.
Nun wird in diesem Kontext gerne argumentiert: Man müsse dann hier – wo es nicht erwünscht ist – einfach den Administrationszugriff auf „verweigert“ setzen. Zusätzlich muss man dann natürlich auch noch in den erwünschten Komponenten die Rechte entsprechend anpassen.
Keine Frage, so kommt man auch zum Ziel. Doch da man hier erstens, an alle Komponenten denken muss, wo der Administrationszugriff im Idealfall auf „vererbt“ (=errechnet „nicht erlaubt“) zurückgesetzt werden muss (nicht auf „verweigert“!) und zweitens bei der Reduzierung der Rechte nur ein „verweigert“ Erfolg hat (da global erlaubt geht hier nur verweigert), ist diese Methode sehr fehleranfällig und birgt den Nachteil „verweigert“ in sich. Ein „verweigert“ kann in unteren Hierarchien nicht mehr geändert werden.
Richtig fahrlässig wird die Methode (eine neue Benutzergruppe der Benutzergruppe Manager unterzuordnen) jedoch, wenn man in den globalen Berechtigungen (Konfiguration= „Site“ -> „Konfiguration“ -> „Berechtigungen“) den Administrationszugriff global erlaubt Damit hat diese Benutzergruppe dieselben globalen Rechte wie die Benutzergruppe „Administrator“. Au weh Zwick!
Das war jetzt alles sehr theoretisch. Nun wird es greifbar.
Backendzugriff Pur
Wir erstellen eine neue Benutzergruppe „Chefredaktion“. Eine Benutzergruppe wird über den Mausklick-Weg erstellt: „Benutzer“ -> „Gruppen“ -> „Neue Gruppe“. In „Gruppentitel“ tragen wir “ Chefredaktion“ ein, als übergeordnete Benutzergruppe lassen wir die Voreinstellung auf „Public“.
Nun ordnen wir dieser Benutzergruppe mindestens einen Benutzer/User zu. Dazu bearbeiten wir einen vorhandenen Benutzer und setzen unter „Zugewiesene Gruppen“ ein Häkchen bei „Chefredaktion“ – speichern nicht vergessen.
Meine so bearbeitete Benutzerin (Sophie) trägt den Usernamen „Chefredi“ und gehört nun zwei Benutzergruppen an: Standardmäßig der Benutzergruppe „Registered“ (die als einziges Recht die Anmeldung im Frontend hat) und der Benutzergruppe „Chefredaktion“, die derzeit die Benutzergruppe „Public“ beerbt und somit noch keinerlei Rechte besitzt. Das ändern wir jetzt.
Der nächste Mausklick-Weg: „Site“ -> „Konfiguration“ -> „Berechtigungen“ => „Chefredaktion“. Wir setzen „Admin Anmeldung“ auf erlaubt.
Was der Benutzergruppe „Chefredaktion“ jetzt noch fehlt, ist die Zugriffsebene special. Mausklick-Weg: „Benutzer“ -> „Zugriffsebenen“ => „Special“ bearbeiten. Unter „Folgende Benutzergruppen haben Zugriff “ ein Häkchen bei „Chefredaktion“ setzen und speichern.
Und fertig ist der Backend Pur Zugang. Chefredi meldet sich unter http://deinedomain.de/administrator an. Und sieht:
Unter „Site“ versteckt sich lediglich der Menüpunkt „Mein Profil“.
Beispiel: Zugriff auf Bannerkomponente
Damit Chefredi nun mit einer bestimmten Komponente arbeiten kann, muss der Superadministrator der Benutzergruppe „Chefredaktion“ folgendes einrichten, nehmen wir einmal die Komponente Banner:
- Die Komponente Banner anklicken, dann auf das Optionen-Icon klicken und „Administrationszugriff“ auf „erlaubt“ setzen (für Benutzergruppe Chefredaktion“)
- Immer noch im Menü „Optionen-Icon“ weitere Rechte freigeben (auf „erlaubt“ setzen), wie zum Beispiel das Recht (Aktion) „Bearbeiten“
Nun sieht es für Chefredi im Backend so aus:
Die Benutzergruppe „Chefredaktion“ hat Administrationszugriff auf die Komponente Banner erhalten und kann die Komponente Banner dadurch sehen. Außerdem wurde der Benutzergruppe „Chefredaktion“ das „Bearbeiten“ innerhalb dieser Komponente erlaubt.
Somit ergeben sich für Chefredi, die der Benutzergruppe „Chefredaktion“ angehört nach dem Mausklick auf „Banner“ folgende Möglichkeiten:
Chefredi kann innerhalb der Komponente Banner existierende Banner, Kunden und Kategorien ändern, kopieren, verschieben und die Zugriffsebene bestimmen (aber nicht frei geben!). Sie darf nichts neu erstellen, sperren, freigeben oder löschen, da die Benutzergruppe „Chefredaktion“ zu der sie gehört, innerhalb der Komponente Banner nur das Recht auf „Bearbeiten“ erhalten hat. Chefredi kann auch keine anderen Komponenten sehen, da der Administrationszugriff nicht global vergeben wurde. Perfekt, genau das war so beabsichtigt!
Da Chefredi aber andere Aufgaben im Schulprojekt haben wird (kommendes Tutorial), als sich mit der Bannerwerbung zu beschäftigen, setzen wir die für die Komponente Banner vergebenen Rechte mal schnell wieder zurück. Das heißt in den Banneroptionen werden bei der Gruppe „Chefredaktion“ die Rechte /Aktionen „Administrationszugriff“ und „Bearbeiten“ wieder auf „vererbt“ gesetzt und gespeichert.
Plus Administrationszugriff Pur
Die Benutzergruppe Chefredaktion hat Zugriff auf das Backend (siehe Kapitel „Backend Pur“). Für Chefredi, die der Benutzergruppe „Chefredaktion“ angehört, ergibt sich nach der Anmeldung im Backend das folgende Bild:
Nun schauen wir uns einmal an, welche Auswirkungen die globale Erlaubnis auf Administrationszugriff hier hat. Mausklick-Weg: „Site“ -> „Konfiguration“ -> „Berechtigungen“ => „Chefredaktion“ -> „Administrationszugriff“ auf „erlaubt“ und speichern.
Wie man auf dem nachfolgenden Screenshot sieht, wurden der Benutzergruppe „Chefredaktion“ die Rechte/Aktionen „Admin Anmeldung“ und „Administrationszugriff“ erlaubt, alle anderen Rechte bleiben „vererbt“ und sind errechnet „nicht erlaubt“.
Chefredi, die der Benutzergruppe „Chefredaktion“ angehört, meldet sich im Backend an. Das Erscheinungsbild ist nun deutlich anders:
Im Einzelnen darf Chefredi, alleine auf Grund des „erlaubt“ bei „Administrationszugriff“ in den globalen Berechtigungen („Site“ -> „Konfiguration“ -> „Berechtigungen“) folgendes:
„Lediglich“ sichtbar ohne die Rechte auf Erstellen, Ändern, Freigeben, Sperren, Papierkorb stecken, Löschen, Kopieren, Verschieben sind folgende Joomla! Objekte:
- Benutzer, samt aller Daten
- Menüs und Menüpunkte
- Beiträge
- Kategorien
- Hauptbeiträge
- Medienmanager, inklusive aller Medien
- installierte Sprachen
- installierte Templates
- Banner, Bannerkategorien, Bannerkunden
- Kontakte, inkl. aller Kontaktdaten
- Newsfeeds
- Suche
- Umleitungen
- Weblinks
- alle installierten Erweiterungen
Aber nicht nur Informationen werden preis gegeben, sondern:
- Chefredi kann neue Erweiterungen installieren (Sprachen, Templates, Komponenten, Joomla!-Updates, Plugins, Module) installieren. Sie kann zwar keine Module und Plugins anschließend frei geben, aber Komponenten funktionieren auch ohne Freigabe. Falls das nicht erwünscht ist, darf also nicht vergessen werden, diese Berechtigung über den Mausklickweg -> „Erweiterungen“ -> „Erweiterungen“ -> „Icon:Optionen“ -> „Gruppe Chefredaktion“ -> „Administrationszugriff“ auf „Verweigert“ zu stellen.
- Chefredi darf außerdem Massen-E-Mails verschicken. Auch hier muss bei Bedarf über den Mausklickweg -> „Benutzer“ -> „Massenmail“ -> „Icon:Optionen“ -> „Gruppe Chefredaktion“ -> „Administrationszugriff“ auf „Verweigert“ die Berechtigung wieder entzogen werden.
Und das Beste zum Schluss: Ich habe auf diesem Testsystem auch mal den Community Builder 1.7 installiert. Hier darf Chefredi Tabs, Felder, Listen bearbeiten, löschen und neu anlegen; Plug-ins installieren, CB-Tools ausführen und die komplette CB-Konfiguration verändern. Das lässt sich auch über kein Icon:Optionen verhindern.
Falls also der Administrationszugriff global erlaubt wurde, müssen bei jeder Installation einer 3rd-Party-Extension die Rechte geprüft werden – ein Irrsinn oder?
Fazit:
Der Administrationszugriff global erlaubt („Site“ -> „Konfiguration“ -> „Berechtigungen“), sollte den Benutzergruppen „Administrator“ und „Super Users“ vorbehalten bleiben. Eigentlich ist ab Joomla! 1.6 nur noch die Verwendung der Gruppen „Registered“ und „Super Users“ sinnvoll.
Warum? Alle Joomla!-Standard-Benutzergruppen haben globale Rechte: Zum Beispiel „Editor“ darf jeden Beitrag im Frontend bearbeiten. Hat „Editor“ dazu noch Backendzugriff, darf „Editor“ bei den Joomla!-Objekten, auf die „Editor“ erlaubten Administrationszugriff hat, ebenfalls alles bearbeiten.
Sinn macht die Verwendung der bisherigen Standard-Joomla!-Benutzergruppen nur noch, wenn man (um beim obigen Beispiel zu bleiben) „Editor“ benötigt, der nur im Frontend agiert und hier wirklich alle Artikel bearbeiten darf.
Für das Backend sollte in der Regel eine neue Gruppe mit auf das Joomla!-Objekt zugeschnittenen Rechten erstellt werden. Auch für das Frontend lässt sich natürlich der Zugriff einschränken, doch dazu mehr in einem der nächsten Tutorials.
