docs: Add Authentik enrollment flow diagnostics and repair guides
- DIAGNOSTIK-AUTHENTIK-FLOW.md: Comprehensive troubleshooting guide - AUTHENTIK-FIX-TEMPLATE.md: Repair instructions for common issues These guides help debug why Boje user was created in Authentik but not synchronized to Matrix. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
Scrublord MacBad
parent
b29c7516d4
commit
f658ce2980
314
AUTHENTIK-FIX-TEMPLATE.md
Normal file
314
AUTHENTIK-FIX-TEMPLATE.md
Normal file
@ -0,0 +1,314 @@
|
|||||||
|
# ✅ Authentik Enrollment Flow – Reparatur-Template
|
||||||
|
|
||||||
|
Basierend auf häufigen Problemen: Hier sind die wahrscheinlichsten Fixes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem 1: MAS kennt Authentik-OIDC nicht
|
||||||
|
|
||||||
|
### Symptom
|
||||||
|
- MAS zeigt "Sign in with Authentik" Button nicht
|
||||||
|
- Logs: "upstream provider not configured"
|
||||||
|
|
||||||
|
### Lösung
|
||||||
|
|
||||||
|
**MAS Secret muss diesen Block enthalten:**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# apps/production/custom-configs/mas-secret.yaml (decrypted)
|
||||||
|
---
|
||||||
|
matrixAuthenticationService:
|
||||||
|
upstream_oauth2_config:
|
||||||
|
issuer: "https://auth.axion1337.chat/application/o/matrix/"
|
||||||
|
client_id: "{{ CLIENT_ID_FROM_AUTHENTIK }}"
|
||||||
|
client_secret: "{{ CLIENT_SECRET_FROM_AUTHENTIK }}"
|
||||||
|
authorization_endpoint: "https://auth.axion1337.chat/application/o/authorize/"
|
||||||
|
token_endpoint: "https://auth.axion1337.chat/application/o/token/"
|
||||||
|
userinfo_endpoint: "https://auth.axion1337.chat/application/o/userinfo/"
|
||||||
|
scopes:
|
||||||
|
- "openid"
|
||||||
|
- "profile"
|
||||||
|
- "email"
|
||||||
|
user_mapping_provider:
|
||||||
|
type: "oidc"
|
||||||
|
config:
|
||||||
|
localpart_template: "{{ user.preferred_username }}"
|
||||||
|
display_name_template: "{{ user.name }}"
|
||||||
|
email_template: "{{ user.email }}"
|
||||||
|
|
||||||
|
# Wichtig: Password-Login deaktivieren (da wir nur OIDC verwenden)
|
||||||
|
passwords:
|
||||||
|
enabled: false
|
||||||
|
```
|
||||||
|
|
||||||
|
**Wie ausfüllen:**
|
||||||
|
|
||||||
|
1. Authentik Admin UI öffnen: `https://auth.axion1337.chat`
|
||||||
|
2. Admin → Applications → Providers → "matrix-provider" (oder ähnlich)
|
||||||
|
3. Folgende Werte kopieren:
|
||||||
|
- **Client ID**: Im Provider-Details zu sehen
|
||||||
|
- **Client Secret**: Im Provider-Details zu sehen (unter "Credentials")
|
||||||
|
|
||||||
|
4. Local entschlüsseln (mit age-key):
|
||||||
|
```bash
|
||||||
|
cd gitops/
|
||||||
|
sops -d -i apps/production/custom-configs/mas-secret.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
5. Datei öffnen und die Werte einfügen
|
||||||
|
|
||||||
|
6. Wieder verschlüsseln:
|
||||||
|
```bash
|
||||||
|
sops -e -i apps/production/custom-configs/mas-secret.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
7. Commiten:
|
||||||
|
```bash
|
||||||
|
git add apps/production/custom-configs/mas-secret.yaml
|
||||||
|
git commit -m "Fix: Configure MAS upstream OIDC for Authentik"
|
||||||
|
git push
|
||||||
|
```
|
||||||
|
|
||||||
|
8. Flux triggern:
|
||||||
|
```bash
|
||||||
|
flux reconcile kustomization production-apps --with-source
|
||||||
|
```
|
||||||
|
|
||||||
|
9. Warten, dass MAS Pod neu startet:
|
||||||
|
```bash
|
||||||
|
kubectl get pods -n matrix -l app=matrix-authentication-service -w
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem 2: Authentik Enrollment Flow ist kaputt
|
||||||
|
|
||||||
|
### Symptom
|
||||||
|
- User kommt zu Authentik-Login
|
||||||
|
- Nach Login: "Error: Enrollment stage not found" oder ähnlich
|
||||||
|
- Oder: Flow bricht ohne Fehlermeldung ab
|
||||||
|
|
||||||
|
### Lösung
|
||||||
|
|
||||||
|
**Authentik UI → Flows & Stages → Enrollment Flow überprüfen:**
|
||||||
|
|
||||||
|
```
|
||||||
|
Flows → Enrollment
|
||||||
|
├── Stage 1: "Identify" (if not exists)
|
||||||
|
│ └── Binding: "Identification (if not exists)"
|
||||||
|
├── Stage 2: "Write" (wichtig!)
|
||||||
|
│ └── Binding: "Create or update user"
|
||||||
|
│ └── User Creation Policies: ???
|
||||||
|
├── Stage 3: (optional) Weitere Datenerfassung
|
||||||
|
└── Stage 4: "Finish"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Häufiger Fehler**: "Write" Stage ist nicht korrekt mit den benötigten Feldern konfiguriert.
|
||||||
|
|
||||||
|
**Fix:**
|
||||||
|
|
||||||
|
1. Authentik Admin UI: `https://auth.axion1337.chat`
|
||||||
|
2. **Flows & Stages** → **Stages**
|
||||||
|
3. Nach "Write" Stage suchen (Filter: "write")
|
||||||
|
4. Klick auf "Write Stage"
|
||||||
|
5. **Field Bindings** überprüfen:
|
||||||
|
- [ ] `username` ← MUSS mit Authentik Username bindbar sein
|
||||||
|
- [ ] `email` ← MUSS vorhanden sein
|
||||||
|
- [ ] `name` ← Optional, aber empfohlen
|
||||||
|
6. Alle sollten "required" sein (nicht optional)
|
||||||
|
7. **Save**
|
||||||
|
|
||||||
|
Dann zurück zu **Flows** → **Enrollment**:
|
||||||
|
1. Stages überprüfen (oben)
|
||||||
|
2. Bindings überprüfen:
|
||||||
|
- Each Stage hat "Binding" Feld
|
||||||
|
- "Write" Stage sollte mit "Create or update user" gebunden sein
|
||||||
|
3. **Save**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem 3: OIDC Token werden nicht korrekt zu Synapse weitergeleitet
|
||||||
|
|
||||||
|
### Symptom
|
||||||
|
- User kommt bis zu ElementWeb
|
||||||
|
- Nach Login zu Authentik: "User not found in Synapse" oder Loop
|
||||||
|
- Oder: User wird in Authentik angelegt, aber nicht in Synapse
|
||||||
|
|
||||||
|
### Lösung
|
||||||
|
|
||||||
|
Das ist komplexer und erfordert MAS-Konfiguration + Synapse-Konfiguration.
|
||||||
|
|
||||||
|
**MAS Config (upstream_oauth2_config)** muss korrekt sein (siehe Problem 1).
|
||||||
|
|
||||||
|
**Zusätzlich in MAS Secret:**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# apps/production/custom-configs/mas-secret.yaml
|
||||||
|
matrixAuthenticationService:
|
||||||
|
# ... upstream_oauth2_config ...
|
||||||
|
|
||||||
|
# User-Provisioning Konfiguration
|
||||||
|
access:
|
||||||
|
# Benutzer aus OIDC Provider automatisch erzeugen
|
||||||
|
auto_provision: true
|
||||||
|
# Synapse URL
|
||||||
|
home_server: "https://matrix.axion1337.chat"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem 4: ElementWeb zeigt nicht automatisch OIDC-Button
|
||||||
|
|
||||||
|
### Symptom
|
||||||
|
- MAS läuft und hat OIDC konfiguriert
|
||||||
|
- ElementWeb zeigt nur "Sign in with username" oder "SAML login"
|
||||||
|
- Kein "Sign in with Authentik" Button
|
||||||
|
|
||||||
|
### Lösung
|
||||||
|
|
||||||
|
ElementWeb muss die MAS-Konfiguration kennen. Das geschieht über `.well-known/matrix/client`:
|
||||||
|
|
||||||
|
**Test:**
|
||||||
|
```bash
|
||||||
|
curl https://axion1337.chat/.well-known/matrix/client | jq '.authentication'
|
||||||
|
```
|
||||||
|
|
||||||
|
Sollte zurückgeben:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"flows": [
|
||||||
|
{
|
||||||
|
"stages": ["m.login.sso"]
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"identity_providers": [
|
||||||
|
{
|
||||||
|
"id": "authentik",
|
||||||
|
"name": "Authentik",
|
||||||
|
"icon": "...",
|
||||||
|
"brand": "custom"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Falls nicht: **ElementWeb Config in Element-Stack aktualisieren:**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# apps/production/custom-configs/element-values.yaml
|
||||||
|
elementWeb:
|
||||||
|
config:
|
||||||
|
auth:
|
||||||
|
sso_redirect_options:
|
||||||
|
immediate: false
|
||||||
|
on_welcome_page: true
|
||||||
|
```
|
||||||
|
|
||||||
|
**Dann:**
|
||||||
|
```bash
|
||||||
|
git add apps/production/custom-configs/element-values.yaml
|
||||||
|
git commit -m "Fix: Enable SSO redirect in ElementWeb"
|
||||||
|
git push
|
||||||
|
flux reconcile kustomization production-apps --with-source
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem 5: User kann sich anmelden, aber Boje ist nicht in Matrix
|
||||||
|
|
||||||
|
### Symptom
|
||||||
|
- Authentik-Login funktioniert
|
||||||
|
- MAS zeigt User erfolgreich
|
||||||
|
- ElementWeb Login funktioniert
|
||||||
|
- **ABER**: User ist nicht in Synapse (check mit `kubectl exec -n matrix synapse ...`)
|
||||||
|
|
||||||
|
### Lösung
|
||||||
|
|
||||||
|
Das bedeutet: User wird nicht automatisch in Synapse provisioniert.
|
||||||
|
|
||||||
|
**MAS muss User zu Synapse erstellen:**
|
||||||
|
|
||||||
|
In MAS Secret, `access` Sektion:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
matrixAuthenticationService:
|
||||||
|
access:
|
||||||
|
# Synapse erlaubt neue User-Erstellung
|
||||||
|
homeserver: "https://matrix.axion1337.chat"
|
||||||
|
|
||||||
|
# Optional: User automatisch erstellen
|
||||||
|
registration_enabled: true
|
||||||
|
```
|
||||||
|
|
||||||
|
**Synapse-seitig** muss auch User-Erstellung erlaubt sein:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
# apps/production/custom-configs/synapse-values.yaml
|
||||||
|
synapse:
|
||||||
|
additional:
|
||||||
|
registration:
|
||||||
|
config: |
|
||||||
|
enable_registration: true
|
||||||
|
enable_registration_without_token: false
|
||||||
|
# Token wird von MAS bereitgestellt
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Komplettes Test-Szenario
|
||||||
|
|
||||||
|
Nach allen Fixes:
|
||||||
|
|
||||||
|
1. **Browser 1**: `https://axion1337.chat` öffnen
|
||||||
|
2. Auf ElementWeb "Sign in" klicken
|
||||||
|
3. "Sign in with Authentik" klicken (sollte sichtbar sein)
|
||||||
|
4. Authentik-Login durchführen (akadmin)
|
||||||
|
5. Nach Login: Enrollment-Flow (nur falls neuer User)
|
||||||
|
6. Zurück zu ElementWeb
|
||||||
|
7. **Synapse prüfen**:
|
||||||
|
```bash
|
||||||
|
kubectl exec -it -n matrix deployment/synapse -- \
|
||||||
|
/usr/local/bin/psql -U synapse -d synapse -c "SELECT name, admin FROM users LIMIT 10;"
|
||||||
|
```
|
||||||
|
8. Neuer User sollte auftauchen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Debugging-Commands (während Test)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Live MAS logs (folgen)
|
||||||
|
kubectl logs -n matrix -l app=matrix-authentication-service -f
|
||||||
|
|
||||||
|
# Authentik logs
|
||||||
|
kubectl logs -n authentik -l app.kubernetes.io/name=authentik -f
|
||||||
|
|
||||||
|
# Port-Forward für manuelles Testen
|
||||||
|
kubectl port-forward -n matrix svc/matrix-authentication-service 8765:8080
|
||||||
|
|
||||||
|
# MAS Secret auslesen (im Cluster)
|
||||||
|
kubectl get secret ess-mas-values-secret -n matrix -o jsonpath='{.data.values\.yaml}' | base64 -d
|
||||||
|
|
||||||
|
# Synapse User-Liste
|
||||||
|
kubectl exec -it -n matrix deployment/synapse -- \
|
||||||
|
/usr/local/bin/psql -U synapse -d synapse -c "SELECT name, admin, is_guest FROM users;"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Checkliste für erfolgreichen Fix
|
||||||
|
|
||||||
|
- [ ] MAS Secret decrypted, upstream_oauth2_config eingetragen
|
||||||
|
- [ ] Client ID + Secret von Authentik kopiert
|
||||||
|
- [ ] MAS Secret re-encrypted und commited
|
||||||
|
- [ ] Authentik Enrollment Flow überprüft
|
||||||
|
- [ ] OIDC Provider in Authentik aktiv
|
||||||
|
- [ ] OIDC Application "matrix" in Authentik existiert
|
||||||
|
- [ ] MAS Pod neu gestartet (nach Secret-Change)
|
||||||
|
- [ ] ElementWeb zeigt OIDC-Button
|
||||||
|
- [ ] Test-Login durchgeführt
|
||||||
|
- [ ] Neuer User in Synapse DB vorhanden
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Fragen?** → Siehe `DIAGNOSTIK-AUTHENTIK-FLOW.md` für tiefergehende Diagnose.
|
||||||
261
DIAGNOSTIK-AUTHENTIK-FLOW.md
Normal file
261
DIAGNOSTIK-AUTHENTIK-FLOW.md
Normal file
@ -0,0 +1,261 @@
|
|||||||
|
# 🔍 Authentik Enrollment Flow – Diagnostik & Reparaturplan
|
||||||
|
|
||||||
|
**Symptom**:
|
||||||
|
- `akadmin` wurde manuell in Matrix-DB angelegt (funktioniert)
|
||||||
|
- `Boje` wurde nur in Authentik erstellt, nicht in Matrix-DB (kaputt)
|
||||||
|
- Beide sollen denselben Enrollment Flow verwenden
|
||||||
|
|
||||||
|
**Vermutung**: Die Authentik → MAS → Synapse Kette ist unterbrochen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 1: Diagnose (Bestandsaufnahme)
|
||||||
|
|
||||||
|
### 1.1 Authentik Logs prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Authentik Server logs
|
||||||
|
kubectl logs -n authentik -l app.kubernetes.io/name=authentik -f | grep -i "oauth\|oidc\|enroll\|flow"
|
||||||
|
|
||||||
|
# Worker logs
|
||||||
|
kubectl logs -n authentik -l app.kubernetes.io/component=worker -f | grep -i "enroll"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Worauf achten**:
|
||||||
|
- Fehler bei "Enrollment create"?
|
||||||
|
- OIDC Token-Probleme?
|
||||||
|
- Flow-Validierungsfehler?
|
||||||
|
|
||||||
|
### 1.2 MAS (Matrix Authentication Service) Logs prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# MAS logs
|
||||||
|
kubectl logs -n matrix -l app=matrix-authentication-service -f | grep -i "oauth\|upstream\|user\|oidc"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Worauf achten**:
|
||||||
|
- Verbindung zu Authentik erfolgreich?
|
||||||
|
- Token-Validierung fehlgeschlagen?
|
||||||
|
- User-Provisioning-Fehler?
|
||||||
|
|
||||||
|
### 1.3 Synapse Logs prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Synapse logs (für User-Erstellung)
|
||||||
|
kubectl logs -n matrix -l app=synapse -f | grep -i "user\|provision\|register\|auth"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Worauf achten**:
|
||||||
|
- User-Registrierungs-Fehler?
|
||||||
|
- Provisioning-Fehler?
|
||||||
|
- Authentifizierungsprobleme?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 2: Authentik UI Überprüfung
|
||||||
|
|
||||||
|
### 2.1 Enrollment Flow inspizieren
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Authentik UI öffnen
|
||||||
|
kubectl port-forward -n authentik svc/authentik 9000:9000
|
||||||
|
# → Browser: http://localhost:9000
|
||||||
|
# → Admin UI → Flows & Stages → "Enrollment" Flow suchen
|
||||||
|
```
|
||||||
|
|
||||||
|
**Checklist**:
|
||||||
|
- [ ] Flow existiert und heißt "Enrollment"
|
||||||
|
- [ ] Reihenfolge der Stages:
|
||||||
|
1. Identify (optional)
|
||||||
|
2. Write (User-Erstellung)
|
||||||
|
3. Enrollment (if-condition für neuen User)
|
||||||
|
4. Verification (optional)
|
||||||
|
- [ ] "Write Stage" bindet sich an:
|
||||||
|
- [ ] Username
|
||||||
|
- [ ] Email
|
||||||
|
- [ ] Name
|
||||||
|
- [ ] Alle Bindings sind "required" (nicht optional)
|
||||||
|
|
||||||
|
### 2.2 OIDC Provider in Authentik prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Über Authentik UI:
|
||||||
|
# Admin → Applications → Providers → "matrix-provider" (oder ähnlich)
|
||||||
|
```
|
||||||
|
|
||||||
|
**Checklist**:
|
||||||
|
- [ ] Provider existiert
|
||||||
|
- [ ] Name: z.B. "matrix-provider"
|
||||||
|
- [ ] Client Type: "Confidential"
|
||||||
|
- [ ] Redirect URIs enthalten:
|
||||||
|
- [ ] `https://account.axion1337.chat/upstream/callback/*`
|
||||||
|
- [ ] `https://account.axion1337.chat/upstream/callback/01KQDJTR1ZVTG8JQ220F5BNBFZ` (exact)
|
||||||
|
- [ ] Scopes: `openid profile email`
|
||||||
|
- [ ] Client ID + Secret kopiert?
|
||||||
|
|
||||||
|
### 2.3 OIDC Application in Authentik
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Admin → Applications → Applications → "matrix"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Checklist**:
|
||||||
|
- [ ] Application existiert mit Slug "matrix"
|
||||||
|
- [ ] Provider ist zugewiesen
|
||||||
|
- [ ] Enrollment Flow ist zugewiesen (nicht "deny")
|
||||||
|
- [ ] Enrollment Flow ist die richtige (die von oben)
|
||||||
|
|
||||||
|
### 2.4 Test-User "Boje" inspizieren
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Admin → Directory → Users → "Boje"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Checklist**:
|
||||||
|
- [ ] Username: `boje`
|
||||||
|
- [ ] Email: `boje@...` (vorhanden?)
|
||||||
|
- [ ] Groups: Falls erforderlich, die richtigen Groups zugewiesen?
|
||||||
|
- [ ] Status: Active oder Disabled?
|
||||||
|
- [ ] Sessions: Aktive Logins?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 3: MAS Konfiguration überprüfen
|
||||||
|
|
||||||
|
### 3.1 Current MAS Secret auslesen
|
||||||
|
|
||||||
|
Da der age-key nicht lokal verfügbar ist, müssen wir die Konfiguration im Cluster prüfen:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# MAS Config im Cluster auslesen (nicht verschlüsselt)
|
||||||
|
kubectl get secret ess-mas-values-secret -n matrix -o jsonpath='{.data.values\.yaml}' | base64 -d | yq . | head -100
|
||||||
|
```
|
||||||
|
|
||||||
|
**Worauf achten**:
|
||||||
|
- [ ] `upstream_oauth2_config` Block existiert
|
||||||
|
- [ ] `upstream_oauth2_config.issuer`: `https://auth.axion1337.chat/application/o/matrix/`
|
||||||
|
- [ ] `upstream_oauth2_config.client_id`: Authentik Client ID
|
||||||
|
- [ ] `upstream_oauth2_config.client_secret`: Authentik Client Secret (*)
|
||||||
|
- [ ] `upstream_oauth2_config.scopes`: `["openid", "profile", "email"]`
|
||||||
|
- [ ] `upstream_oauth2_config.user_mapping_provider`:
|
||||||
|
- `type`: "oidc"
|
||||||
|
- `config.localpart_template`: `{{ user.preferred_username }}`
|
||||||
|
- `config.display_name_template`: `{{ user.name }}`
|
||||||
|
- `config.email_template`: `{{ user.email }}`
|
||||||
|
|
||||||
|
### 3.2 MAS Pod exec – Config live prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# MAS Config im laufenden Pod inspizieren
|
||||||
|
kubectl exec -it -n matrix deployment/matrix-authentication-service -- cat /etc/mas/config.yaml | grep -A50 upstream_oauth2_config
|
||||||
|
```
|
||||||
|
|
||||||
|
**Worauf achten**:
|
||||||
|
- Config ist syntaktisch korrekt (YAML)?
|
||||||
|
- Indentierung ist richtig?
|
||||||
|
- Werte sind vorhanden?
|
||||||
|
|
||||||
|
### 3.3 MAS OIDC Discovery prüfen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Authentik OIDC Discovery Endpoint
|
||||||
|
curl -s https://auth.axion1337.chat/application/o/matrix/.well-known/openid-configuration | jq .
|
||||||
|
|
||||||
|
# Sollte zurückgeben:
|
||||||
|
# {
|
||||||
|
# "issuer": "https://auth.axion1337.chat/application/o/matrix/",
|
||||||
|
# "token_endpoint": "https://auth.axion1337.chat/application/o/token/",
|
||||||
|
# "authorization_endpoint": "...",
|
||||||
|
# ...
|
||||||
|
# }
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 4: Login-Flow Testen
|
||||||
|
|
||||||
|
### 4.1 MAS Login UI öffnen
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Port-Forward zu MAS
|
||||||
|
kubectl port-forward -n matrix svc/matrix-authentication-service 8765:8080
|
||||||
|
# → Browser: http://localhost:8765
|
||||||
|
```
|
||||||
|
|
||||||
|
**Test**:
|
||||||
|
1. Auf MAS-Seite: "Sign in with Authentik" klicken
|
||||||
|
2. Authentik-Login durchführen
|
||||||
|
3. Auf Enrollment Flow warten
|
||||||
|
4. Neuen User erstellen (Test-Username, Email, Password)
|
||||||
|
5. Nach erfolgreicher Registrierung: Matrix home_server erhalten?
|
||||||
|
|
||||||
|
### 4.2 Fehlerberichte
|
||||||
|
|
||||||
|
Falls Fehler auftritt:
|
||||||
|
- [ ] Screenshot des Fehlers
|
||||||
|
- [ ] MAS logs auslesen: `kubectl logs -n matrix -l app=matrix-authentication-service --tail=50`
|
||||||
|
- [ ] Authentik logs auslesen: `kubectl logs -n authentik -l app.kubernetes.io/name=authentik --tail=50`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Phase 5: Reparaturschritte (nachdem Diagnose klar ist)
|
||||||
|
|
||||||
|
### Falls MAS-Config fehlerhaft:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Secrets entschlüsseln (lokale Umgebung mit age-key erforderlich)
|
||||||
|
sops -d apps/production/custom-configs/mas-secret.yaml > /tmp/mas-secret-decrypted.yaml
|
||||||
|
|
||||||
|
# 2. Editor öffnen und Konfiguration reparieren
|
||||||
|
vim /tmp/mas-secret-decrypted.yaml
|
||||||
|
# → upstream_oauth2_config überprüfen und korrigieren
|
||||||
|
|
||||||
|
# 3. Wieder verschlüsseln
|
||||||
|
sops -e /tmp/mas-secret-decrypted.yaml > apps/production/custom-configs/mas-secret.yaml
|
||||||
|
|
||||||
|
# 4. Commiten
|
||||||
|
git add apps/production/custom-configs/mas-secret.yaml
|
||||||
|
git commit -m "Fix: Correct MAS upstream_oauth2_config for Authentik integration"
|
||||||
|
|
||||||
|
# 5. Flux triggern
|
||||||
|
flux reconcile kustomization production-apps --with-source
|
||||||
|
```
|
||||||
|
|
||||||
|
### Falls Authentik Enrollment Flow fehlerhaft:
|
||||||
|
|
||||||
|
1. Admin UI öffnen: `kubectl port-forward -n authentik svc/authentik 9000:9000`
|
||||||
|
2. Flows → Enrollment Flow öffnen
|
||||||
|
3. Stages überprüfen und in richtige Reihenfolge bringen:
|
||||||
|
- **Identify**: Benutzer identifizieren
|
||||||
|
- **Write**: Benutzer in DB speichern
|
||||||
|
- **Enrollment**: Weitere Felder (optional)
|
||||||
|
- **Finish**: Abschluss
|
||||||
|
4. Speichern
|
||||||
|
5. Neuen Test-User erstellen und Enrollment durchlaufen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Erwartete Endergebnisse
|
||||||
|
|
||||||
|
Nach erfolgreichem Fix:
|
||||||
|
1. Benutzer klickt "Sign in with Authentik" auf MAS
|
||||||
|
2. Authentik-Login-Seite wird angezeigt
|
||||||
|
3. Nach Login: Enrollment Flow wird angezeigt
|
||||||
|
4. User füllt Formular aus
|
||||||
|
5. Nach "Finish": Authentik erstellt User UND verbindet zu Matrix
|
||||||
|
6. User wird in Matrix-DB angelegt (`_matrix_auth` prefix)
|
||||||
|
7. User kan sich bei ElementWeb anmelden
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Nächster Schritt
|
||||||
|
|
||||||
|
Bitte folgende Diagnostik durchlaufen und mir die Output berichte:
|
||||||
|
|
||||||
|
1. **MAS Logs** (letzten 30 Zeilen)
|
||||||
|
2. **Authentik Logs** (letzten 30 Zeilen)
|
||||||
|
3. **MAS Secret (entschlüsselt)** – upstream_oauth2_config Block
|
||||||
|
4. **Authentik OIDC Discovery** Output
|
||||||
|
5. **Screenshots** der Authentik UI (Enrollment Flow, OIDC Provider, Application)
|
||||||
|
|
||||||
|
Damit kann ich dann genau sehen, wo der Bruch in der Kette ist! 🔗
|
||||||
Loading…
x
Reference in New Issue
Block a user