OTOBO ACLs

Zugriffskontrolllisten (ACLs) in OTOBO sind das Fundament einer robusten Rechteverwaltung. In diesem Subthema lernen Sie:

1. Konzepte und Business Value: Warum ACLs unverzichtbar sind.
2. Architekturüberblick: Wie das ACL-Subsystem intern aufgebaut ist.
3. Match vs. Action: Grundstruktur einer ACL.
4. Systemkonfigurationen: Wichtige SysConfig-Einstellungen rund um ACLs.

---

1. Konzepte & Business Value

ACLs definieren, welche Aktionen Agenten und Kunden im Ticketsystem ausführen dürfen – automatisiert und kontextsensitiv.

• Sicherheit: Schützen Sie sensible Funktionen (z. B. Ticket-Schließen) vor unautorisierter Nutzung.
• Usability: Blenden Sie irrelevante Buttons oder Menüs dynamisch aus, um den Anwender nicht zu überfrachten.
• Automatisierung: Steuern Sie Ticket-Flows (Priorisierung, Eskalation, Zuweisung) direkt über ACL-Regeln, ohne zusätzlichen Code.
• Wartbarkeit: Exportieren, importieren und versionieren Sie ACLs zentral – ideal für Multi-Instanz-Umgebungen.

1.1 Rollen- und Kriterien-basierte ACLs

• Rollenbasiert: Zuweisung anhand von Agenten-Rollen oder Gruppen (z. B. Admin vs. Support-Agent).
• Kriterienbasiert: Steuerung durch Ticketattribute (Queue, Status, Priority, DynamicFields, CustomerID).

Kombination beider Ansätze ermöglicht präzise Regeln, z. B.: „Nur Senior-Agenten verschieben Tickets mit Priorität > 3 in die Entwicklung-Queue.“

---

2. Architektur-Überblick

Das OTOBO-ACL-Subsystem verteilt sich auf mehrere Kernkomponenten:

Komponente	Aufgabe
Kernel::System::ACL::DB::ACL	Perl-Backend: Persistiert und lädt ACLs aus der Datenbank
Kernel::System::YAML	Serialisiert config_match & config_change als YAML-Text
Kernel::System::Cache	Cacht ACL-Abfragen mit TTL (SysConfig: ACL::CacheTTL)
acl_sync Tabelle	Protokolliert, welche ACLs neu sind oder geändert wurden (sync_state), um Deployments zu triggern
ZZZACL.pm	Generierte Perl-Datei, die beim Deploy alle validierten ACLs in den Ticket-Modulen bereitstellt

# Beispiel: YAML-Serialisierung vor DB-Insert
my $YAML = $Kernel::OM->Get('Kernel::System::YAML');
my $ConfigMatchYAML  = $YAML->Dump(Data => $Param{ConfigMatch});
my $ConfigChangeYAML = $YAML->Dump(Data => $Param{ConfigChange});
$DBObject->Do(
    SQL  => 'INSERT INTO acl (..., config_match, config_change, ...) VALUES (?, ?, ?, ...)',
    Bind => [\$ConfigMatchYAML, \$ConfigChangeYAML, ...],
);

Hinweis: Superuser (UserID 1) ignoriert alle ACLs automatisch – um sich nicht auszusperren.

---

3. Grundstruktur einer ACL: Match vs. Action

Abschnitt	Aufgabe
Match	Definiert Bedingungen: Ticketattribute (Properties) oder DB-Werte (PropertiesDatabase) prüfen.
Action	Legt fest, welche UI-Elemente (Buttons, Felder) ein-/ausgeblendet werden (Possible, PossibleAdd, PossibleNot) oder welche Aktionen ausgeführt werden (Status-/Queue-Wechsel).

Beispiel Match-Optionen:

• Queue, Status, Priority
• DynamicField_<Name>, CustomerUser, Owner
• Frontend::Module (AgentTicketZoom, CustomerTicketCreate)

Beispiel Action-Optionen:

• Possible: Whitelist z. B. nur bestimmte Queues oder Status zulassen
• PossibleAdd: Zusätzliche Werte in begrenzter Auswahl hinzufügen
• PossibleNot: Bestimmte Buttons (z. B. AgentTicketClose) aus UI entfernen

---

4. Wichtige SysConfig-Einstellungen

Oben genannte Kernelemente werden über SysConfig konfiguriert:

