Autorisierung

Die Autorisierung legt fest, was Benutzer nach der Authentifizierung tun dürfen und was nicht. Aptli kombiniert zwei unabhängige Ebenen: freizügige Administratorrechte (was Sie tun dürfen) und restriktive Rollenbeschränkungen (was Sie nicht sehen dürfen). Zusammen ermöglichen sie Administratoren eine detaillierte Kontrolle sowohl über die Funktionen als auch über die Sichtbarkeit von Daten.

Überblick über das Autorisierungsmodell

Das vollständige Sicherheitsmodell von Aptli besteht aus drei Ebenen:

Authentifizierung – Wer Sie sind (im Abschnitt „Authentifizierung“ behandelt)
Administratorrechte – Was Sie ändern DÜRFEN (freizügige Berechtigungen)
Rollenbeschränkungen – Was Sie NICHT sehen können (restriktive Filter)

Alle Beschränkungen werden auf dem Server durchgesetzt – nicht autorisierte Daten werden niemals an Ihren Browser gesendet, unabhängig davon, was Sie über die Benutzeroberfläche, die API oder Exporte versuchen.

Dieses Modell bietet enorme Flexibilität bei gleichzeitiger Wahrung der Sicherheit.

Administratorrechte (Permissiv)

Administratorrechte gewähren die Berechtigung, Informationen zu ändern oder den Status anzupassen. Ohne diese Rechte können Benutzer nur Daten einsehen und ihr eigenes Profil bearbeiten.

Administratorrechte sind ein individuell pro Benutzer konfigurierbares Array (user.admin). Jeder Eintrag ist der Name eines einzelnen Rechts; es gibt keine Gruppierung in Pakete. Rechte werden direkt dem Benutzer gewährt und niemals von einer Rolle vererbt.

Gängige Administratorrechte:

usersUpdate – Profile anderer Benutzer bearbeiten (Name, Titel, Abteilung – NICHT E-Mail/Passwort)
usersLogout – Benutzer zwangsweise abmelden oder sperren
usersDelete – Benutzerkonten löschen
usersCreate – Neue Benutzer anlegen oder gelöschte Konten wiederherstellen
featureCreate, featureUpdate, featureDelete – Kartenelemente (Punkte, Linien, Polygone) bearbeiten
allowCommits – Kartenversionen live freigeben (ansonsten ist „Submit“ eine Anfrage zur Überprüfung durch den Administrator)
jobsCreate, jobsUpdate, jobsDelete – Aufträge (geplante Arbeitseinheiten) verwalten
workOrdersCreate, workOrdersUpdate, workOrdersDelete – Arbeitsaufträge verwalten
reportsCreate, reportsUpdate, reportsDelete – Arbeitsberichte einreichen und verwalten
validationsCreate, validationsUpdate, validationsDelete – Freigabe von Berichten durch die Qualitätssicherung
activitiesCreate, activitiesUpdate, activitiesDelete – Pflege des Aktivitätskatalogs (Arbeitstypen)
projectsCreate, projectsUpdate, projectsDelete – Projekte verwalten
transactionsCreate – Bestandsbewegungen anlegen (das Hauptbuch ist schreibgeschützt – es gibt kein Recht zum Aktualisieren oder Löschen)
canFacilitatePickups – Materialien über einen QR-Code-Abholvorgang in Namen einer Person ausgeben
canTransferStock – Bestände zwischen Standorten verlagern (Standorte sind Transferorte, Personen sind Abholer)

Das Einreichen einer Hilfeanfrage erfordert keine Berechtigung – jeder authentifizierte Benutzer kann eine solche Anfrage stellen. Ob der KI-Assistent verfügbar ist, ist eine bereichsweite Einstellung und kein benutzerspezifisches Recht.

Superrechte (haben Vorrang vor allen anderen):

appSettingSchemasModify – Einstellungen auf Anwendungsebene ändern (Domänen, Timeouts, Sicherheit)
adminRightsModify – Administratorrechte an andere Benutzer vergeben
viewDeleted – Gelöschte Datensätze anzeigen (nahezu universell, teilweise durch Rollenbeschränkungen außer Kraft gesetzt)

