Benutzerrollen und Rechte

SwissMentor verwendet ein mehrschichtiges Berechtigungssystem. Es besteht aus Profilen (grobe Benutzerart), Zugriffsgruppen (ACL-Regeln auf Objektebene) und Richtlinien (feingranulares Systemverhalten).

Benutzer

Ein Benutzer ist ein Login-Konto, das mit einer Person in SwissMentor verknüpft ist. Die Verwaltung erfolgt unter System-Administration > Benutzer.

Eigenschaften eines Benutzerkontos:

Benutzername (Login)
Authentifizierungsmethode: Lokales SwissMentor-Passwort (SM) oder Microsoft Entra ID
Status: Aktiv oder gesperrt
Zwei-Faktor-Authentifizierung (OTP optional oder erzwungen)
Letzter Login, Anmeldeversuche

Ein Benutzer ist immer eine Person. Die Zuordnung erfolgt 1:1 über die PersonID.

Profile (Benutzerarten)

Das Profil bestimmt, welche Module, Menüs und Grundfunktionen ein Benutzer sehen darf. Es ist die grobste Ebene der Zugriffsteuerung.

Profil	Code	Beschreibung
Administrator	`ADMIN`	Vollzugriff, alle ACL-Prüfungen werden übersprungen
Power-User	`POWERUSER`	Operative Benutzer mit erweitertem Zugriff
Lehrperson	`TEACHER`	Zugriff auf eigene Kurse und Klassen
Lernende/r	`STUDENT`	Eingeschränkter Zugriff auf eigene Daten
Elternteil	`PARENT`	Lesezugriff auf Daten des eigenen Kindes
Betrieb	`VOCTRAINER`	Betriebsbezogener Zugriff im Lehrlingswesen
Manager	`MANAGER`	Führungssicht
Coach	`COACH`	Coaching-Funktionen
Betreuung	`CARETAKER`	Betreuungsfunktionen

Das Profil wird nicht direkt am Benutzer vergeben, sondern ergibt sich aus den Rollen (_ACCESSROLE), die dem Benutzer über Mitgliedschaften zugeordnet sind.

Rollen (_ACCESSROLE)

Eine Rolle ist ein Objekt mit dem Objekttyp _ACCESSROLE. Personen werden über Mitgliedschaften einer Rolle zugeordnet. Jede Rolle hat einen ProfileCode, der das Profil des Benutzers bestimmt.

Eine Person kann mehrere Rollen haben. Das System kombiniert die Profile aller zugewiesenen Rollen.

Wichtig: Wenn ein Benutzer Mitglied in einer Gruppe mit dem Code ADMIN ist, lädt das System automatisch alle existierenden Zugriffsgruppen für diesen Benutzer — er hat somit vollen Zugriff.

Zugriffsgruppen (_ACCESSGROUP)

Zugriffsgruppen sind Objekte mit dem Objekttyp _ACCESSGROUP. Sie bilden die Grundlage für das ACL-System (Objektrechte). Personen werden ebenfalls über Mitgliedschaften einer Zugriffsgruppe zugeordnet.

Zugriffsgruppen erhalten ACL-Regeln, die festlegen, welche Rechte Mitglieder dieser Gruppe auf bestimmten Objekten haben.

Objektrechte (ACL)

Das ACL-System (Access Control List) steuert den Zugriff auf einzelne Objekte in SwissMentor. Es ist das feinste und mächtigste Berechtigungswerkzeug.

Zugriffsrechte im Überblick

Recht	Code	Bedeutung
Lesen	`READ`	Objekt anzeigen
Lesen (alle)	`READALL`	Alle Felder inkl. sensible anzeigen
Lesen (Buchh.)	`READACCOUNTING`	Buchhaltungsdaten lesen
Lesen (Kalender)	`READCALENDAR`	Kalender/Termine lesen
Lesen (Mitglieder)	`READMEMBER`	Mitgliederlisten einsehen
Lesen (Dateien)	`READFILE`	Dateien abrufen
Lesen (Spezial)	`READSPECIAL`	Spezialfelder lesen (z.B. Lohn)
Erstellen	`INSERT`	Neue Objekte anlegen
Bearbeiten	`UPDATE`	Objekte ändern
Löschen	`DELETE`	Objekte löschen
Status	`STATUS`	Status-/Workflow-Übergänge auslösen
Objekt-Aktion	`PROCESS`	Objekt-Aktionen ausführen
Kategorie	`TAG`	Kategorien zuweisen
Kalender bearb.	`UPDATECALENDAR`	Kalendereinträge bearbeiten

