Files

T

Thore CimbalandClaude Opus 4.8 f248c4f03c docs(issues): close #0043 , record the coverage map for #0044

#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>

2026-08-15 12:00:00 +00:00

3.2 KiB

Raw Permalink Blame History

type, id, status, created, milestone, priority, area, related

type

status

created

milestone

priority

area

issue

0043

done

2026-08-11

medium

security

docs/adr/0011-enrollment-localpart-kollision-verweigern.md

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.

3.2 KiB Raw Permalink Blame History