Schlüssel	Beschreibung	Beispielwert
ACL::CacheTTL	Cache-Lebensdauer in Sekunden (Backend)	3600
ACLKeysLevel1MatchTicket	Erlaubte erste Ebene für Match (Properties, PropertiesDatabase)	Properties, PropertiesDatabase
ACLKeysLevel1ChangeTicket	Erlaubte erste Ebene für Change (Possible, PossibleAdd, PossibleNot)	Possible, PossibleAdd, PossibleNot
ACLKeysLevel2::PropertiesTicket	Erlaubte Match-Keys (Queue, State, DynamicField, etc.)	Queue, State, CustomerUser, ...
ACLKeysLevel2::PossibleTicket	Erlaubte Change-Keys (Form, FormStd, Action, Process, Ticket)	Form, FormStd, Action, ...
ACLKeysLevel3::Actions###DefaultTicket	Liste aller möglichen Aktionen in der UI (AgentTicketClose, AgentTicketEmail, …)	(s. Liste)

Tipp: Passen Sie ACLKeysLevel* an, um das ACL-UI nur mit relevanten Einträgen zu bestücken.

Evaluierung, Stop-on-Match & Performance

Die Evaluierung von ACLs (Access Control Lists) bestimmt, welche Regeln angewendet werden, wenn ein Ticket geladen oder eine Aktion im Ticketsystem ausgeführt wird. Eine effiziente Konfiguration dieser Abläufe sowie gezielte Performance-Optimierungen sind entscheidend, um ein flüssiges und skalierbares Agenten-Interface zu gewährleisten.

Evaluierungszyklus

Jedes Mal, wenn ein Agent ein Ticket öffnet oder eine Aktion (z. B. Button-Klick) ausführt, durchläuft OTOBO die Liste aller aktiven ACLs geordnet nach ihrem Sortierschlüssel (Name oder ID). Folgender Ablauf zeigt den Prüf- und Ausführungsprozess:

flowchart TB
    A[Ticket Load / User Action] --> B{Liste aktiver ACLs}
    B --> C[Prüfung ACL1: Match?]
    C -->|ja| D[Ausführen von ConfigChange 1]
    C -->|nein| E[Prüfung ACL2]
    D --> F{StopAfterMatch=1?}
    F -->|ja| G[Stopp: keine weiteren ACLs]
    F -->|nein| E
    E -->|…| H[Prüfung ACLN]
    H -->|ja| I[Ausführen von ConfigChange N]
    H -->|nein| J[Standardverhalten]

• Match (ConfigMatch): Hier werden Kriterien wie Queue, Status, Priority oder DynamicFields geprüft.
• Change (ConfigChange): Definiert, welche UI-Elemente entfernt oder hinzugefügt werden (Possible, PossibleAdd, PossibleNot) oder welche automatischen Aktionen erfolgen (Queue-/Statuswechsel).
• StopAfterMatch: Wird auf 1 gesetzt, bricht die Verarbeitung nach der ersten zutreffenden ACL ab.

Merke: Ein korrekt gesetztes StopAfterMatch verhindert, dass nachfolgende ACLs unbeabsichtigte Änderungen auslösen.

Stop-on-Match-Strategien

Option	Wirkung
StopAfterMatch=1	Sobald eine ACL matcht, wird keine weitere überprüft – ideal für exklusive Regeln.
StopAfterMatch=0	Alle ACLs werden geprüft – nötig, wenn mehrere ACLs unabhängig voneinander eingreifen sollen.

Tipp: Nummerische Präfixe (z. B. 100-, 200-) im ACL-Namen steuern die natürliche Sortierung und damit die Priorität kritisch wichtiger Regeln.

Performance-Optimierung

Ein großes Set an ACLs kann die Ladezeiten von Ticketformularen verlängern. Diese Maßnahmen helfen, die Performance zu steigern:

1. CacheTTL anpassen: In SysConfig unter ACL::CacheTTL (z. B. 3600 s) legen Sie fest, wie lange geladene ACL-Definitionen im Cache verbleiben.
2. Preselection-Cache aktivieren: Das Modul TicketACL::ACLPreselection füllt vorausgewählte Optionen vorab und spart wiederholte Prüfungen.
3. Regel-Reduktion: Entfernen Sie veraltete oder doppelte ACLs und bündeln Sie ähnliche Regeln.
4. Sequenz optimieren: Platzieren Sie häufig zutreffende ACLs an den Anfang der Liste.
5. Indexierte Felder: Nutzen Sie DB-Indexe für DynamicFields und andere häufig abgefragte Properties.

