SSO für dev.toppyr.de (Keycloak Forward-Auth) #7

Closed
opened 2026-03-31 01:05:08 +02:00 by tobias · 2 comments
Owner

Beschreibung

dev.toppyr.de ist aktuell ohne Authentifizierung erreichbar. Absicherung über Keycloak Forward-Auth wie bei gruen.toppyr.de.

Ist-Zustand

  • dev.toppyr.de → SSH-Tunnel zum Mac mini (Dev-Server)
  • Kein Auth-Layer
  • forward-auth Container existiert bereits (thomseddon/traefik-forward-auth)
  • Keycloak-Realm collaboration auf sso.toppyr.de aktiv
  • Funktionierendes Beispiel: gruen.toppyr.de nutzt sso-auth@docker Middleware

Umsetzung

Option A: Bestehende sso-auth Middleware mitnutzen

Einfachste Lösung — gleiche Middleware wie gruen.toppyr.de:

labels:
  - "traefik.http.routers.dev.middlewares=sso-auth@docker"

Vorteil: Kein neuer Keycloak-Client nötig, gruene-antraege Client wird wiederverwendet.
Nachteil: Cookie-Domain ist toppyr.de — ein Login gilt für alle Forward-Auth-geschützten Services.

Option B: Eigener Keycloak-Client dev-tunnel

Sauberer, aber mehr Aufwand:

  • Neuer Client dev-tunnel in Keycloak anlegen
  • Eigener Forward-Auth Container oder separater OIDC-Client im bestehenden
  • Eigene Redirect-URI: https://dev.toppyr.de/_oauth

Offene Fragen

  1. Option A oder B? A ist sofort machbar (eine Zeile). B ist sauberer für Zukunft. Empfehlung: A jetzt, B wenn die Antragsideen-App eigenes SSO bekommt (Issue #3 im antragsideen-hagen Repo).

  2. Wer soll Zugang haben? Alle User im Realm collaboration oder nur bestimmte Rollen?

  3. Cookie-Sharing: Aktuell teilen sich alle Forward-Auth-Services (gruen.toppyr.de, dev.toppyr.de) eine Session. Ist das gewünscht oder soll dev.toppyr.de eine separate Auth-Session haben?

  4. Temporär oder permanent? Dev-Tunnel ist per Definition temporär (läuft nur wenn SSH-Tunnel aktiv). Braucht es trotzdem SSO oder reicht Basic-Auth als Quick-Fix?

Abhängigkeiten

  • toppyr-stack #1 (dev.toppyr.de Reverse-Tunnel) erledigt
  • Keycloak muss laufen
  • forward-auth Container muss laufen
## Beschreibung dev.toppyr.de ist aktuell ohne Authentifizierung erreichbar. Absicherung über Keycloak Forward-Auth wie bei gruen.toppyr.de. ## Ist-Zustand - `dev.toppyr.de` → SSH-Tunnel zum Mac mini (Dev-Server) - Kein Auth-Layer - `forward-auth` Container existiert bereits (thomseddon/traefik-forward-auth) - Keycloak-Realm `collaboration` auf sso.toppyr.de aktiv - Funktionierendes Beispiel: `gruen.toppyr.de` nutzt `sso-auth@docker` Middleware ## Umsetzung ### Option A: Bestehende sso-auth Middleware mitnutzen Einfachste Lösung — gleiche Middleware wie gruen.toppyr.de: ```yaml labels: - "traefik.http.routers.dev.middlewares=sso-auth@docker" ``` Vorteil: Kein neuer Keycloak-Client nötig, `gruene-antraege` Client wird wiederverwendet. Nachteil: Cookie-Domain ist `toppyr.de` — ein Login gilt für alle Forward-Auth-geschützten Services. ### Option B: Eigener Keycloak-Client `dev-tunnel` Sauberer, aber mehr Aufwand: - Neuer Client `dev-tunnel` in Keycloak anlegen - Eigener Forward-Auth Container oder separater OIDC-Client im bestehenden - Eigene Redirect-URI: `https://dev.toppyr.de/_oauth` ## Offene Fragen 1. **Option A oder B?** A ist sofort machbar (eine Zeile). B ist sauberer für Zukunft. Empfehlung: A jetzt, B wenn die Antragsideen-App eigenes SSO bekommt (Issue #3 im antragsideen-hagen Repo). 2. **Wer soll Zugang haben?** Alle User im Realm `collaboration` oder nur bestimmte Rollen? 3. **Cookie-Sharing:** Aktuell teilen sich alle Forward-Auth-Services (gruen.toppyr.de, dev.toppyr.de) eine Session. Ist das gewünscht oder soll dev.toppyr.de eine separate Auth-Session haben? 4. **Temporär oder permanent?** Dev-Tunnel ist per Definition temporär (läuft nur wenn SSH-Tunnel aktiv). Braucht es trotzdem SSO oder reicht Basic-Auth als Quick-Fix? ## Abhängigkeiten - toppyr-stack #1 (dev.toppyr.de Reverse-Tunnel) ✅ erledigt - Keycloak muss laufen ✅ - forward-auth Container muss laufen ✅
Author
Owner

Entscheidung: Option B — Eigener Keycloak-Client

Umsetzungsschritte:

  1. Keycloak: Client dev-tunnel im Realm collaboration anlegen
  2. Eigener Forward-Auth Container oder Konfiguration im bestehenden
  3. Separate Traefik-Middleware dev-sso-auth
  4. Redirect-URI: https://dev.toppyr.de/_oauth
### Entscheidung: Option B — Eigener Keycloak-Client Umsetzungsschritte: 1. Keycloak: Client `dev-tunnel` im Realm `collaboration` anlegen 2. Eigener Forward-Auth Container oder Konfiguration im bestehenden 3. Separate Traefik-Middleware `dev-sso-auth` 4. Redirect-URI: `https://dev.toppyr.de/_oauth`
Author
Owner

Erledigt (31.03.2026)

Umsetzung (Option B)

  • Keycloak Client: dev-tunnel im Realm collaboration
  • Client Secret: dev-tunnel-secret-2026
  • Forward-Auth Container: dev-forward-auth (thomseddon/traefik-forward-auth)
  • Cookie-Domain: dev.toppyr.de (isoliert von gruen.toppyr.de)
  • Traefik Middleware: dev-sso-auth@docker
  • Redirect-URI: https://dev.toppyr.de/_oauth

Test

  • Browser → dev.toppyr.de → Redirect auf Keycloak → Login → App sichtbar
## Erledigt (31.03.2026) ### Umsetzung (Option B) - **Keycloak Client:** `dev-tunnel` im Realm `collaboration` - **Client Secret:** `dev-tunnel-secret-2026` - **Forward-Auth Container:** `dev-forward-auth` (thomseddon/traefik-forward-auth) - **Cookie-Domain:** `dev.toppyr.de` (isoliert von gruen.toppyr.de) - **Traefik Middleware:** `dev-sso-auth@docker` - **Redirect-URI:** `https://dev.toppyr.de/_oauth` ### Test - Browser → dev.toppyr.de → Redirect auf Keycloak → Login → App sichtbar ✅
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: tobias/toppyr-stack#7
No description provided.