Zustand einer Regel

Jede ACL-Regel hat einen Zustand:

Zustand	Wert	Bedeutung
Erlaubt	`1`	Zugriff gewähren
Undefiniert	`0`	Keine Aussage (Standard wenn keine Regel greift)
Verweigert	`-1`	Zugriff explizit verweigern

Verweigert (-1) hat Vorrang gegenüber Erlaubt (1) — Deny overrides Allow.

Auf wen gilt eine Regel?

Eine ACL-Regel kann auf verschiedene Subjekte angewendet werden:

Bedingung	Feld	Bedeutung
Jeder	`everybody = true`	Gilt für alle Benutzer
Direkte Person	`personID`	Gilt nur für diese eine Person
Eigentümer	`owner = true`	Gilt für den Eigentümer des Objekts
Eigene Person	`ownPerson = true`	Person ist selbst das Objekt (z.B. eigenes Profil)
Mitglied des Objekts	`ownMember = true`	Person ist Mitglied des Objekts selbst
Mitglied einer Gruppe	`memberOfObjectID`	Person ist Mitglied einer bestimmten Gruppe
Mitgl. eines Elternobjekt-Typs	`memberOfParentObjecttype`	Person ist Mitglied in einem übergeordneten Objekt des angegebenen Typs

Vererbung (Rekursion)

ACL-Regeln können vererbt werden:

Option	Bedeutung
`recursiv = false`	Gilt nur für das direkte Objekt
`recursiv = true`	Gilt für das Objekt und alle Unterobjekte
`recursiveOnlyChildren = true`	Gilt nur für Unterobjekte, nicht für das Objekt selbst

Das System durchläuft beim ACL-Check die gesamte Elternhierarchie (via CHILD-Links). Objekte mit aclInherit = true erben Regeln von ihrem Elternobjekt.

Typ-basierte Regeln (ObjectType-ACL)

ACL-Regeln können auch auf Objekttypen statt auf einzelne Objekte angewendet werden. Eine Regel auf den Objekttyp _BILL gilt dann für alle Rechnungen im System. Die Regel gilt, wenn acl.objectType = objectType.objectType oder = objectType.sysType oder = '_ALL_' (für alle Typen).

Wie der Zugriffscheck funktioniert

Das System nimmt den Minimumwert aller passenden Regeln: Ein einziges “Verweigert” (-1) reicht, um den Zugriff zu blockieren, auch wenn andere Regeln “Erlaubt” sagen.

Objekt-Aktionen einschränken

Wenn einer ACL-Regel das Recht PROCESS gegeben wird, kann zusätzlich über AclRightProcessStep eingeschränkt werden, welche spezifischen Objekt-Aktionen erlaubt sind. Sind keine Einschränkungen definiert, sind alle Objekt-Aktionen erlaubt.

Whitelist (temporäre Zugriffsregeln)

Neben den permanenten ACL-Regeln gibt es einen Whitelist-Mechanismus für zeitlich begrenzte Zugriffsrechte. Ein Whitelist-Eintrag:

Gilt für eine bestimmte Person auf einem bestimmten Objekt
Hat ein Ablaufdatum (validUntil)
Hat einen Zustand (Erlaubt oder Verweigert)
Wird durch eine Whitelist-Regel (AclWhitelistRule) generiert, die auf einer SQL-Abfrage basiert

Der Whitelist-Check erfolgt vor dem normalen ACL-Check und hat Vorrang.

Whitelist-Regeln: Sicherheitshinweis

Whitelist-Regeln liegen in der Tabelle Object.UserAclWhitelistRule. Die dort hinterlegte SQL-Abfrage wird bei jedem Whitelist-Refresh unverändert mit dem Datenbank-Login der Applikation ausgeführt.

Das bedeutet:

