Releasehinweis :: MAJOR CHANGE in KIX v28 (!)

[Torsten Thau]

MAJOR CHANGE in KIX v28 (KIX Start/Pro/Cloud)

Mit der kommenden Version 28 von KIX18 wird ein Umbruch begonnen: v28 wird Basisberechtigungen ("Base Permissions") einführen. Wir reagieren damit auf Wünsche nach besserer Performanz und Vereinfachung aber erfüllen dennoch weiterhin Anforderungen an komplexe Berechtigungsszenarien. Dieser Blogbeitrag kündigt die Änderungen an und erläutert diese.

siehe auch https://docs.kixdesk.com/display/K18AdminDECommunity/Basisberechtigungen



(i) Warum gibt es Basisberechtigungen?

Zum einen wurden die bislang primär verwendeten Objektberechtigungen als mühsam zu administrieren bewertet. Die Anlage von Berechtigungsstrukturen wird mit Basisberechtigungen vereinfacht. Die überwiegende Mehrzahl der Anwendungsfälle betrachtet nur Teams/Queues für die Rollendefinition. Das volle Potential der spezifischen Objektberechtigungen wurde nur selten genutzt.

Zum anderen ergaben sich Schwierigkeiten bei der Zuordnung von Tickets zu Teams/Queues und dem Setzen von zulässigen Bearbeitern/Verantwortlichen unter Beachtung der Objektberechtigungen.
Künftig werden Auswahlwerte für zu setzende (a) Teams/Queues, (b) Bearbeiter und(c) Verantwortliche ausschließlich auf Grund der Basisberechtigungen ermittelt.

Ein dritter Punkt ist die möglichst performante Anwendung von Berechtigungen für die Anzeige von Ticketlisten. Durch Anwendung von Berechtigungen direkt bei der Datenbanksuche werden Aufwände für codeseitig auszuführende Berechtigungsprüfungen (Objektberechtigungen) signifikant reduziert.



(ii) Was sind Basisberechtigungen?

Basisberechtigungen werden an "umgebenden" Objekten für Businessobjekte hinterlegt. Als Businessobjekte betrachten wir Tickets, Assets, FAQ-Artikel, Kontakte und Organisationen. Damit ergeben sich folgende "Paarungen"

• Tickets und Teams/Queues
• Assets und Assetklassen
• FAQ-Artikel und FAQ-Kategorien
• Kontakte und Organisationen
• Tickets und Organisationen

Basisberechtigungen werden zunächst nur für  Tickets in Teams/Queues eingeführt(!). Mittelfristig wird dieser Ansatz aber auf weiteren Paarungen ausgeweitet.

Basisberechtigungen in Queues/Teams werden direkt in der Bearbeitung eines Teams hinterlegt. Dabei wird eine Menge von Rollen und deren jeweilige Möglichkeiten in in Bezug auf das Team hinterlegt.

• Read: erlaubt das Lesen von Tickets in diesem Team. Es ist keine Veränderung oder Bearbeitung an dem Ticket möglich.
• Write: erlaubt das Erstellen und Verschieben von Tickets in diesem Team. Das Ticket kann ohne Read im weiteren jedoch nicht eingesehen werden.
• Read & Write: entspricht einem Vollzugriff. Diese Berechtigung wird benötigt um ein Ticket in irgendeiner Weise zu bearbeiten.

Abbildung 1 zeigt die künftige Bearbeitung von Teams/Queues:




(iii) Wie passt das ins KIX Berechtigungskonzept?

Basisberechtigungen wirken wie die bisher bereits eingesetzten Objektberechtigungen: Sie steuern ob der Zugriff auf ein Businessobjekt erlaubt wird. Sie wirken direkt "nach" Ressourcenberechtigungen. D.h. zunächst muss Berechtigung bestehen überhaupt auf eine Ressource (bspw. "/tickets" für "Tickets überhaupt") zugreifen zu dürfen. Danach werden die Basisberechtigungen geprüft. Wenn dieser Zugriff zulässig ist, werden weitere Objektberechtigungen geprüft und schließlich Eigenschaftsberechtigungen angewandt. In Abbildung 2 ist das ganze etwas grafischer dargestellt.





(iv) Wie wirken sich Basisberechtigungen aus?

Um in einem Team X ein Ticket zu erstellen, benötigt der ausführende Nutzer mindestens Write-Berechtigungen auf das gewählte Team/Queue. Umgekehrt bedeutet dies, das der Nutzer nur die Queues/Teams auswählen kann in denen er die erforderliche Berechtigung hat. Die Auswahl der Teams/Queues in Ticketerstellung und -bearbeitung wird eingeschränkt.

Um in einem Team X ein Ticket zu bearbeiten, benötigt ein Nutzer Read & Write Berechtigung auf das Team/Queue in dem/r sich das Ticket befindet. Umgekehrt bedeutet dies, dass der Nutzer nur solche Agenten als BEarbeiter oder Verantwortlicher setzen kann, die im Team diese Berechtigung inne haben. Die Auswahl der Bearbeiter und Verantwortlichen in Ticketerstellung und -bearbeitung wird eingeschränkt. Das betrifft auch die Sammelaktion auf Tickets.

Bei der Suche nach Tickets und in Team-/Queueansicht stehen nur diese Teams/Queues zur Verfügung, auf welche der Nutzer Read-Berechtigung hat. Auch können nur die Tickets eingesehen werden auf deren Teams/Queues Read-Berechtigung besteht.

