UC08 – Benutzerverwaltung
Stand: 01.08.2026 14:55
Branch: docs/einheitliche-kopfbereiche
Status: Spezifikation
| Datum, Uhrzeit |
Version |
Änderung |
Autor |
| 01.08.2026 14:55 |
0.1 |
Kopfbereich vereinheitlicht |
David Mittig |
Spezifikationsdatei – Leitdokument für Entwicklung, Testing und Abnahme
Review: offen
Status-Übersicht
| Schritt |
Bezeichnung |
Status |
Kommentar |
| 1 |
Steckbrief |
✅ Erstellt |
fachlicher Rahmen für UC08 definiert |
| 2 |
Scope & Abgrenzung |
✅ Erstellt |
Benutzerverwaltung von Kundenportal und Superadmin abgegrenzt |
| 3 |
Rollenmodell |
🟡 In Bearbeitung |
V1-Rollen vorbereitet, Detailrechte noch zu prüfen |
| 4 |
Benutzer-Lifecycle |
🟡 In Bearbeitung |
Einladung, Aktivierung, Deaktivierung vorbereitet |
| 5 |
Einladungsmodell |
🟡 In Bearbeitung |
Token-, Ablauf- und Wiederholungsregeln offen |
| 6 |
Sicherheits- und Auditregeln |
🟡 In Bearbeitung |
Grundregeln definiert, Security-Review erforderlich |
| 7 |
Datenmodell-Vorbereitung |
🟡 In Bearbeitung |
Entitäten vorbereitet, Schema noch nicht final |
| 8 |
Screen-Flow BU-01 bis BU-08 |
⬜ Offen |
Screen-Dokumente noch nicht erstellt |
Legende: ✅ Erstellt | 🟡 In Bearbeitung | 🔴 Blockiert | ⬜ Offen
1. Steckbrief
| Feld |
Inhalt |
| UC-ID |
UC08 |
| Name |
Benutzerverwaltung |
| Version |
V1 MVP |
| Zielgruppe |
Tauchschule / Tenant |
| Primärakteur |
tenant_admin |
| Sekundärakteur |
mitarbeiter |
| Betroffener Akteur |
kunde |
| Systemakteur |
Authentifizierungsdienst / E-Mail-Service |
| Reifegrad V1 |
fachliche Spezifikation gestartet |
| Priorität |
Hoch |
1.1 Ziel
UC08 ermöglicht einem Tenant, Benutzer innerhalb der eigenen Tauchschule zu verwalten.
Der Tenant-Admin kann Benutzer einladen, Rollen zuweisen, Benutzer aktivieren, deaktivieren, reaktivieren und relevante Sicherheits- sowie Auditinformationen prüfen.
UC08 bildet damit die zentrale Grundlage für rollenbasierte Bedienung in allen weiteren Use Cases.
2. Scope & Abgrenzung
2.1 Gehört zu UC08 V1
| Bereich |
Enthalten |
| Benutzerübersicht je Tenant |
Ja |
| Mitarbeiter einladen |
Ja |
| weiteren Tenant-Admin einladen |
Ja |
| Benutzerrolle ändern |
Ja |
| Benutzer deaktivieren |
Ja |
| Benutzer reaktivieren |
Ja |
| offene Einladungen anzeigen |
Ja |
| Einladung erneut senden |
Ja |
| Einladung widerrufen |
Ja |
| Sicherheitsstatus anzeigen |
Ja, grundlegend |
| Login-Historie anzeigen |
vorbereitet |
| Audit-Historie anzeigen |
Ja, mindestens für Rollen- und Statusänderungen |
| Schutz vor letzter Admin-Entfernung |
Ja |
| Tenant-Isolation |
Ja |
2.2 Gehört nicht zu UC08 V1
| Bereich |
Hinweis |
| globale Superadmin-Verwaltung |
eigener Bereich / UC-SA |
| Self-Service-Registrierung eines Tenants |
UC00+ |
| Kundenportal-Einladung im Detail |
primär UC06, Statussicht in UC08 möglich |
| vollständiges IAM-System |
nicht V1 |
| komplexe Berechtigungsmatrix je Einzelfunktion |
später erweiterbar |
| Single Sign-on / SAML / OIDC Enterprise |
später prüfen |
| verpflichtende 2FA |
vorbereitet, aber nicht zwingend V1 |
| Passwort-Reset-Logik im Detail |
Authentifizierungsdienst / eigenes Security-Konzept |
3. Rollenmodell V1
3.1 Rollen
| Rolle |
Bedeutung |
superadmin |
Plattformbetreiber, tenantübergreifend, nicht durch Tenant verwaltbar |
tenant_admin |
Administrator der eigenen Tauchschule |
mitarbeiter |
operativer Benutzer der Tauchschule |
kunde |
Kunde / Taucher mit eingeschränktem Portalzugriff |
3.2 Grundregel
Ein Tenant darf nur Benutzer des eigenen Tenants sehen und verwalten.
3.3 Rollenrechte V1
| Aktion |
tenant_admin |
mitarbeiter |
kunde |
| Benutzerübersicht sehen |
Ja |
Nein / eingeschränkt offen |
Nein |
| Mitarbeiter einladen |
Ja |
Nein |
Nein |
| Tenant-Admin einladen |
Ja |
Nein |
Nein |
| Rolle ändern |
Ja |
Nein |
Nein |
| Benutzer deaktivieren |
Ja |
Nein |
Nein |
| Benutzer reaktivieren |
Ja |
Nein |
Nein |
| offene Einladungen sehen |
Ja |
Nein |
Nein |
| eigene Profildaten sehen |
Ja |
Ja |
Ja |
| eigene Sicherheitshinweise sehen |
Ja |
Ja |
Ja |
4. Benutzer-Lifecycle
4.1 Statusmodell
| Status |
Bedeutung |
invited |
Einladung wurde erstellt, aber noch nicht angenommen |
active |
Benutzer ist aktiv und kann sich anmelden |
inactive |
Benutzer ist deaktiviert und kann sich nicht anmelden |
invitation_expired |
Einladung ist abgelaufen |
invitation_revoked |
Einladung wurde widerrufen |
locked |
Benutzer ist sicherheitsbedingt gesperrt, spätere Erweiterung |
4.2 Ablauf: Benutzer einladen
1. tenant_admin öffnet Benutzerverwaltung
2. tenant_admin wählt „Benutzer einladen“
3. E-Mail-Adresse, Name und Rolle werden erfasst
4. System prüft Tenant, Dubletten und Rollenregeln
5. Einladungstoken wird erzeugt
6. Einladung wird per E-Mail versendet
7. Benutzer nimmt Einladung an
8. Benutzerstatus wechselt auf active
4.3 Ablauf: Benutzer deaktivieren
1. tenant_admin öffnet Benutzerprofil
2. tenant_admin wählt „Benutzer deaktivieren“
3. System prüft, ob dadurch der letzte aktive tenant_admin entfernt würde
4. Pflichtgrund wird erfasst
5. Benutzerstatus wechselt auf inactive
6. Änderung wird auditierbar protokolliert
5. Einladungsmodell
5.1 Grundidee
Neue Benutzer werden nicht direkt vollständig aktiviert, sondern per Einladung angelegt.
| Element |
Beschreibung |
| Einladung |
Datensatz mit E-Mail, Rolle, Tenant und Ablaufdatum |
| Token |
sicherer, nicht erratbarer Einladungslink |
| Ablaufdatum |
verhindert unbegrenzt gültige Links |
| Annahme |
Benutzer setzt Passwort / aktiviert Konto |
| Widerruf |
tenant_admin kann offene Einladung zurückziehen |
5.2 Vorläufige Regeln
| ID |
Regel |
| UC08-INV-R01 |
Einladungstoken dürfen nicht im Klartext gespeichert werden |
| UC08-INV-R02 |
Einladungstoken müssen ein Ablaufdatum haben |
| UC08-INV-R03 |
Eine E-Mail-Adresse darf je Tenant nicht mehrfach aktiv eingeladen werden |
| UC08-INV-R04 |
Einladung kann erneut versendet werden |
| UC08-INV-R05 |
Widerrufene Einladungen dürfen nicht mehr angenommen werden |
| UC08-INV-R06 |
Annahme einer Einladung muss auditierbar sein |
5.3 Offene Entscheidung
| ID |
Frage |
Vorschlag |
| UC08-INV-O01 |
Wie lange ist ein Einladungstoken gültig? |
7 Tage |
| UC08-INV-O02 |
Darf Einladung erneut versendet werden und verlängert dies das Ablaufdatum? |
Ja, mit neuem Token |
| UC08-INV-O03 |
Muss Einladung für tenant_admin zusätzlich bestätigt werden? |
offen |
6. Sicherheitsregeln
| ID |
Regel |
| UC08-SEC-R01 |
Tenant-Isolation ist zwingend |
| UC08-SEC-R02 |
Ein Tenant-Admin darf keine Benutzer anderer Tenants sehen |
| UC08-SEC-R03 |
Es muss immer mindestens ein aktiver tenant_admin je Tenant verbleiben |
| UC08-SEC-R04 |
Ein letzter aktiver tenant_admin darf sich nicht selbst deaktivieren |
| UC08-SEC-R05 |
Rollenänderungen müssen auditierbar sein |
| UC08-SEC-R06 |
Deaktivierte Benutzer dürfen sich nicht anmelden |
| UC08-SEC-R07 |
Einladungslinks dürfen nicht erratbar sein |
| UC08-SEC-R08 |
Einladungslinks dürfen nach Ablauf oder Widerruf nicht mehr funktionieren |
| UC08-SEC-R09 |
Sensible Aktionen benötigen klare Bestätigung im UI |
| UC08-SEC-R10 |
Optionales 2FA-Feld kann vorbereitet werden, ist aber nicht zwingend V1 |
7. Auditregeln
7.1 Auditpflichtige Aktionen
| Aktion |
Audit erforderlich |
| Benutzer eingeladen |
Ja |
| Einladung erneut versendet |
Ja |
| Einladung widerrufen |
Ja |
| Benutzer aktiviert |
Ja |
| Rolle geändert |
Ja |
| Benutzer deaktiviert |
Ja |
| Benutzer reaktiviert |
Ja |
| letzter Admin-Schutz ausgelöst |
Ja / Systemereignis |
| Login fehlgeschlagen |
optional / Security-Log |
| Login erfolgreich |
optional / Security-Log |
7.2 Auditdaten
| Feld |
Beschreibung |
| Aktion |
z. B. user_invited, role_changed, user_deactivated |
| Zielbenutzer |
betroffener Benutzer |
| ausführender Benutzer |
handelnder Benutzer |
| Tenant |
betroffener Tenant |
| Zeitpunkt |
Datum / Zeit |
| alter Wert |
z. B. alte Rolle |
| neuer Wert |
z. B. neue Rolle |
| Grund |
Pflicht bei Deaktivierung / kritischer Änderung |
8. Datenmodell-Vorbereitung
8.1 Mögliche Entitäten
| Entität |
Zweck |
users |
globale Benutzeridentität |
tenant_users |
Zuordnung Benutzer zu Tenant inkl. Rolle und Status |
user_invitations |
offene und historische Einladungen |
user_security_events |
Login- und Sicherheitsereignisse |
audit_log |
revisionsrelevante Änderungen |
8.2 Mögliche Felder tenant_users
| Feld |
Beschreibung |
id |
UUID |
tenant_id |
Tenant-Bezug |
user_id |
Benutzer-Bezug |
role |
Rolle im Tenant |
status |
active, inactive, invited usw. |
created_at |
Erstellzeitpunkt |
created_by |
einladender / anlegender Benutzer |
deactivated_at |
Zeitpunkt der Deaktivierung |
deactivated_by |
Benutzer, der deaktiviert hat |
deactivation_reason |
Pflichtgrund |
8.3 Mögliche Felder user_invitations
| Feld |
Beschreibung |
id |
UUID |
tenant_id |
Tenant-Bezug |
email |
eingeladene E-Mail-Adresse |
role |
vorgesehene Rolle |
token_hash |
Hash des Einladungstokens |
expires_at |
Ablaufdatum |
accepted_at |
Annahmezeitpunkt |
revoked_at |
Widerrufszeitpunkt |
created_by |
einladender Benutzer |
status |
pending, accepted, expired, revoked |
9. Screen-Flow BU-01 bis BU-08
| Screen |
Bezeichnung |
Zweck |
| BU-01 |
Benutzerübersicht |
alle Benutzer und Einladungen eines Tenants anzeigen |
| BU-02 |
Benutzer einladen |
neuen Mitarbeiter oder Tenant-Admin einladen |
| BU-03 |
Benutzerprofil verwalten |
Name, E-Mail, Rolle, Status und Kontext anzeigen |
| BU-04 |
Rollen & Rechte ändern |
Rolle ändern und Auswirkungen prüfen |
| BU-05 |
Einladung verwalten |
offene, abgelaufene oder widerrufene Einladungen verwalten |
| BU-06 |
Benutzer deaktivieren / reaktivieren |
kontrollierter Statuswechsel mit Pflichtgrund |
| BU-07 |
Sicherheits- & Login-Historie |
Login- und Sicherheitsereignisse prüfen |
| BU-08 |
Audit-Historie Benutzerverwaltung |
Rollen-, Status- und Einladungsänderungen nachvollziehen |
9.1 Empfohlener V1-Kern
| Screen |
Bewertung |
| BU-01 |
zwingend V1 |
| BU-02 |
zwingend V1 |
| BU-03 |
zwingend V1 |
| BU-04 |
zwingend V1 |
| BU-05 |
zwingend V1 |
| BU-06 |
zwingend V1 |
| BU-07 |
V1-light / sinnvoll |
| BU-08 |
V1-light / sinnvoll |
10. Akzeptanzkriterien UC08 V1
| ID |
Kriterium |
| UC08-AC01 |
tenant_admin kann Benutzer des eigenen Tenants sehen |
| UC08-AC02 |
tenant_admin kann Mitarbeiter einladen |
| UC08-AC03 |
tenant_admin kann weitere tenant_admins einladen |
| UC08-AC04 |
System verhindert Zugriff auf fremde Tenants |
| UC08-AC05 |
System verhindert Deaktivierung des letzten aktiven tenant_admins |
| UC08-AC06 |
Rollenänderungen werden auditierbar protokolliert |
| UC08-AC07 |
Benutzerdeaktivierung benötigt Pflichtgrund |
| UC08-AC08 |
Einladungstoken sind zeitlich begrenzt und nicht im Klartext gespeichert |
| UC08-AC09 |
Offene Einladungen können erneut versendet oder widerrufen werden |
| UC08-AC10 |
Deaktivierte Benutzer können sich nicht anmelden |
11. Offene Fragen / Restentscheidungen
| ID |
Frage |
Vorschlag / Status |
| UC08-O01 |
Wie lange ist ein Einladungstoken gültig? |
Vorschlag: 7 Tage |
| UC08-O02 |
Darf ein Mitarbeiter andere Benutzer sehen? |
Vorschlag: Nein oder nur stark eingeschränkt |
| UC08-O03 |
Darf ein Tenant mehrere tenant_admins haben? |
Vorschlag: Ja |
| UC08-O04 |
Muss 2FA in V1 umgesetzt werden? |
Vorschlag: vorbereiten, nicht erzwingen |
| UC08-O05 |
Wird Kundenportal-Zugang in UC08 vollständig verwaltet? |
Vorschlag: Statussicht ja, Detailprozess UC06 |
| UC08-O06 |
Wie wird Passwort-Reset fachlich abgegrenzt? |
Authentifizierungsdienst / Security-Konzept |
| UC08-O07 |
Darf eine Einladung an eine bereits plattformweit bekannte E-Mail-Adresse gehen? |
Ja, aber Tenant-Zuordnung sauber prüfen |
| UC08-O08 |
Müssen Rollenänderungen aktiv vom betroffenen Benutzer bestätigt werden? |
Nein für V1 |
12. Nächster Schritt
Als nächstes sollten die Screen-Vorgaben unter folgendem Ordner angelegt werden:
docs/developer/uc08/screens/
Start mit:
BU-01 – Benutzerübersicht
Je Screen werden analog zu UC02 und UC03 drei Dateien erstellt: