be_acl für TYPO3

Sobald mehr als drei Redakteure arbeiten, reichen TYPO3s Standard-Rechte nicht mehr aus

TYPO3 bringt ein Berechtigungssystem mit: Backend-Gruppen, Seitenzugriffe, Tabellen-Rechte. Für kleine Teams mit einer Handvoll Redakteuren funktioniert das. Aber wenn eine Unternehmenswebsite von 15 Redakteuren aus 4 Abteilungen gepflegt wird, stößt das Standard-System an Grenzen. be_acl erweitert TYPO3 um granulare Access Control Lists, die pro Seite und für beliebig viele Benutzer und Gruppen regeln, wer dort was sehen, bearbeiten oder löschen darf.

Die Extension ist kein Nice-to-have, sondern Voraussetzung für jedes Multi-Redaktions-Setup mit mehr als einer Verantwortungszone. Ohne be_acl enden Berechtigungskonzepte in TYPO3 regelmäßig in einem Geflecht aus dutzenden Gruppen, die niemand mehr überblickt.

Typische Einsatzszenarien

Konzern-Websites mit Abteilungs-Verantwortung. Marketing pflegt die Startseite und Kampagnenseiten, HR die Karriereseite, die Fachabteilungen ihre Produktseiten. Jede Abteilung soll nur ihre eigenen Seiten sehen und bearbeiten. Das Standard-TYPO3-System erlaubt Seitenzugriffe über Mount Points und Gruppenrechte, aber die Konfiguration wird bei 10+ Abteilungen unübersichtlich. be_acl vereinfacht das durch seitenbasierte ACLs: Auf jeder Seite im Seitenbaum lässt sich direkt definieren, welche Gruppe welche Rechte hat.

Mandantenfähige TYPO3-Installationen. Agenturen und Konzerne betreiben mehrere Websites in einer TYPO3-Instanz. Mandant A darf Mandant B nicht sehen, nicht einmal im Seitenbaum. be_acl setzt diese Trennung durch, ohne für jeden Mandanten eine eigene TYPO3-Installation zu betreiben. Bei einer Agentur mit 12 Mandanten in einer TYPO3-Instanz reduzierte be_acl die Administrationszeit für Berechtigungen um circa 60%.

Freigabe-Workflows mit eingeschränkter Bearbeitungstiefe. Externe Dienstleister oder Praktikanten sollen Content-Texte bearbeiten, aber keine Bilder hochladen, keine Seiten verschieben und keine Plugins konfigurieren. Die Rechte auf Feldebene kommen dabei aus dem TYPO3-Core: Über die erlaubten Felder seiner Backend-Gruppe sieht der Benutzer das Textfeld, aber nicht die Layout-Einstellungen oder die Plugin-Konfiguration. be_acl ergänzt das um passende Seitenrechte, etwa Inhalte bearbeiten, aber keine Seiten anlegen oder löschen.

Technische Architektur

be_acl erweitert TYPO3s Backend-Berechtigungssystem um ein ACL-Layer, das zwischen dem Core-Rechtesystem und der Benutzerinteraktion sitzt. Die Extension speichert Berechtigungsregeln in der Tabelle tx_beacl_acl, die pro Seite und pro Gruppe definiert, welche Operationen erlaubt sind.

Das System arbeitet mit den fünf Seitenrechten von TYPO3: Seite anzeigen (show), Seite bearbeiten, Seite löschen, Unterseiten anlegen und Inhalte bearbeiten. Diese Rechte werden pro Seite oder rekursiv für einen Seitenbaum vergeben. Die Konfiguration erfolgt im Backend-Modul Web > Zugriff: Dort legt der Administrator für eine Seite eine ACL für einen Benutzer oder eine Gruppe an und setzt die gewünschten Rechte per Checkbox.

Intern greift be_acl in TYPO3s BackendUserAuthentication ein und erweitert die doesUserHaveAccess-Prüfung. Bei jedem Seitenzugriff im Backend prüft TYPO3 zuerst die Standard-Rechte und anschließend die ACL-Regeln. Die ACL-Regeln können Standard-Rechte erweitern, aber nicht einschränken. Das ist ein wichtiges Architekturdetail: Wenn eine Gruppe über die Standard-Rechte bereits Zugriff hat, kann be_acl diesen nicht entziehen.

Die Rechte-Auflösung folgt zwei Regeln. Erstens gilt für den Benutzer und für jede seiner Gruppen die ACL, die der Seite am nächsten liegt: eine ACL auf der Seite selbst oder die nächste rekursive ACL darüber. Zweitens addiert be_acl die Rechte aus Benutzer- und Gruppen-ACLs (ODER-Verknüpfung), bei aktivem altem Rechtesystem zusätzlich zu den klassischen Seitenrechten; eine Gruppe kann einer anderen also keine Rechte entziehen.

Häufige Probleme und Lösungen

Berechtigungen greifen nicht wie erwartet. Häufigste Ursache: Der Benutzer ist Mitglied in mehreren Gruppen, und die Rechte einer Gruppe überschreiben die ACL-Einschränkung einer anderen. TYPO3s Rechtesystem arbeitet additiv, das heißt, der Benutzer erhält die Summe aller Rechte seiner Gruppen. Lösung: Berechtigungsmatrix erstellen, alle Gruppen eines Benutzers dokumentieren und Überschneidungen eliminieren.

Performance-Probleme bei großen Seitenbäumen. Ab etwa 1.000 Seiten wird die ACL-Berechnung laut Dokumentation spürbar, vor allem beim Anlegen von Inhaltselementen und beim Bearbeiten der Seiteneigenschaften; die Last wächst mit der Zahl der Unterseiten, für die eine ACL gilt. Die Berechnungen speichert be_acl bereits zwischen, auf Wunsch in Redis. Lösung: keine ACLs auf der Wurzelseite, globale Rechte über das klassische Rechtesystem vergeben und ACLs nur für Teilbäume einsetzen.

Rechte-Debugging ist schwierig. TYPO3 bietet kein eingebautes Tool, das anzeigt, warum ein Benutzer auf eine bestimmte Seite zugreifen kann oder nicht. Der Admin-Bereich “Backend User” zeigt die simulierte Ansicht, aber nicht die Rechte-Kaskade. Lösung: Das TYPO3 System Log analysieren (bei aktiviertem Debug-Modus loggt TYPO3 Zugriffsversuche) oder die SQL-Tabelle tx_beacl_acl direkt abfragen.

Migration und Versions-Kompatibilität

Seit Januar 2021 ist keine neue Version von be_acl erschienen. Die letzte Version 2.0.1 unterstützt nur TYPO3 v10, für v11, v12 und v13 gibt es kein Release.

Wer von TYPO3 v10 auf eine neuere Version wechselt, muss be_acl deshalb selbst portieren oder die Rechte auf Core-Bordmittel umstellen. Die bestehenden Regeln in der Tabelle tx_beacl_acl sind dafür die Grundlage; beim Portieren kommt ab v12 die geänderte Registrierung der Backend-Module hinzu.

Für Unternehmen, die auf TYPO3 v13 migrieren, empfiehlt sich vor dem Upgrade ein Export der bestehenden ACL-Regeln. TYPO3 v13 überarbeitet zwar die Rechteverwaltung im Backend, übernimmt aber keine Funktion von be_acl: Mehrere Gruppen mit eigenen Rechten auf derselben Seite kennt auch der Core von v13 nicht. Ob sich das Berechtigungskonzept mit Core-Rechten abbilden lässt, hängt von seiner Komplexität ab. Gosign analysiert bei TYPO3-Upgrades das bestehende ACL-Setup und empfiehlt die optimale Lösung, ob be_acl, Core-native Rechte oder eine Kombination.