Security, interne Authentifizierung, Authorisierung

Die Daten werden entlang der Kontexte strukturiert und auch entsprechend geschützt. Anwender*innen weisen sich sich mit einem beim Start der Session generierten JWT aus, welches nach externer Authentifizierung durch das Volt Portal erstellt und mit gewissen Eigenschaften aufgeladen wird.

Neben einigen personenbezogenen Daten enthält das Token insbesondere die folgenden Informationen:

Kontext
Die Session ist immer auf genau einen Kontext bezogen. Dieser Kontext kann innerhalb der Session gewechselt werden, dafür muss aber das bestehende Token gegen ein neues ausgetauscht werden. Neben der ID des aktuellen Kontexts enthält das Token Informationen dazu, welche Kontexte diesem nachgeordnet sind (Benutzerunabhängig, vgl. Hierarchie der Kontexte) und auf welche Kontexte der*die Anwender*in neben dem aktuell gewählten (Hierarchieunabhängig) Zugriff hat.
Rechte
Aus unterschiedlichen internen Quellen bezieht ein*e Anwender*in die ihm*ihr zugeordneten Rechte. Diese sind dabei jeweils auf einen Kontext beschränkt. Die Liste von Rechten wird dabei vorallem auf Grundlage der im jeweiligen Kontext bzw. dessen Verband zugeordneten Rollen ermittelt. Die meisten im System durchgeführten Aktionen sind dabei davon abhängig ob neben dem aktuellen Kontext auch die notwendigen Rechte zugeteilt sind.
Es kann Anwendungsfälle geben, für die kein im JWT abgebildetes Recht, sondern eine explizite Zuordnung zum jeweiligen Objekt entscheidend oder notwendig ist, um die Aktion durchzuführen. Dabei handelt es sich um fachlich geschlossene Rechte, die - entgegen der via Rollen und dem JWT zugeordneten Rechte - nicht in mehreren Fachbereichen entscheidend sind. Beispielhaft hier ist das Bearbeiten von einzelnen Versammlungen; die hierfür notwendigen Rechte können sich aus einer für die spezielle Versammlung zugewiesenen Rolle ergeben und haben außerhalb der Versammlung keine Wirkung.
Flags
Weiterhin gibt es einige Flags, die entscheidend für das Erlauben oder Verbieten von Aktionen sind. Dafür wird am JWT gespeichert, ob:
- der jeweilige Anwender gesperrt ist,
- es sich um eine maschinelle oder menschliche Anwender*in handelt,
- der*die Anwender*in Systemadministrator*in ist,
- den Nutzungsbedingungen zugestimmt wurde und
- die Authentifizierung mittels eines zweiten Faktors bestätigt bzw. die gewählte vorgelegte Authentisierung so stark war, dass kein zweiter Faktor verlangt wird.

Die Authentisierung kann über Google OAuth 2.0 oder über ein im Volt Portal generiertes TOTP, das an die angeforderte Mail versendet wird, erfolgen. Dabei wird ersteres als starke Authentifizierung gewertet, die Anmeldung über TOTP nicht. Da es aktuell keine Implementierung für einen zweiten Faktor gibt, stehen damit nur auf die persönlichen Daten beschränkte Funktionen zur Verfügung.

Das Frontend filtert angezeigte Funktionen, Daten und Navigationsmöglichkeiten eigenständig entsprechend der im JWT geladenen Rechte. Zusätzlich und als hauptsächliche Security-Funktionalität prüft das Backend die entsprechenden API-Calls auf Zulässigkeit (Eingangsprüfung) sowie fachliche Freigaben (fachliche Prüfung).