Die Basisberechtigungen wirken für jeden Nutzer unabhängig vom Kontext, d.h. sie wirken auch im Self Service Portal (egal ob SSP1 oder SSP2).

Im Adminbereich und bei der Konfiguration von Jobs, Macro Actions, Benachrichtigungsregeln o.a. Automatismen gelten diese Einschränkungen für Auswahlen von Teams/Queues nicht.



(v) Was ändert sich für bestehende KIX18 Installationen ...und überhaupt?

Paradigmenwechsel: Fortan gilt das Motto "Base Permissions First!"

Bevor Objektberechtigungen vergeben werden, müssen die Möglichkeiten der Basisberechtigungen ausgeschöpft werden. Der bisherige Ansatz für Berechtigungen tritt zurück für die Sonderfälle, welche auf anderen Kriterien als Team/Queue Berechtigungen definieren.

Damit bestehende Installationen einen Performanzgewinn verzeichnen können, ist ein Wechsel von Objektberechtigungen auf Basisberechtigungen erforderlich. Zudem ermöglichen die bisherigen Berechtigungen keine korrekte Bearbeiter-/Verantwortlichen- oder Teamauswahl. Berechtigungsszenarien basierend auf Teams/Queues sollten also überarbeitet werden. Es ist jedoch nicht zwingend, denn die bisherigen Berechtigungen werden weiter wirken, sind aber weiterhin eine Performance-Belastung.

Die out-of-the-box Berechtigungsrollen welche KIX mitbringt werden auch mit Ausrollen der Basisberechtigungen wie beschrieben wirken. Die Rolle "Customer" erlaubt weiterhin den vollen Zugriff eines SSP-Nutzers entsprechend den Möglichkeiten und Berechtigungen im Self Service Portal. Die Rolle "Ticket Reader" erlaubt weiterhin den lesenden Zugriff auf alle Tickets unabhängig davon in welchem Team/Queue diese liegen. Die Rolle "Ticket Agent" erlaubt weiterhin den vollen Zugriff auf alle Tickets unabhängig davon in welchem Team/Queue diese liegen.

Die Rolle "Ticket Agent (w/o teams)" beinhaltet zwar weiterhin die grundlegenden Berechtigungen zum Bearbeiten von Tickets ohne konkrete Queuezuordnungen kann aber in Zusammenhang mit Basisberechtigungen nicht verwendet werden. Die Rolle "Ticket Agent (w/o teams)" ist veraltet und wird in zukünftigen Releases entfallen und dann nicht mehr ausgeliefert. Die grundlegenden Berechtigungen auf Tickets ohne Zugriffe auf konkrete Queues werden fortan von der Rolle "Ticket Agent Base Permission" bereit gestellt. Diese Rolle ist ab v28 der Grundstock für teamspezifische Berechtigungsrollen.

Wichtiger Hinweis:
Eigene Rollen welche auf den Vorgaberollen "Customer", "Ticket Agent (w/o teams)", etc. basieren (d.h. diese kopieren), müssen mit Installation/Update auf v28 eigenhändig mit Basisberechtigungen auf alle Teams/Queues versehen werden, damit die Sichtbarkeit von Tickets erhalten bleibt. Das gilt auch wenn zuvor genannte Rollen umbenannt wurden.

Sofern komplett ohne diese Rollen gearbeitet wurde und an den Teams/Queues keine spezifischen Berechtigungen benötigt werden, bleibt alles wie es war. Es sind dann keine Maßnahmen erforderlich.



(vi) Wie kann ich spezielle Rollen für Arbeit in Teams/Queues gestalten?

Sollen team-/queuespezifische Berechtigungen vergeben werden, wird empfohlen wie folgt vorzugehen:

• (1) Die erforderlichen spezifischen Rollen anlegen. Diesen Rollen müssen manuell keine Berechtigungen zugestanden werden. Das reine Erstellen reicht aus.
• (2) Im zweiten Schritt werden die Teams/Queues definiert und an jedem Eintrag hinterlegt, welche Rolle welche Berechtigung innerhalb dieses Teams hat.
• (3) Abschließend werden den betreffenden Nutzer mind. die Rollen "Agent User", "Ticket Agent Base Permission" sowie die relevanten spezifischen Rollen aus (1+2) zugeordnet.

(vii) Technische Details

Die Basisberechtigungen für Tickets werden auch in den Rollendefinitionen selbst hinterlegt. Dazu gibt es neben "Resource", "Object" und "Property" nun auch "Base::Ticket" als Berechtigungslayer. Das Ziel ist dabei eine einzelne Queue-ID. Sollen Basisberechtigungen für alle Teams/Queues gesetzt werden kann anstatt aller Queue-IDs ein "*" eingetragen werden.

• Die Basisberechtigung "Read" wird als -R--- (Read) abgebildet.
• Die Basisberechtigung "Write" wird als C-U-- (Create, Update) abgebildet.
• Die Basisberechtigung "Read & Write" wird als CRUD- (Create, Read, Update, Delete) abgebildet.

(viii) Zeitplanung Release v28

Die Bereitstellung des Releasekandidaten für v28 ist für das Osterwochende 2023 geplant. Das stable-Release wird nicht vor dem 18.04.2023 erfolgen. KIX Pro Kunden, die einen Vorab-Test des RC vornehmen möchten und noch keinen RC in ihren Repository haben, können dies per Support oder via unseres Beraterteams erfragen.