Administratorrechte eines Benutzers überprüfen:

Navigieren Sie zu „Admin“ → „Benutzer“
Öffnen Sie das Benutzerprofil
Im Abschnitt „Admin-Rechte“ werden alle gewährten Berechtigungen aufgelistet

Rollenbeschränkungen (restriktiv)

Rollen sind Sammlungen von Beschränkungen, die das Anzeigen und Ändern von Datensätzen mit bestimmten Merkmalen verhindern. Eine Rolle enthält lediglich einen Namen und eine Liste von Einschränkungen – sonst nichts. Rollen haben weder Mitglieder noch einen Eigentümer oder Administratorrechte. Die Zugehörigkeit liegt beim Benutzer: Jeder Benutzer verfügt über eine Liste „roles“, und jede Einschränkung aus diesen Rollen wird auf diesen Benutzer angewendet.

Um eine Rolle zuzuweisen, fügen Sie sie dem Benutzer über dessen Profil hinzu (oder legen Sie sie als Standardrolle für neue Benutzer fest). Um die Mitglieder einer Rolle aufzulisten, suchen Sie nach Benutzern, deren roles diese Rolle enthalten.

Komponenten einer Rolle:

Name – Eine für Menschen lesbare Bezeichnung
Rollenbeschränkungen – Filter auf Feldebene, die bestimmte Daten ausblenden

Rollen regeln ausschließlich die Sichtbarkeit und Beschränkungen. Sie gewähren niemals die Befugnis, etwas zu tun – dafür sind Administratorrechte da.

Struktur der Rollenbeschränkungen

Jede Beschränkung definiert:

Modell (target_model) – Welcher Datentyp (Benutzer, Feature, Rolle usw.)
Feld – Nach welcher Eigenschaft gefiltert werden soll (Eigentümer, Status, Kategorie, benutzerdefinierte Felder)
Vergleich – Wie der Abgleich erfolgen soll. Eine der folgenden Optionen: eq, ne, gt, gte, lt, lte, in, nin
Filterwert - Welcher Wert abgeglichen werden soll (ein einzelner Wert oder ein Array für in/nin)
Berechtigungen – Ein Array der Operationen, die verweigert werden, wenn ein Datensatz den Kriterien entspricht. Jeder Eintrag ist einer der folgenden Werte: read, edit, create, delete. Wird eine Operation hier aufgeführt, wird sie blockiert; wird sie weggelassen, ist sie zulässig.

Die Benutzeroberfläche zur Rollenverwaltung stellt diese als Spalten „Modell“, „Aktion“ und „Pfad“ dar.

Anwendungsbeispiel: Trennung von Auftragnehmern

Szenario: Verhindern, dass Auftragnehmer A die Arbeit von Auftragnehmer B einsehen kann

Einrichtung:

Rolle erstellen: „Auftragnehmer A“
Rollenbeschränkung hinzufügen:
- Modell: feature
- Feld: owner
- Vergleich: eq
- Filterwert: Auftragnehmer B
- Berechtigungen (verweigert): read, edit, create, delete (alle vier gesperrt)
Fügen Sie die Rolle „Auftragnehmer A“ den Benutzern von Auftragnehmer A hinzu (im Profil jedes Benutzers)

Ergebnis:

Mitglieder von Auftragnehmer A können keine Objekte sehen, bei denen Eigentümer = „Auftragnehmer B“ ist
Nicht nur in der Benutzeroberfläche ausgeblendet – die API gibt Daten so zurück, als ob die Datensätze nicht existierten
Kann nicht versehentlich über Screenshots, API-Aufrufe oder Exporte eingesehen werden
Wird vollständig serverseitig durchgesetzt

Weitere Anwendungsfälle

Nach Arbeitsphase: Verhindern, dass Außendienstmitarbeiter QC-Validierungsberichte einsehen können:

