Thore Cimbal
a81ea0dd2e
Dazu eine Aussage korrigiert, die seit heute nur noch halb stimmt: "2FA-Selbsteinrichtung optional (not_configured_action=skip)" gilt weiterhin fuer Mitglieder, aber nicht mehr fuer Admins. Festgehalten sind vor allem die beiden Fallen: configure statt deny (deny sperrt Admins aus, ohne Weg zurueck ausser ueber den Cluster) und last_auth_threshold gegen die doppelte Abfrage. Dazu die wichtigste - stimmt der Gruppenname nicht, greift die Regel fuer niemanden und wirft dabei keinen Fehler.
5.0 KiB
Authentik als Identity Provider für Matrix
Status: ✅ Deployed (Stage 1 + Stage 2 + Enrollment/Recovery/2FA, Closes Issue #7)
Domain: auth.axion1337.chat
Überblick
Authentik = OIDC Provider für MAS → Zentrales Login + Einladungs-basierte Registrierung.
Stage 1: Authentik Deployment
Dateien (in apps/authentik/):
namespace.yaml,helm-repo.yaml,authentik-secret.yaml(SOPS)authentik.yaml(HelmRelease v2026.x + embedded Postgres)certificate.yaml,ingress.yaml
Flux Kustomization: clusters/matrix/flux-system/authentik-sync.yaml
Deployment-Schritte
- DNS A-Record:
auth.axion1337.chat → 49.13.132.245 - Pods hochfahren:
kubectl get pods -n authentik -w - Authentik UI:
https://auth.axion1337.chat/if/flow/initial-setup/→ Admin-Passwort setzen - OIDC Provider: Admin UI → OIDC Provider erstellen
- Application: Slug
matrix(wichtig für Issuer URL!) - Redirect URIs:
https://account.axion1337.chat/upstream/callback/01KQDJTR1ZVTG8JQ220F5BNBFZ- Post-logout:
https://axion1337.chat
- Client ID + Secret kopieren
Stage 2: MAS Integration
- Decrypt:
sops --decrypt --in-place apps/production/custom-configs/mas-secret.yaml upstream_oauth2_config+passwords-configBlöcke hinzufügen- Encrypt:
sops --encrypt --in-place ... - Commit & Push
- WICHTIG:
passwords: enabled: falseerst nach OIDC-Test!
Einladungs-Links
Authentik Admin → Flows & Stages → Invitations → Create
Enrollment/Recovery/2FA Fix (2026-07-27, Issue #7)
Der matrix-invitation-Flow hatte nur 2 von 5 nötigen Stages (kein Write/Password/Login) -
Nutzer wurden nie in Synapse angelegt. Behoben und als Authentik Blueprint
(apps/authentik/authentik-blueprints.yaml) deklarativ ins Repo übernommen: vollständiger
matrix-invitation-Flow (Invite → Prompt → Write → Password → Login → Redirect), leerer
matrix-recovery-Flow ergänzt, Brand.default_application gesetzt. 2FA/Passkey-Selbst-
Einrichtung optional (not_configured_action=skip) — ⚠️ gilt seit 2026-08-06 nur noch
für Mitglieder, für Admins ist MFA Pflicht, siehe unten. Auffindbar über
axion1337.chat/docs/setup/security.html. Details: siehe Wiki
Authentik-OIDC.md.
Issue #13 geschlossen (2026-07-29): der ursprünglich hier vorgesehene direkte 2FA-Link auf
account.axion1337.chat/account/ (per MAS Custom-Template-Override) wurde verworfen - live
geprüfte OIDC-Discovery zeigt, dass MAS keine 2FA/Passkey-Deep-Link-Action unterstützt. Jetzt
als Client-seitige Änderung nachgehalten:
ThreadNet-Web#4.
Weitere Details: Siehe Kapitel 2 in diesem Projekt.
MFA-Pflicht für Admins (2026-08-06, gitops#57)
Für Mitglieder bleibt 2FA freiwillig, für die Gruppe authentik Admins ist sie Pflicht.
Umgesetzt als eigener Blueprint admin-mfa-enforcement.yaml in
apps/authentik/authentik-blueprints.yaml.
Warum eine zweite Stage statt einer Umstellung
not_configured_action hängt an der Stage, nicht an der Bindung. Die vorhandene
default-authentication-mfa-validation umzustellen hätte deshalb alle Mitglieder
getroffen — und wäre zugleich eine Änderung an einem Objekt aus Authentiks eigenem
Blueprint gewesen.
Stattdessen: eine eigene admin-mfa-validation auf Ordnung 31, direkt hinter der
Standard-Stage (30) und vor dem Login (100), eingeschränkt über eine PolicyBinding
mit gesetztem group. Eine solche Bindung wertet Gruppenmitgliedschaft aus
(PolicyResult(group.is_member(user))). Kein Authentik-Standardobjekt wird
angefasst.
Die drei Einstellungen, auf die es ankommt
| Feld | Wert | Warum |
|---|---|---|
not_configured_action |
configure |
führt durch die Einrichtung, statt auszusperren |
configuration_stages |
TOTP + WebAuthn | sonst kann configure nichts anbieten |
last_auth_threshold |
hours=1 |
verhindert die doppelte Abfrage |
⚠️ configure, niemals deny. deny weist Admins ohne zweiten Faktor ab — und
danach gibt es keinen Weg zurück außer über den Cluster. configure erzwingt
genauso, führt aber durch die Einrichtung.
⚠️ last_auth_threshold ist kein Beiwerk. Die Standard-Stage auf Ordnung 30
validiert bereits, wer einen Faktor besitzt. Ohne Schwelle (seconds=0, der Default)
würde unsere Stage direkt danach ein zweites Mal fragen. Mit hours=1 überspringt
sie sich, wenn das Gerät gerade benutzt wurde — übrig bleibt genau der Zielfall:
Admin ohne zweiten Faktor.
Die Falle beim Ändern
Der Gruppenname ist die ganze Wirkung. Stimmt er nicht, greift die Regel für niemanden — und wirft dabei keinen Fehler. Das ist schlechter als keine Regel, weil es sich sicher anfühlt. Wer die Gruppe umbenennt, muss den Blueprint mitziehen.
Prüfen lässt sich die Wirkung nur an einem Konto, das in der Gruppe ist: anmelden und sehen, ob nach dem Passwort die Einrichtung kommt.