<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Cache-Lebensdauer für DB-ACL-Backends in Sekunden.</Description>
</Setting>

Wartung & Best Practices

Praxis	Nutzen
YAML-Export	Versionieren Sie ACLs in Git, um Änderungen nachzuvollziehen.
Dokumentation	Erstellen Sie ein Change-Log mit Zeitstempeln, Autor und Ziel der ACL.
Regel-Review	Regelmäßige Überprüfung im Team verhindert Überschneidungen.
Testumgebung	Validieren Sie neue ACLs mit kontrollierten Testtickets.
Log-Debugging	Aktivieren Sie Debug-Logs (TicketACL::Debug::Enabled) für detaillierte Einblicke.

Debugging konfigurieren

<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>ACL-Debugging aktivieren</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filter für Debug-Ausgaben auf Ticket-ID.</Description>
</Setting>

Durch diese gezielten Strategien stellen Sie sicher, dass Ihre ACL-Infrastruktur in OTOBO sowohl leistungsfähig als auch wartbar bleibt – selbst in großen, verteilten Umgebungen.

Praxisbeispiele, Governance & Referenz

In diesem abschließenden Artikelteil zeigen wir anhand konkreter Szenarien, wie ACLs in OTOBO praxisnah eingesetzt werden. Anschließend behandeln wir bewährte Governance-Methoden und verweisen auf weiterführende Referenzen.

Praxisbeispiele

1. Automatische Priorisierung in die “Alarm”-Queue

Ziel: Tickets mit Priorität 5 (sehr hoch) sofort in die Queue Alarm verschieben und Bearbeiter benachrichtigen.

- Name: "100-Auto-Alarm"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    Properties:
      Priority:
        ID: [ 5 ]
  ConfigChange:
    PossibleNot:
      Form:
        - ticketCreateQuickClose
    PossibleAdd:
      Form:
        - ticketCreateNotifyOwner
    Action:
      Queue: "Alarm"

ACL-Grunddaten und Match-Einstellung

ACL-Change: Queue-Wechsel und Button-Add

---

2. Eskalationsschutz für “sehr hoch” priorisierte Tickets

Ziel: Verhindern, dass Tickets mit Datenbank-Priorität 5 geschlossen werden.

- Name: "101-No-Close-High"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    PropertiesDatabase:
      Priority:
        Name: [ "5" ]
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketClose

ACL-Change: Close-Button ausblenden

---

3. UI-Restriction pro Queue

Ziel: In der Queue Support soll die Statusoption gelöst nicht verfügbar sein.

- Name: "102-Hide-Resolved-Support"
  ValidID: 1
  ConfigMatch:
    Properties:
      Queue:
        Name: [ "Support" ]
  ConfigChange:
    PossibleNot:
      FormStd:
        - State::resolved

ACL-Change: Status-Option entfernen

---

4. Kundenprozess-Beschränkung

Ziel: Kunden dürfen eigene Tickets nicht in andere Queues verschieben.

- Name: "103-Cust-No-Reassign"
  ValidID: 1
  ConfigMatch:
    Properties:
      Frontend:
        Action:
          - CustomerTicketZoomReply
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketMove

ACL-Change: Move-Button ausblenden für Kunden

---

5. Zeitbasierte Eskalation nach 48 Stunden

Ziel: Tickets, die älter als 48 Stunden offen sind, werden automatisch an Senior-Agenten zugewiesen.

- Name: "104-Escalate-48h"
  ValidID: 1
  ConfigMatch:
    Properties:
      Ticket:
        CreateTimeOlderThan: 48h
  ConfigChange:
    Action:
      Owner: "Senior-Agenten"

Hinweis: Dieses Szenario erfordert gegebenenfalls eine Erweiterung für zeitbasierte Match-Kriterien.

---

Governance & Dokumentation

Maßnahme	Beschreibung
Namenskonvention	Numerische Präfixe (z. B. 100-, 200-) für Sortierung und Übersichtlichkeit.
Changelog	Protokollieren Sie Name, Comment, ChangeTime und ChangeBy für jede ACL-Änderung.
Review-Prozess	Führen Sie regelmäßig Reviews durch, um Überschneidungen und Konflikte zu vermeiden.
Versionierung	Exportieren Sie ACLs als YAML und versionieren Sie in Git oder einem Dokumentationstool.
Testing	Validieren Sie ACLs in einer Testumgebung mit spezifischen Testtickets.

---

Weiterführende Referenzen