Role: "Field Workers"
Restriction:
  Model: validation
  Field: status
  Comparison: ne
  Filter Value: "" (any value)
  Permissions (denied): read

Außendienstmitarbeiter können Validierungen überhaupt nicht sehen.

Nach Asset-Typ: Infrastrukturteams trennen (Masten/Leerrohre vs. aktive Anlagen):

Role: "Civil Team"
Restriction:
  Model: feature
  Field: category
  Comparison: eq
  Filter Value: "Active Equipment"
  Permissions (denied): read, edit, create, delete

Das Bau-Team kann Objekte für aktive Anlagen weder sehen noch ändern.

Nach physisch/logisch: Getrennter Zugriff auf Bürodaten (Kapazitätsbeziehungen vs. Bürostandorte):

Role: "Capacity Analysts"
Restriction:
  Model: feature
  Field: layer
  Comparison: eq
  Filter Value: "Office Locations"
  Permissions (denied): edit, create, delete

Analysten können Standorte anzeigen, diese jedoch nicht ändern (schreibgeschützt – Lesezugriff wird nicht verweigert).

Kombination von Administratorrechten und Rollenbeschränkungen

Standardverhalten: Alle Benutzer können alles sehen, aber nichts ändern (ohne Administratorrechte).

Schreibzugriff mit Einschränkungen hinzufügen:

Beispiel: Außendienstmitarbeiter können ihre eigenen Aufgaben bearbeiten, nicht jedoch die anderer

Admin Rights:
  - reportsCreate: true
  - reportsUpdate: true

Role Restrictions:
  Model: report
  Field: submittedBy
  Comparison: ne
  Filter Value: [current user ID]
  Permissions (denied): edit

Ergebnis:

Mitarbeiter können Berichte erstellen (Administratorrecht gewährt)
Mitarbeiter können NUR ihre eigenen Berichte bearbeiten (die Rollenbeschränkung filtert andere aus)
Sie können die Berichte anderer Mitarbeiter weder einsehen noch ändern

Serverseitige Durchsetzung

So funktioniert es:

Alle Abfragen werden gefiltert, bevor Daten zurückgegeben werden
Rollenbeschränkungen werden auf dem Server angewendet (nicht nur durch Ausblenden in der Benutzeroberfläche)
Benutzer können die Beschränkungen nicht durch direkte API-Aufrufe, Browser-Tools oder Exporte umgehen
Für nicht autorisierte Benutzer existieren die Daten tatsächlich nicht

Sicherheitsauswirkungen:

Ein Screenshot des Bildschirms einer anderen Person hilft nicht weiter (die Daten werden für Sie nicht geladen)
Eingeschränkte Daten können nicht exportiert werden (der Server erzwingt die Filter)
Datensatz-IDs können nicht „erraten“ werden (sie werden vor der ID-Abfrage gefiltert)
Datensätze, die außerhalb Ihrer Berechtigungen liegen, werden als „nicht gefunden“ zurückgegeben, selbst wenn Sie die ID kennen

Rollen verwalten

Rollen erstellen:

Navigieren Sie zu „Admin“ → „Rollen“
Klicken Sie auf „Rolle erstellen“
Geben Sie einen Rollennamen ein
Fügen Sie Rolleneinschränkungen hinzu (es können mehrere sein)
Speichern

Zum Erstellen einer Rolle ist die Administratorberechtigung rolesCreate erforderlich.

Rollen bearbeiten:

Erfordert die Administratorberechtigung rolesUpdate
Einschränkungen können geändert werden
Eine Rolle kann mit rolesDelete gelöscht werden (befreit Mitglieder von diesen Einschränkungen)

Rollen verfügen hier über keine Mitgliederliste, die bearbeitet werden kann – die Mitgliedschaft wird auf dem Benutzer festgelegt, nicht auf der Rolle.

Rollenmitgliedschaft:

