#013 Personen und Self-Service #13

New Issue

2026-10-12T15:12:39Z

florian.wilde commented

2026-10-12 15:12:39 +00:00

Ziel

Personen verwalten; jeder angemeldete Benutzer kann eigene Public Keys hinterlegen, wirksam erst nach Zuweisung.

Aufgaben

Personenliste/-detail
Seite „Meine Schlüssel“

Akzeptanzkriterien

Leser kann nur eigene Keys hinterlegen, nicht zuweisen

Abhängigkeiten

#012

Notizen / Entscheidungen

Personen pflegt, wer Schlüssel verwaltet (Recht schluesselVerwalten, Admin und Operator) –
ein eigenes Recht wäre nur ein Alias. Lesen dürfen alle Rollen.
Archivieren statt Löschen: die Schlüssel bleiben der Person zugeordnet (wer hatte bis wann
welchen Key?), die Kontoverknüpfung entfällt, damit der Self-Service nicht bei einer
archivierten Person landet. Die Notiz steht nicht im Protokoll, nur dass sie sich änderte.
Self-Service /meine-schluessel (Recht eigeneSchluesselHinterlegen, alle Rollen,
Navigation „Meine Schlüssel“): beim ersten Aufruf wird die eigene Person angelegt oder
verknüpft – per benutzerId, sonst per E-Mail, aber nur bei vom Anbieter bestätigter
Adresse und genau einer freien, nicht archivierten Person. Dafür neue Spalte
Benutzer.emailBestaetigt (Migration 20261012103000_benutzer_email_bestaetigt), gesetzt bei
jeder OIDC-Anmeldung. Ohne sie könnte jemand mit selbst gewählter Adresse die Keys einer fremden
Person sehen.
Hinterlegte Keys: Kategorie PERSON, selbstHinterlegt = true, Protokoll
schluessel.selbst_hinterlegt. Hinweis in der Oberfläche: „Wirksam erst, wenn ein Operator
oder Admin den Schlüssel einem Host zuweist.“
Entfernen nur eigene, selbst hinterlegte Keys ohne jede Verwendung (auch keine entfernte –
der Verlauf am Key bleibt). Das Löschen ist bedingt (deleteMany mit „keine Verwendungen“),
damit eine gleichzeitige Zuweisung nicht per Cascade verschwindet. Fremde IDs gelten als „nicht
vorhanden“. Tests: tests/personen.test.ts.
Die Services nehmen den angemeldeten Benutzer entgegen und leiten die Person selbst ab; die
Actions reichen keine personId von außen durch (struktureller Test).

Quelle: docs/issues/013-personen-selbstauskunft.md – dort wird dieses Issue gepflegt.

## Ziel Personen verwalten; jeder angemeldete Benutzer kann eigene Public Keys hinterlegen, wirksam erst nach Zuweisung. ## Aufgaben - [x] Personenliste/-detail - [x] Seite „Meine Schlüssel“ ## Akzeptanzkriterien - [x] Leser kann nur eigene Keys hinterlegen, nicht zuweisen ## Abhängigkeiten #012 ## Notizen / Entscheidungen - **Personen pflegt, wer Schlüssel verwaltet** (Recht `schluesselVerwalten`, Admin und Operator) – ein eigenes Recht wäre nur ein Alias. Lesen dürfen alle Rollen. - **Archivieren statt Löschen:** die Schlüssel bleiben der Person zugeordnet (wer hatte bis wann welchen Key?), die Kontoverknüpfung entfällt, damit der Self-Service nicht bei einer archivierten Person landet. Die Notiz steht nicht im Protokoll, nur dass sie sich änderte. - **Self-Service `/meine-schluessel`** (Recht `eigeneSchluesselHinterlegen`, alle Rollen, Navigation „Meine Schlüssel“): beim ersten Aufruf wird die eigene Person angelegt oder verknüpft – per `benutzerId`, sonst per E-Mail, aber **nur bei vom Anbieter bestätigter Adresse** und genau einer freien, nicht archivierten Person. Dafür neue Spalte `Benutzer.emailBestaetigt` (Migration `20261012103000_benutzer_email_bestaetigt`), gesetzt bei jeder OIDC-Anmeldung. Ohne sie könnte jemand mit selbst gewählter Adresse die Keys einer fremden Person sehen. - Hinterlegte Keys: Kategorie `PERSON`, `selbstHinterlegt = true`, Protokoll `schluessel.selbst_hinterlegt`. Hinweis in der Oberfläche: „Wirksam erst, wenn ein Operator oder Admin den Schlüssel einem Host zuweist.“ - **Entfernen** nur eigene, selbst hinterlegte Keys ohne jede Verwendung (auch keine entfernte – der Verlauf am Key bleibt). Das Löschen ist bedingt (`deleteMany` mit „keine Verwendungen“), damit eine gleichzeitige Zuweisung nicht per Cascade verschwindet. Fremde IDs gelten als „nicht vorhanden“. Tests: `tests/personen.test.ts`. - Die Services nehmen den angemeldeten Benutzer entgegen und leiten die Person selbst ab; die Actions reichen keine `personId` von außen durch (struktureller Test). --- Quelle: `docs/issues/013-personen-selbstauskunft.md` – dort wird dieses Issue gepflegt.

florian.wilde added this to the v0.2.0 milestone 2026-10-12 15:12:39 +00:00

florian.wilde added the ui backend labels 2026-10-12 15:12:39 +00:00

florian.wilde closed this issue

2026-10-12 15:12:39 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/sshkeyvault#13