Florian Feuerwehrmanagement
Angebot anfordern
Angebot anfordernZum Kunden-Portal

Benutzer, Rollen & Rechte

Florian unterscheidet zwischen Mitgliederdatensätzen und Benutzerkonten. Rollen, vererbte Rollenrechte und direkte Benutzer-Ausnahmen bestimmen, welche Aktionen ein Konto ausführen darf.

Dokumentationsstand: 19. Oktober 2026, geprüfter Quellstand. Diese Seite beschreibt das vorhandene Berechtigungsmodell. Die Durchsetzung von Feldrechten und Datensatz-Scopes muss für den jeweiligen Zugriffspfad geprüft werden; daraus folgt keine pauschale Zusicherung für sämtliche Ansichten, Exporte oder APIs. Die laufende Sicherheitsprüfung umfasst insbesondere Mitgliederzugriffe und die Vergabe privilegierter Rollen.

Benutzer und Mitglied

Ein Mitglied ist ein Personen-Datensatz der Wehr. Ein Benutzer ist ein Anmeldekonto. Ein Mitglied benötigt nicht automatisch ein Konto; ein Konto kann auch ohne Mitgliedsverknüpfung bestehen. Für Zugriffe auf die eigenen Mitgliedsdaten muss die passende Verknüpfung vorhanden sein.

Konten, Rollen und Berechtigungen verwalten

Die Verwaltung ist in drei Ansichten aufgeteilt:

Ansicht Adresse Erforderliche Rechte
Benutzerverwaltung /admin/benutzer Benutzerverwaltung: Ansehen; je nach Vorgang zusätzlich Erstellen, Bearbeiten, Löschen oder Verwalten
Rollenverwaltung /admin/rollen Rollen: Ansehen; für Änderungen Verwalten
Berechtigungen /admin/berechtigungen Berechtigungen: Ansehen; für Änderungen Verwalten

Legen Sie Konten in der Benutzerverwaltung an und weisen Sie die benötigten Rollen zu. Die Rollenverwaltung enthält Name, Beschreibung, übergeordnete Rolle und Kennzeichnungen für System- und Superuser-Rollen. Systemrollen sind vor strukturellen Änderungen geschützt. Die eigentlichen Modul- und Feldrechte bearbeiten Sie in der Ansicht Berechtigungen, nicht im Dialog zum Rollennamen.

Ein Konto kann mehrere Rollen haben. Zusätzlich werden Rechte übergeordneter Rollen berücksichtigt. Eine Rollenhierarchie darf keinen Kreis bilden. Wählen Sie Superuser-Zuweisungen und Verwaltungsrechte besonders sparsam: Damit können weitreichende Zugriffe und Rechteänderungen verbunden sein.

Aktionen

Die Rechte sind einzelne Aktionen, keine vierstufige Leiter:

Aktion im Modell Bedeutung
View Ansehen
Create Erstellen
Edit Bearbeiten
Delete Löschen
Export Exportieren
Manage Verwalten; umfasst bei der Rechteauswertung auch die fünf anderen Aktionen

Eine fachliche Freigabe von Selbstverwaltungsänderungen ist ein eigener Ablauf. Freigeben ist keine allgemeine Aktion dieses Berechtigungsmodells. Einzelheiten stehen unter Selbstverwaltung.

Geltungsbereich und Feldrechte

Scope Zweck
All Zugriff ohne Datensatzbegrenzung dieses Scopes
Own Eigene Daten, wenn der Zugriff den passenden Eigentümerkontext prüft
Jf Jugendfeuerwehrdaten, wenn der Zugriff den passenden Jugendkontext prüft
Wehr Daten der passenden Wehr, wenn der Zugriff den Wehrkontext prüft

Ein Feldrecht ergänzt Modul und Aktion um einen konkreten Feldnamen. Ohne Feldnamen gilt der Eintrag auf Modulebene. Ein Scope-Eintrag allein filtert keine Datenbankabfrage und ein Feldrecht allein entfernt kein Feld aus einem Export: Die jeweilige Funktion muss den passenden Kontext beziehungsweise Feldnamen bei der Prüfung verwenden. Prüfen Sie sensible Zugriffe mit einem eigenen Testkonto, bevor Sie dieses für den Betrieb freigeben.

Geprüfte Mitgliederzugriffe

Im geprüften Entwicklungsstand berücksichtigen Mitgliederliste, Mitgliederakte und die Mitglieder-Stammdaten-API die verknüpfte Person (Own), den Jugendstatus (Jf) und die aktuelle Wehr. Nicht lesbare Stammdaten werden aus der Ausgabe entfernt beziehungsweise in der Ansicht ausgeblendet. Änderungen prüfen die aktuellen Rechte erneut; bei einem Statuswechsel müssen Feld- und Funktionsänderungen im bisherigen und im neuen Kontext erlaubt sein. Zum Anlegen ist zusätzlich zum Erstellen ein Leserecht für die Mitgliederverwaltung erforderlich.

