Thore CimbalandClaude Opus 4.8
f248c4f03c
#0043: the case-insensitive username policy is live and verified end to end — present in the ConfigMap, mounted in the worker, applied by authentik on its own, and bound to the prompt stage. It reads only prompt_data, since the stage runs anonymously and that is exactly what the previous system policies died on. #0044 turns out to be largely solved already, which the issue could not know: the ESS chart hangs config and secret hashes on the pod template as labels, so MAS and the other chart components do roll out on change, and coturn has its own annotation bump driven by the rotation job. What remains are three services whose secrets change rarely and deliberately — recommending against adding a controller for that. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.2 KiB
type, id, status, created, milestone, priority, area, related
| type | id | status | created | milestone | priority | area | related | |
|---|---|---|---|---|---|---|---|---|
| issue | 0043 | done | 2026-08-11 | M5 | medium | security |
|
Invitation-Flow: case-insensitive Eindeutigkeitsprüfung im Prompt-Stage
Offener Rest aus ADR-0011; GitLab-seitig als gitops#61 verfolgt.
Problem / Motivation
Die Kontoübernahme über kollidierende Localparts ist geschlossen — MAS steht auf
on_conflict: fail (ADR-0011, live nach MAS-Neustart). Das ist die harte
Sicherheitsgrenze, aber sie greift erst beim Login: Ein Nutzer, der bei der
Registrierung einen bereits vergebenen Namen (oder eine Schreibweise-Variante wie
boje neben Boje) wählt, bekommt kein Feedback im Flow, sondern läuft später in
einen fehlgeschlagenen Login. Authentiks eigene Eindeutigkeit ist case-sensitive
und deckt Kollisionen mit bestehenden Matrix-Konten nicht ab.
Acceptance
- Der
matrix-invitation-Flow prüft im Prompt-Stage den gewünschten Benutzernamen case-insensitive gegen bestehende Konten und weist eine Kollision schon bei der Registrierung sichtbar ab. - Als Blueprint reproduzierbar (
apps/authentik/authentik-blueprints.yaml), nicht nur als Klick im Admin-UI. - Gegenprobe: Registrierung mit einem existierenden Namen in abweichender Schreibweise scheitert im Flow, nicht erst beim Login.
Notes
Rein defensive Ergänzung / UX — der Übernahme-Vektor selbst ist bereits zu.
Deshalb M5 (Härtung, nicht Reparatur) und priority: medium.
Erledigt 2026-08-15
Expression-Policy matrix-username-eindeutig-ci im Blueprint ergänzt und an die
Prompt-Stage des matrix-invitation-Flows gebunden (gitops afc4ad3). Sie prüft
prompt_data.username per username__iexact gegen bestehende Konten und weist eine
Kollision mit sichtbarer Meldung ab — dort, wo der Fehler entsteht, statt später beim Login.
⚠️ Bewusst ohne Zugriff auf request.user. Die Stage läuft im anonymen
Enrollment-Kontext; genau daran waren die früher hier hängenden 16 System-Policies gescheitert
('AnonymousUser' object has no attribute 'group_attributes'). Gelesen wird ausschließlich
prompt_data. Der Kommentar im Blueprint hält das fest, damit die Falle nicht wiederkehrt.
Verifiziert am laufenden System (nicht nur „Blueprint gepusht"):
| Prüfung | Ergebnis |
|---|---|
| ConfigMap im Cluster | Policy enthalten |
| Datei im Worker-Pod gemountet | Policy enthalten |
| Blueprint von Authentik angewandt | Policy matrix-username-eindeutig-ci in der DB vorhanden |
| Bindung an die Stage | matrix-invitation-prompt → matrix-username-eindeutig-ci |
Authentik hat den Blueprint selbstständig übernommen — kein Neustart nötig.
Grenze, die bleibt: Geprüft wird gegen Authentik-Konten. Ein reines Matrix-Konto ohne
Authentik-Entsprechung fällt weiterhin erst bei MAS auf (on_conflict: fail, ADR-0011) — das
bleibt die harte Sicherheitsgrenze, diese Policy ist die freundliche davor. Eine Prüfung gegen
Synapse aus einer Policy heraus hieße Netzwerkaufruf plus Credentials im Ausdruck; das wäre
schlechter als der bestehende Zweiklang.