• ACL-Referenz (YAML): Kernel/Config/Files/ZZZACL.pm (generiert)
• SysConfig ACL-Keys: Level 1–3-Begriffe zur Feinsteuerung (Core::Ticket::ACL)
• DynamicField-Dokumentation: Anbindung dynamischer Felder in ACLs

Mit diesen Praxisbeispielen und Governance-Empfehlungen verfügen Sie nun über das Rüstzeug, um ACLs in OTOBO sicher, effizient und nachvollziehbar zu betreiben.

Häufig gestellte Fragen

Was steuern Access Control Lists in OTOBO?

ACLs in OTOBO sind ein zentrales Instrument zur detaillierten Rechteverwaltung und Workflow-Steuerung. Sie definieren präzise, welche Aktionen Agenten und Kunden im Ticketsystem ausführen dürfen und welche Benutzeroberflächenelemente (Buttons, Felder, Menüs) kontextsensitiv ein- oder ausgeblendet werden. Dies trägt maßgeblich zur Sicherheit bei, indem sensible Funktionen vor unautorisierter Nutzung geschützt werden. Gleichzeitig verbessern ACLs die Usability, indem sie die Oberfläche dynamisch an den jeweiligen Kontext anpassen und so unnötige Optionen ausblenden. Sie ermöglichen auch eine Automatisierung von Ticket-Flows, wie Priorisierung oder Zuweisung, direkt über definierte Regeln. Die zentrale Verwaltung und Versionierung der ACLs erleichtert zudem die Wartbarkeit in komplexen Umgebungen.Quellen:- Access Control Lists (ACL) - OTOBO Documentation- Process Management & Automation - OTOBO Docs - Softoft

Gelten ACLs auch für den Superuser?

Nein, ACLs gelten grundsätzlich nicht für den Superuser in OTOBO. Der Superuser, der typischerweise die UserID 1 besitzt, ignoriert alle konfigurierten Access Control Lists automatisch. Diese Ausnahme ist eine bewusste Designentscheidung, um zu verhindern, dass Administratoren sich selbst aus dem System aussperren oder den Zugriff auf kritische Funktionen verlieren. Es stellt sicher, dass der Superuser stets die volle Kontrolle über das System behält, unabhängig von den definierten ACL-Regeln. Dies ist eine wichtige Sicherheitsmaßnahme für die Systemadministration und -wartung.Quellen:- OTOBO ACLs - Softoft OTOBO community guide- Access Control Lists (ACL) - OTOBO Documentation

Was ist der Unterschied zwischen Match und Action in einer OTOBO ACL?

In der Grundstruktur einer OTOBO ACL sind "Match" und "Action" die zwei Hauptabschnitte, die zusammenwirken, um eine Regel zu definieren.Der Match-Abschnitt legt die Bedingungen fest, unter denen eine ACL aktiv wird. Hier werden Ticketattribute (sogenannte Properties) oder Werte aus der Datenbank (PropertiesDatabase) geprüft. Beispiele für Match-Optionen sind die Queue, der Status, die Priority eines Tickets, DynamicField_<Name> oder der CustomerUser. Auch das Frontend::Module, also das aktuell genutzte Modul im Agenten- oder Kundenbereich, kann als Match-Kriterium dienen.Der Action-Abschnitt definiert, welche Konsequenzen eintreten, wenn die Match-Bedingungen erfüllt sind. Dies kann das Ein- oder Ausblenden von UI-Elementen (Possible, PossibleAdd, PossibleNot) oder die Steuerung erlaubter Ticketwerte sein. Zum Beispiel kann Possible eine Whitelist für bestimmte Queues oder Status definieren, PossibleAdd zusätzliche Werte zu einer Auswahl hinzufügen und PossibleNot bestimmte Buttons, wie AgentTicketClose, aus der Benutzeroberfläche entfernen.Quellen:- OTOBO ACLs - Softoft OTOBO community guide- Access Control Lists (ACL) - OTOBO Documentation

Was sollte ich über Rollen- und Kriterien-basierte ACLs wissen?

