Berechtigungskonzept

Das Berechtigungskonzept von KIX 18 unterscheidet zwischen verschiedenen Zugriffsebenen, die einander bedingen.

Das heißt, zunächst muss eine Berechtigung bestehen, überhaupt auf eine Ressource (bspw. /tickets ) 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 KIX 18 werden folgende Berechtigungsarten verwendet:

Für leichtere Lesbarkeit wird die Notation "CRUDX" verwendet: 

Die Berechtigungen auf die einzelnen Ebenen sind vergleichbar mit einer Aktensammlung.

Abb.: Aktenanalogie der Berechtigungen

Für Subressourcen gilt:

Identifizierende Subressourcen (Artikel zu Tickets)

Berechtigungen auf identifizierende Subressourcen stellen eine kleine Besonderheit dar.

Um diese beschreiben zu können, wird der Stern-Platzhalter wie in /ticket/*/articles verwendet. Der Stern hat die gleiche Wirkung wie bspw. im Dateisystem und bedeutet hier: alle Elemente direkt unter /tickets/.

Beispiel:

Das Anlegen eines Artikels an Ticket Nr. 123 erfordert also: 

Basisberechtigungen werden an "umgebenden" Objekten für Businessobjekte hinterlegt. 

Businessobjekte sind Tickets, Assets, FAQ-Artikel, Kontakte und Organisationen. Damit ergeben sich folgende "Paarungen":

Die Basisberechtigungen für Tickets in Teams (Queues) werden direkt beim Anlegen/Bearbeiten eines Teams erteilt. Dabei werden Rollen ausgewählt und deren jeweiligen Berechtigungen in Bezug auf das Team hinterlegt.

Abb.: Pflege der Basisberechtigungen im Team Service Desk

Objektberechtigung erlauben eine weitergehende Prüfung des Objekts auf bestimmte Eigenschaften zur Gewährung/Entzug von Berechtigungen. Anwendungsfälle sind u.a.. der Ausschluss von Ticket mit sensiblen Inhalten (z.B. Typ "Incident-Security") oder spezifischer Kundenorganisationen. 

Die HTTP-Methode definiert welche Berechtigung gewährt/entzogen wird.

Bei CREATE/UPDATE erfolgt die Prüfung auf Basis der übermittelten, (neu) zu setzenden Eigenschaften (in der HTTP-Anfrage POST/PATCH).

Bei READ/DELETE werden die im Backend bzw. in der Datenbank bestehenden Eigenschaften verwendet.

Es kann dabei auf verschiedene Eigenschaften geprüft werden. Diese Prüfungen können mit dem logischen UND-Operator && verknüpft werden. Alternative Optionen (ODER-Verknüpfungen) können durch mehrere Berechtigungen abgebildet werden. Des Weiteren kann gegen absolute Werte oder Eigenschaften des ausführenden Nutzers mittels des Platzhalters $CurrentUser geprüft werden. 

Optional besteht die Möglichkeit, Property-Berechtigungen einzuschränken. Mittels IF  können Eigenschaften für bestimmte Objekte definiert werden.

Zulässige Vergleichsoperatoren sind: LT, LTE, GT, GTE, CONTAINS, LIKE, IN, STARTSWITH, ENDSWITH, EQ, NE.  (s. auch: Übersicht der Operatoren)

Die Vergleichsoperatoren können mittels ! negiert werden.

Beispiele zur Prüfung von Objekteigenschaften

# ALLOW full access to ticket
# WHERE title contains "Security"
#   AND priority-ID is 3
Object | /tickets/*{Ticket.Title CONTAINS "Security" && Ticket.PriorityID LT 3} | CRUD-
 
# ALLOW to read tickets
# WHERE SLA is not 5
#   AND team/ueue is not 1,2 or 3
Object | /tickets/*{Ticket.SLAID NE 5 && Ticket.QueueID !IN [1,2,3]} | -R----
 
# ALLOW to read tickets
# WHERE title LIKE "*something*"
Object | /tickets/*{Ticket.Title LIKE "*something*"} | -R----
 
# DO NOT ALLOW ACCESS to tickets
# WHERE contactID differs from current users contact id AND
#   AND tickets organization is not current users primary organisation
Object | /tickets/*{Ticket.ContactID NE $CurrentUser.Contact.ID && Ticket.OrganisationID NE $CurrentUser.Contact.PrimaryOrganisationID} | ------
 
# DO NOT ALLOW ACCESS to articles
# WHERE customer visible flag is not set
Object | /tickets/*/articles/*{Article.CustomerVisible NE1} | -----
 
# ALLOW full access to ticket
# WHERE title contains "Security"
#   AND priority-ID is 3
Object | /tickets/*{Ticket.[PriorityID,StateID] IF Ticket.Title CONTAINS "Security" && Ticket.PriorityID LT 3} | -----

Eigenschaftsberechtigungen wirken nur auf bestehende Objekte. Eine CREATE-Berechtigung kann damit nicht gesetzt oder entzogen werden.

Die optionale Angabe von Eigenschaftsberechtigungen erlaubt die Beschränkung des Zugriffs auf Objektattribute. Um diese angeben zu können, wird Kenntnis der vorhandenen Attribute benötigt.

Im Hinblick auf dynamische Felder können diese in versch. Umgebungen variieren.

Eine konkrete Anwendung erfolgt in Rolle "Customer". Sie schränkt die im Self Service Portal darstellbaren Ticketeigenschaften ein, indem eine White-List definiert wird.

Beispiel Eigenschaftsberechtigungen

# LIMIT shown ticket attributes to the mentioned (line break for improved readability)
Property | /tickets/*{Ticket.[TicketNumber,Age,Articles,Changed,ContactID,Created,CreateTimeUnix,DynamicFields,OrganisationID,PriorityID,QueueID,StateID,TypeID]} | -R---

Rollen werden dadurch definiert, dass sie neben allgemeinen Kopfdaten wie Name, Gültigkeit, Kommentar etc. eine Menge n aus Berechtigungen beinhalten (1: n-Beziehung → 1 Rolle : n Berechtigungen).

Einem Nutzer können mehreren Rollen zugeordnet werden. Die resultierenden Berechtigungen sind dabei die Vereinigungsmenge aller einzelnen Rollenberechtigungen. Ein DENY besitzt dabei stets die höchste Priorität (s. Berechtigungsarten). 

Beispiele: 

Resource | /contacts                                         | -R---
Object   | /contacts/*{Contact.PrimaryOrganisationID NE 2}   | -R--- # specific (limit access to contacts not belonging to Org wit ID 2)
Resource | /links                                            | CRUD
Resource | /organisations                                    | -R---
Object   | /organisations/*{Organisation.Number NE "SECRET"} | -R--- # specific (limit access to org. with other Number than "SECRET")
Resource | /system/automation                                | -RU--
Resource | /system/automation/*                              | -----
Resource | /system/automation/macros                         | --U--
Resource | /system/automation/macros/*                       | -----
Resource | /system/communication                             | -R---
Resource | /system/communication/*                           | -----
Resource | /system/communication/channels                    | -R---
Resource | /system/communication/sendertypes                 | -R---
Resource | /system/communication/systemaddresses             | -R---
Resource | /system/objectactions                             | -R---
Resource | /system/objectactions/*                           | -----
Resource | /system/objectactions/2                           | -R---
Resource | /system/objectactions/3                           | -R---
Resource | /system/objectactions/4                           | -R---
Resource | /system/objectactions/6                           | -R---
Resource | /system/slas                                      | -R---
Resource | /system/templates                                 | -R---
Resource | /system/templates/*                               | -----
Resource | /system/templates/4                               | -R---
Resource | /system/templates/5                               | -R---
Resource | /system/templates/7                               | -R---
Resource | /system/textmodules                               | -R---
Resource | /system/ticket                                    | -R---
Object   | /system/ticket/*{Ticket.OrganisationID EQ 2}      | ----- # specific (prohibit access to tickets of Org 2)
Resource | /system/ticket/locks                              | -R---
Resource | /system/ticket/priorities                         | -R---
Resource | /system/ticket/states                             | -R---
Resource | /system/ticket/types                              | -R---

Ressourcenberechtigungen sind erforderlich, um generellen Zugriff bzw. Zugriff auf bestimmte Bereiche der GUI zu erhalten. So wird bspw. mindestens ein READ auf die Ressource /tickets für den Zugriff auf das Ticket-Modul benötigt. Dies gilt ebenso für den Zugriff auf alle anderen Objekte wie FAQ (/faq), Assets (/cmdb) usw.

Die Zugehörigkeit von Nutzern zu Rollen ist Voraussetzung für die Nutzung der konfigurierbaren Ticket- und Artikelaktionen sowie der Ticketvorlagen.

Die Berechtigungen und angezeigten Inhalte eines Kundennutzers im SSP werden durch die Vorgaberolle "Customer" definiert.

Der Zugriff auf Objekte des Assetmanagements wird weiterhin im Backend durch die Konfiguration des Zuordnungs-Mappings definiert und ergänzt das Berechtigungssystem (SysConfig-Schlüssel AssignedConfigItemsMapping).