docs/issues/0043-invitation-flow-eindeutigkeit-case-insensitiv.md

---
type: issue
id: "0043"
status: done
created: 2026-08-11
milestone: M5
priority: medium
area: security
related: [docs/adr/0011-enrollment-localpart-kollision-verweigern.md]
---
# Invitation-Flow: case-insensitive Eindeutigkeitsprüfung im Prompt-Stage

> Offener Rest aus [ADR-0011](../adr/0011-enrollment-localpart-kollision-verweigern.md); GitLab-seitig als [gitops#61](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/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.
docs: capture session knowledge not yet in the repo 2026-08-11 12:00:00 +00:00			`---`
			`type: issue`
			`id: "0043"`
docs(issues): close #0043 , record the coverage map for #0044 2026-08-15 12:00:00 +00:00			`status: done`
docs: capture session knowledge not yet in the repo 2026-08-11 12:00:00 +00:00			`created: 2026-08-11`
			`milestone: M5`
			`priority: medium`
			`area: security`
			`related: [docs/adr/0011-enrollment-localpart-kollision-verweigern.md]`
			`---`
			`# Invitation-Flow: case-insensitive Eindeutigkeitsprüfung im Prompt-Stage`

			`> Offener Rest aus [ADR-0011](../adr/0011-enrollment-localpart-kollision-verweigern.md); GitLab-seitig als [gitops#61](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/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`.
docs(issues): close #0043 , record the coverage map for #0044 2026-08-15 12:00:00 +00:00
			`## 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.`