Zusätzliche Fachbereiche der Mitgliederakte und des Datenblatts benötigen eigene Leserechte, beispielsweise Atemschutz oder Geräte. Fehlen sie, werden die betreffenden Abschnitte einschließlich abgeleiteter Kennzahlen nicht ausgegeben. Das PDF benötigt außerdem vollständige Leserechte für seine Kernstammdaten. Diese Prüfung ist keine Freigabe aller anderen Exporte, Fotoschnittstellen oder Verwaltungsbereiche.

Die Korrekturen befinden sich bis zur dokumentierten Bereitstellung im Entwicklungsstand; der Freigabestand Ihrer Instanz ist maßgeblich.

Historien im Entwicklungsstand

Die Seite Historien und die API für Funktions- und Dienstgradhistorien prüfen die aktuelle Mitgliedsverknüpfung (Own), den Jugendstatus (Jf) und die Wehr des betroffenen Mitglieds. Ein Leserecht für Historien erlaubt das Anlegen noch nicht: Dafür werden zusätzlich Erstellen und die Schreibrechte für die Felder des neuen Eintrags benötigt. Die API prüft beim Bearbeiten die tatsächlich geänderten Felder; beim Löschen müssen die Löschrechte für alle Eintragsfelder vorliegen.

Namen in der Mitgliedsauswahl benötigen zusätzlich die passenden Leserechte für Vorname beziehungsweise Nachname in der Mitgliederverwaltung. Ohne diese Rechte erscheinen neutrale Kennungen; das Historienrecht wird dadurch nicht um ein allgemeines Mitglieder-Leserecht erweitert. Beim Laden der Historien sowie beim Öffnen und Speichern eines neuen Eintrags werden Konto und Berechtigungen erneut geprüft und die Auswahl neu aufgebaut. Eine bereits angezeigte Seite aktualisiert sich bei einer externen Rechteänderung nicht automatisch im selben Augenblick.

Diese Historienkorrektur durchläuft noch die gesonderte Freigabeprüfung. Die Beschreibung ist keine Bestätigung ihrer Bereitstellung auf einer bestehenden Instanz.

Erlauben, Verweigern und Benutzer-Ausnahmen

Jeder Eintrag hat den Effekt Allow (erlauben) oder Deny (verweigern). Für eine passende Prüfung gilt folgende Reihenfolge:

  1. Eine direkt oder über Vererbung zugewiesene Superuser-Rolle erlaubt alle Aktionen. Andere Einträge schränken diese nicht ein.
  2. Gibt es einen passenden Benutzer-Override, wird dieser ausgewertet. Bei mehreren passenden Overrides gewinnt Deny vor Allow.
  3. Sonst werden die passenden Rollenrechte einschließlich geerbter Rechte ausgewertet. Innerhalb dieser Ebene gewinnt Deny vor Allow.
  4. Ohne passenden erlaubenden Eintrag wird der Zugriff verweigert.

Beispiele:

  • Rolle A erlaubt Geräte-Ansehen, Rolle B verweigert dieselbe passende Prüfung: Das Rollen-Ergebnis ist verweigert.
  • Ein passender Benutzer-Override erlaubt Geräte-Ansehen, während ein Rollenrecht es verweigert: Der Override entscheidet erlaubt, sofern keine passende Verweigerung auf der Override-Ebene existiert.
  • Ein Superuser bleibt auch mit einem verweigernden Override ein Superuser. Entfernen Sie die Superuser-Zuweisung, wenn das Konto eingeschränkt werden soll.

Die Ansicht Berechtigungen zeigt die Rollen-Matrix, Feldrechte und Benutzer-Overrides. Kontrollieren Sie bei unerwarteten Ergebnissen zuerst die Superuser-Kennzeichnung, dann Overrides, geerbte Rollen und die angefragte Aktion samt Scope und Feld. Änderungen an Berechtigungen werden über die vorgesehenen Verwaltungsfunktionen im Audit protokolliert; daraus folgt keine vollständige Historie aller gelesenen Felder.

Sicherheitsrichtlinie

Die administrative Seite Sicherheitsrichtlinie erreichen Sie unter /einstellungen/sicherheit. Sie benötigt System: Verwalten (System.Manage). Die persönliche Kontosicherheit mit TOTP ist ein eigener Bereich.

Bereich Geltungsbereich und Wirkung
Sitzungsdauer Gilt für die gesamte Florian-Instanz. Die gespeicherte Änderung wird erst nach einem Neustart von Florian für die Sitzungsoptionen übernommen.
Login-Sperre Fehlversuchsgrenze und Sperrdauer gelten für die aktuelle Wehr.
Gültigkeit von Passwort-Links Legt die Gültigkeit beim Ausstellen neuer Zurücksetzen-Links der aktuellen Wehr fest.
Passwort-Anforderungen Mindestlänge und Anforderungen an Großbuchstaben, Kleinbuchstaben, Ziffern und Sonderzeichen gelten für die aktuelle Wehr bei der Vergabe neuer Passwörter. Das Speichern schreibt bestehende Passwörter nicht um.