OTOBO ACLs können auf zwei Hauptansätzen basieren: rollenbasiert und kriterienbasiert. Rollenbasierte ACLs steuern Berechtigungen basierend auf den zugewiesenen Agenten-Rollen oder Gruppen. Ein typisches Beispiel wäre die Unterscheidung zwischen einem "Admin" und einem "Support-Agenten", wobei jeder Rolle unterschiedliche Rechte zugewiesen werden. Kriterienbasierte ACLs hingegen nutzen spezifische Ticketattribute zur Steuerung. Dazu gehören beispielsweise die Queue, der Status, die Priority, DynamicFields oder die CustomerID eines Tickets.Die wahre Stärke von OTOBO ACLs liegt in der Kombination beider Ansätze. Dies ermöglicht die Erstellung hochpräziser und flexibler Regeln. Ein Beispiel hierfür wäre: „Nur Senior-Agenten dürfen Tickets mit einer Priorität von über 3 in die Entwicklung-Queue verschieben und den Status auf 'Wartet auf Entwicklung' setzen.“ Diese Kombination erlaubt eine feingranulare Kontrolle, die sowohl die Rolle des Agenten als auch die spezifischen Eigenschaften des Tickets berücksichtigt.Quellen:- OTOBO ACLs - Softoft OTOBO community guide- Access Control Lists (ACL) - OTOBO Documentation

Wie funktioniert die Evaluierung von ACLs und was bedeutet "Stop-on-Match"?

Die Evaluierung von ACLs ist ein kritischer Prozess, der bestimmt, welche Regeln angewendet werden, wenn ein Ticket geladen oder eine Aktion im Ticketsystem ausgeführt wird. Jedes Mal, wenn ein Agent ein Ticket öffnet oder eine Aktion ausführt (z. B. einen Button klickt), durchläuft OTOBO die Liste aller aktiven ACLs. Diese Liste wird nach ihrem Sortierschlüssel (Name oder ID) geordnet abgearbeitet.Der Ablauf ist wie folgt:- Das System prüft die erste ACL auf ihre Match-Bedingungen.- Wenn die Bedingungen erfüllt sind, wird der ConfigChange-Abschnitt dieser ACL ausgeführt.- Anschließend wird geprüft, ob die Option StopAfterMatch=1 für diese ACL gesetzt ist.- Ist StopAfterMatch=1, stoppt die Evaluierung sofort, und keine weiteren ACLs werden geprüft oder angewendet.- Ist StopAfterMatch nicht gesetzt oder auf 0, fährt die Evaluierung mit der nächsten ACL in der Liste fort.Dieser Zyklus wird fortgesetzt, bis alle ACLs geprüft wurden oder eine ACL mit StopAfterMatch=1 gefunden wurde. Eine effiziente Konfiguration, insbesondere der bewusste Einsatz von StopAfterMatch, ist entscheidend für die Performance und die korrekte Anwendung der Berechtigungen.Quellen:- OTOBO ACLs - Softoft OTOBO community guide- Access Control Lists (ACL) - OTOBO Documentation

Welche wichtigen SysConfig-Einstellungen beeinflussen OTOBO ACLs?

Mehrere SysConfig-Einstellungen sind entscheidend für die Konfiguration und das Verhalten von OTOBO ACLs. Hier sind einige der wichtigsten:- ACL::CacheTTL: Definiert die Lebensdauer des ACL-Caches in Sekunden (Backend). Ein höherer Wert kann die Performance verbessern, da ACL-Abfragen seltener aus der Datenbank geladen werden müssen.- ACLKeysLevel1MatchTicket: Legt die erlaubten ersten Ebenen für den Match-Abschnitt einer ACL fest, typischerweise Properties und PropertiesDatabase.- ACLKeysLevel1ChangeTicket: Bestimmt die erlaubten ersten Ebenen für den Change-Abschnitt, wie Possible, PossibleAdd und PossibleNot.- ACLKeysLevel2::PropertiesTicket: Listet die erlaubten Match-Keys der zweiten Ebene auf, z. B. Queue, State, CustomerUser oder DynamicField_<Name>.- ACLKeysLevel2::PossibleTicket: Definiert die erlaubten Change-Keys der zweiten Ebene, die steuern, welche Formularelemente oder Aktionen beeinflusst werden können (z. B. Form, Action).- ACLKeysLevel3::Actions###DefaultTicket: Enthält eine umfassende Liste aller möglichen Aktionen in der Benutzeroberfläche, wie AgentTicketClose oder AgentTicketEmail, die über ACLs gesteuert werden können.Es ist ratsam, die ACLKeysLevel*-Einstellungen anzupassen, um die ACL-Benutzeroberfläche nur mit den tatsächlich relevanten Einträgen zu bestücken und so die Übersichtlichkeit zu erhöhen.Quellen:- OTOBO ACLs - Softoft OTOBO community guide- Access Control Lists (ACL) - OTOBO Documentation