Die Mitgliedschaft ist auf dem Benutzer hinterlegt (user.roles); fügen Sie Rollen zum Profil eines Benutzers hinzu oder entfernen Sie sie daraus
Benutzer können mehreren Rollen angehören (Einschränkungen werden kombiniert)
Austritt aus der Organisation: Entfernen Sie alle Rollen vom Benutzer, bevor Sie das Konto löschen

Anpassung der Autorisierung für neue Benutzer

Konfiguration der App-Einstellungen (erfordert appSettingSchemasModify):

Navigieren Sie zu den App-Einstellungen
„Standardrollen“ – die Rollen, die neuen Konten automatisch zugewiesen werden
Speichern

Es gibt keine Einstellung für „Standard-Admin-Rechte“ – neue Benutzer beginnen ohne Admin-Rechte. Erteilen Sie Rechte pro Benutzer über dessen Profil, nachdem das Konto erstellt wurde.

Typische Konfigurationen:

Außendienstmitarbeiter:

Standardrollen: ["Außendienstmitarbeiter"]
Dem Benutzer nach der Erstellung gewährte Administratorrechte: reportsCreate

Bürokoordinator:

Standardrollen: keine
Dem Benutzer nach der Erstellung gewährte Administratorrechte: workOrdersCreate, stockItemsCreate, stockItemsUpdate

Keine automatische Vergabe (manuelle Überprüfung):

Standardrollen: keine
Administratoren weisen Rollen und Rechte nach Überprüfung des Kontos manuell zu.

Aktive Berechtigungen anzeigen

Für einen bestimmten Benutzer:

Zum Benutzerprofil navigieren
Abschnitt „Administratorrechte“ – Was der Benutzer tun DARF
Abschnitt „Rollen“ – Was der Benutzer NICHT sehen darf (aufgrund von Einschränkungen)
Die kombinierte Ansicht zeigt die aktiven Berechtigungen an

Berechtigungen testen:

Als Benutzer anmelden (oder mit Administratorrechten als dieser auftreten)
Normal navigieren
Eingeschränkte Daten werden einfach nicht angezeigt
Aktionen ohne Administratorrechte sind deaktiviert/ausgeblendet

Bewährte Vorgehensweisen

Zunächst restriktiv vorgehen, bei Bedarf Berechtigungen erteilen:

Neue Benutzer erhalten minimale Berechtigungen
Administratorrechte je nach Anforderungen der Rolle hinzufügen
Das Erteilen ist einfacher als das Entziehen (verhindert „Berechtigungsausuferung“)

Rollen für die Datensichtbarkeit nutzen:

Auftragnehmer trennen (um Wettbewerbsausspähung zu verhindern)
Trennen Sie Arbeitsphasen (Qualitätskontrolle von Außendienstmitarbeitern)
Trennen Sie Anlagentypen (Infrastruktur von aktiven Anlagen)

Verwenden Sie Administratorrechte für Funktionen:

Wer kann Aufträge erstellen?
Wer kann den Bestand bearbeiten?
Wer kann Berechtigungen erteilen?

Zweck der Rolle dokumentieren:

Eindeutiger Rollenname („Auftragnehmer A“ ist besser als „Rolle 1“)
Beschreibung erläutert Einschränkungen
Hilft zukünftigen Administratoren, die Absicht zu verstehen

Regelmäßige Berechtigungsprüfungen:

Vierteljährliche Überprüfung der Administratorrechte der Benutzer
Nicht genutzte Rechte entfernen (Benutzer hat die Rolle gewechselt)
Rollenmitgliedschaften prüfen (Benutzer haben die Organisation verlassen)

Zugriffsversuche überwachen:

Fehlgeschlagene Autorisierungsversuche protokollieren
Wiederkehrende Ablehnungen = Benutzer versucht unbefugten Zugriff
Untersuchen und Berechtigungen anpassen oder Benutzer schulen

Prinzip der geringsten Privilegien:

Nur die für die Aufgabenstellung erforderlichen Mindestberechtigungen erteilen
Vorübergehend erweiterte Zugriffsrechte für Projekte (anschließend wieder entfernen)
Superrechte (adminRightsModify) nur für vertrauenswürdige Administratoren