Wer eine Whitelist-Regel schreiben kann, kann beliebiges SQL mit den Rechten der Applikation ausführen. Eine Regel entspricht damit faktisch Vollzugriff auf die Datenbank.
Whitelist-Regeln sind deshalb weder über die Web-Oberfläche noch über die GraphQL-API lesbar oder änderbar. Sie werden ausschliesslich von Datenbank-Administratoren per SQL-Skript (ChangelogAtom) gepflegt.
Schreibrechte auf Object.UserAclWhitelistRule sind auf Datenbank-Ebene auf Administratoren zu beschränken und wie ein Admin-Zugang zu behandeln.
Jede neue Regel ist vor dem Einspielen zu reviewen: Sie darf nur SELECT-Abfragen enthalten, die objectID (optional right, state) liefern, und den Parameter @0 als Personen-ObjectID des Benutzers verwenden.

Sonderfelder (SpecialFields)

Bestimmte sensible Felder (z.B. Lohndaten, Telefonnummern) können als Sonderfelder definiert werden. Diese werden nur angezeigt, wenn der Benutzer das Recht READSPECIAL auf das Objekt hat. Andernfalls werden sie maskiert (leer gelassen oder mit einem Platzhalter ersetzt).

Objekt-Sperren (Locks)

Unabhängig von den ACL-Rechten können Objekte gesperrt sein. Bei einem Schreib-, Lösch- oder Status-Zugriff prüft das System nach dem ACL-Check, ob das Objekt gesperrt ist.

Sperrtyp	Code	Stärke	Bedeutung
Verrechnet	`ACCOUNTING`	Mittel	Buchhaltungsrelevante Daten gesperrt. Keine Änderungen oder Löschen möglich. Je nach Objekttyp können bestimmte Objekt-Aktionen noch ausgeführt werden.
In Bearbeitung	`EDITING`	Schwach	Wird gesetzt, wenn ein Benutzer ein Objekt geöffnet hat. Nur eine lose Sperre — andere Benutzer können das Objekt trotzdem über die API ändern. Nur das direkte Speichern via Formular ist blockiert. Benutzer können diese Sperre selbst aufheben.
Eingefroren	`FREEZE`	Stark	Das Objekt kann nicht mehr geändert werden. Objekt-Aktionen sind jedoch noch möglich. Typisch bei verbuchten Gutschriften.
Nicht löschen	`NOTDELETE`	Schwach	Nur das Löschen ist nicht erlaubt. Bearbeiten und Objekt-Aktionen sind weiterhin möglich.
Strikt	`STRICT`	Absolut	Vollständige, definitive Sperre. Weder Änderungen noch Objekt-Aktionen sind möglich. Wird immer als Fehler geworfen und kann nicht ignoriert werden (auch nicht von Administratoren).

Sperren und der Workflow

Sperren können automatisch durch Objekt-Aktionen gesetzt oder aufgehoben werden. Im Workflow ist pro Objekt-Aktion konfigurierbar:

LockObjectAtStep = 'STRICT' → Objekt wird nach diesem Schritt strikt gesperrt
LockObjectAtStep = 'FREEZE' → Objekt wird eingefroren
LockObjectAtStep = 'ACCOUNTING' → Buchhaltungssperre wird gesetzt
LockObjectAtStep = 'UNLOCK' → Vorhandene Sperre wird aufgehoben

Ignorierbare Sperren

Benutzer mit dem ignoreLocks-Flag (typischerweise Administratoren) können folgende Sperrtypen übergehen: NOTDELETE, EDITING, ACCOUNTING. Strikt (STRICT) kann von niemandem ignoriert werden.

Empfehlungen

Definieren Sie Zugriffsgruppen nach funktionalen Bereichen (z.B. “Sachbearbeiter Billing”, “Kursadmin”)
Nutzen Sie Objekttyp-ACLs für systemweite Regeln statt individuelle Objekt-ACLs
Explizites Verweigern (-1) sparsam einsetzen — es überschreibt alle erlaubenden Regeln
Vergeben Sie das ADMIN-Profil nur an wenige technische Benutzer — es deaktiviert alle ACL-Prüfungen vollständig