Jeder Bereich hat eine eigene Speicheraktion. Die Seite zeigt die zulässigen Eingabegrenzen und meldet ungültige Werte am jeweiligen Feld. Die vier Bereiche werden getrennt gespeichert; es gibt keine gemeinsame Speicherung aller Karten.

Im geprüften Entwicklungsstand prüfen die Speicheraktionen das aktuell angemeldete, aktive Konto und dessen gegenwärtiges Recht System: Verwalten erneut. Wurde dieses Recht inzwischen entzogen oder ist das Konto nicht mehr gültig, bleiben die gespeicherten Werte unverändert. Die Seite zeigt eine Fehlermeldung; der eingegebene Entwurf bleibt erhalten. Das beschreibt den geprüften Quellstand, keine Bereitstellung auf Ihrer Instanz. Beachten Sie den Neustarthinweis bei der Sitzungsdauer.

Anmeldung (Authentifizierung)

Florian besitzt eine lokale Kontoanmeldung unter /login. Benutzer melden sich mit Anmeldename und Passwort an. Die administrative Sicherheitsrichtlinie unter /einstellungen/sicherheit regelt Sitzungsdauer, Login-Sperre, Reset-Link-Gültigkeit und Passwortanforderungen. Die persönliche Zwei-Faktor-Einrichtung ist unter /konto/sicherheit erreichbar.

Lokale Kontoanmeldung

Die reguläre Nutzung wird in diesem Handbuch mit aktiver Kontoanmeldung beschrieben. Die Rechte eines Benutzers ergeben sich aus seinen Florian-Rollen und individuellen Berechtigungen.

Zentrale Anmeldung über OIDC: technischer Konfigurationsstand

Der Quellstand enthält eine optionale OIDC-Registrierung über Auth:Oidc:Enabled und den Konfigurationsabschnitt Auth:Oidc. Dieses Kapitel beschreibt dafür keinen freigegebenen SSO-Einrichtungsablauf. Eine grafische OIDC-Einrichtung, eine angezeigte Rückleit-Adresse, eine verschlüsselte Ablage des Client-Secrets und eine automatische Zuordnung externer Gruppen zu Florian-Rollen sind hier nicht als geprüfte Funktionen zugesichert.

Vor einem Einsatz muss die konkrete Integration einschließlich Start und Rückleitung der Anmeldung, Benutzerzuordnung, Berechtigungen und sicherer Bereitstellung der Zugangsdaten gesondert geprüft werden. Ein externer Gruppenname allein begründet kein Florian-Berechtigungsrecht.

Technischer Notfallzugang

Der technische Settingkey auth.login.enabled wird für einen Break-glass-Modus ausgewertet. Dieser verwendet im Blazor-Authentifizierungszustand den vorhandenen Notfalladministrator und dessen Berechtigungen. Er hebt die Benutzer- und Berechtigungsprüfung nicht allgemein auf.

Daraus folgt keine Zusicherung eines uneingeschränkten Zugriffs auf sämtliche Oberflächen und APIs oder zur Verfügbarkeit von Selbstverwaltung und TOTP in diesem Sondermodus. Dieses Handbuch enthält keine Anleitung zum Abschalten der Anmeldung als regulären Betriebsmodus.

2-Faktor-Authentifizierung (TOTP)

Zusätzlich zum Passwort können Sie die 2-Faktor-Authentifizierung per TOTP aktivieren (zeitbasierte Einmalcodes, wie sie Authenticator-Apps erzeugen). Nach dem Passwort gibt der Benutzer dann einen sechsstelligen Code aus seiner App ein.

So aktiviert ein Benutzer 2FA für sein Konto:

  1. Öffnen Sie die Kontoseite Sicherheit unter /konto/sicherheit.
  2. Scannen Sie den angezeigten QR-Code mit einer Authenticator-App (z. B. einer TOTP-fähigen App Ihrer Wahl).
  3. Bestätigen Sie mit dem erzeugten Code, um die Kopplung abzuschließen.
  4. Bewahren Sie die angezeigten Wiederherstellungscodes sicher auf — mit ihnen kommen Sie wieder hinein, falls das zweite Gerät verloren geht.

Achtung: Aktivieren Sie 2FA unbedingt für Konten mit weitreichenden Rechten (Administrator, Kommandant, Kassier). Geht das zweite Gerät verloren und sind keine Wiederherstellungscodes vorhanden, muss ein anderer Administrator die 2FA für das betroffene Konto zurücksetzen.

Siehe auch