Anmeldung wahlweise ueber OpenID Connect (Authentik)
Neben dem Passwort-Login gibt es jetzt einen zweiten, gleichberechtigten Weg: OpenID Connect gegen einen selbst gehosteten Anmeldedienst. Ohne Konfiguration aendert sich nichts - keine SSO-Knoepfe, Passwort-Login wie bisher. Der Anmeldedienst ist NUR fuer die Anmeldung zustaendig. Danach stellt Vorrania sein eigenes Token aus wie beim Passwort-Login, deshalb bleiben deps.py, die Rollenpruefung und die langlebigen API-Tokens unveraendert. Backend - Anbieter kommen aus der Umgebung (OIDC_PROVIDERS + OIDC_<KUERZEL>_*). Ein zweiter Anbieter ist damit reine Konfiguration, ohne Codeaenderung. - Browser-Weg (vertraulicher Client) und App-Weg (oeffentlicher Client, PKCE) enden beide im selben Token-Schema. - state/nonce/PKCE-Verifier liegen in einer kurzlebigen Tabelle statt in einem Cookie: Starlettes CORS-Schicht spiegelt bei allow_origins=["*"] zusammen mit allow_credentials die Herkunft zurueck, sobald ein Request ein Cookie traegt. Ohne Cookie entsteht diese Wechselwirkung erst gar nicht - und der Ablauf bleibt mit der db-Fixture pruefbar. - Zuordnung ueber die sub des Anbieters; die Erstverknuepfung laeuft ueber die BESTAETIGTE E-Mail-Adresse. Rollen kommen nie aus dem Anbieter, und ein gleichlautender preferred_username uebernimmt nie ein bestehendes Konto. - users.password_hash darf jetzt leer sein (reine SSO-Konten). verify_password faengt das ab, sonst antwortete der Login mit 500 statt 401. Verknuepfen bestehender Konten - Neue Seite "Mein Konto" (fuer alle Benutzer, nicht nur Admins): verknuepfen und wieder loesen. Die Berechtigung stammt aus der laufenden Sitzung, es braucht also weder eine hinterlegte Adresse noch Admin-Rechte. - Der Start laeuft ueber POST, weil eine Seitennavigation das Bearer-Token nicht mitschicken kann. - Die letzte Anmeldemoeglichkeit eines Kontos laesst sich nicht loesen. iOS - AppAuth (erste Paketabhaengigkeit) mit PKCE im System-Browser, nie in einem eingebetteten WebView, und ohne Client-Secret. - offline_access nur im App-Weg: der Browser-Weg braucht kein Refresh-Token und bekaeme sonst einen ueberfluessigen Zustimmungsdialog. - Anmeldezustand je Serverprofil im Keychain; abgelaufene Token erneuert die App still im Hintergrund. Gleichzeitige 401er teilen sich eine Erneuerung. Deployment - docker-compose reicht die ganze .env durch. Einzeln aufzuzaehlen ginge nur mit fest verdrahteten Kuerzeln - genau das soll ein weiterer Anbieter nicht erfordern. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
8d4954610b
commit
3d0ff54bf5
@@ -44,6 +44,9 @@ Auslagern wird automatisch die zuerst ablaufende Charge entnommen (**FEFO**).
|
||||
- **Mehrbenutzer mit Rollen:** *Admin* verwaltet Stammdaten und Benutzer,
|
||||
*Nutzer* lagert nur ein/aus und sieht Bestände; alle Bewegungen werden
|
||||
protokolliert.
|
||||
- **Single Sign-on (optional)** über OpenID Connect, z. B. gegen ein selbst
|
||||
gehostetes [Authentik](https://goauthentik.io). Der Passwort-Login bleibt
|
||||
daneben bestehen – siehe [Single Sign-on](#single-sign-on-optional).
|
||||
|
||||
### In der iOS-App zusätzlich
|
||||
- **Scannen** von Barcode, **MHD/Datum per Texterkennung** (auch nur Tag+Monat
|
||||
@@ -57,6 +60,7 @@ Details zur App: [ios/README.md](ios/README.md).
|
||||
| Teil | Technik |
|
||||
|---------|----------------------------------------|
|
||||
| Backend | Python · FastAPI · SQLAlchemy |
|
||||
| Anmeldung | Passwort (JWT) und optional OpenID Connect |
|
||||
| DB | PostgreSQL (SQLite für Tests/lokal) |
|
||||
| Web-UI | React · Vite (via nginx ausgeliefert) |
|
||||
| iOS | Native SwiftUI-App (VisionKit-Scanner) |
|
||||
@@ -95,6 +99,76 @@ Nach dem Start:
|
||||
|
||||
Die iOS-App wird mit derselben Adresse verbunden (`http://<server-ip>:8080`).
|
||||
|
||||
## Single Sign-on (optional)
|
||||
|
||||
Neben dem Passwort-Login kann sich Vorrania an einen OpenID-Connect-Dienst
|
||||
hängen (getestet mit Authentik). Ohne Konfiguration ändert sich nichts: Es gibt
|
||||
keinen SSO-Knopf, und der Passwort-Login bleibt der einzige Weg.
|
||||
|
||||
**1. In Authentik zwei Provider anlegen** – die Web-Oberfläche und die App
|
||||
brauchen unterschiedliche Client-Typen:
|
||||
|
||||
| Für | Typ | Redirect-URI |
|
||||
|-----|-----|--------------|
|
||||
| Web-UI | *Confidential* (mit Secret) | `https://<deine-adresse>/api/auth/oidc/authentik/callback` |
|
||||
| iOS-App | *Public* (ohne Secret, PKCE) | `vorrania://oauth/callback` |
|
||||
|
||||
Das `/api` in der Web-Adresse ist kein Versehen: Es entsteht im mitgelieferten
|
||||
nginx und gehört deshalb in die bei Authentik hinterlegte Adresse.
|
||||
|
||||
Damit die App ihre Anmeldung im Hintergrund erneuern kann, muss der
|
||||
öffentliche Client `offline_access` ausliefern dürfen (in Authentik seit 2024.2
|
||||
ein eigenes Scope-Mapping) – sonst kommt kein Refresh-Token zurück.
|
||||
|
||||
**2. `deploy/.env` ergänzen** (vollständige Vorlage in `deploy/.env.example`):
|
||||
|
||||
```bash
|
||||
PUBLIC_BASE_URL=https://vorrania.example.com
|
||||
OIDC_PROVIDERS=authentik
|
||||
OIDC_AUTHENTIK_DISPLAY_NAME=Authentik
|
||||
OIDC_AUTHENTIK_DISCOVERY_URL=https://authentik.example.com/application/o/vorrania/.well-known/openid-configuration
|
||||
OIDC_AUTHENTIK_CLIENT_ID=...
|
||||
OIDC_AUTHENTIK_CLIENT_SECRET=...
|
||||
OIDC_AUTHENTIK_NATIVE_CLIENT_IDS=vorrania-ios
|
||||
```
|
||||
|
||||
Danach `./update.sh` (oder `docker compose --env-file .env up -d`).
|
||||
Ob es geklappt hat, verrät `curl http://<server>:8080/api/auth/oidc/providers`.
|
||||
|
||||
**3. Bestehende Konten verknüpfen.** Dafür gibt es zwei Wege:
|
||||
|
||||
*Selbst verknüpfen (empfohlen).* Angemeldet bleiben, in der Seitenleiste unten
|
||||
auf den eigenen Namen klicken → **Mein Konto** → *Verknüpfen*. Das funktioniert
|
||||
für jeden Benutzer, braucht keine hinterlegte E-Mail-Adresse und keine
|
||||
Admin-Rechte: Die Berechtigung stammt aus der laufenden Sitzung. Dort lässt sich
|
||||
eine Verknüpfung auch wieder lösen – außer es wäre die letzte
|
||||
Anmeldemöglichkeit des Kontos.
|
||||
|
||||
*Über die E-Mail-Adresse.* Trage sie unter *Benutzer* ein – dieselbe wie in
|
||||
Authentik. Beim ersten SSO-Login wird das Konto dann automatisch gefunden.
|
||||
Verknüpft wird nur bei **bestätigter** Adresse.
|
||||
|
||||
Ohne eines von beidem entsteht beim ersten Anmelden ein **zweites** Konto mit
|
||||
der Rolle *Benutzer*, statt dass das bestehende übernommen wird.
|
||||
|
||||
Weitere Anbieter sind reine Konfiguration: Kürzel in `OIDC_PROVIDERS` ergänzen
|
||||
und einen zweiten Block mit dessen Präfix anlegen (`OIDC_<KÜRZEL>_…`) – am Code
|
||||
ändert sich dafür nichts.
|
||||
|
||||
### Was dabei bewusst so gebaut ist
|
||||
- Der Anmeldedienst ist **nur für die Anmeldung** zuständig. Danach stellt
|
||||
Vorrania sein eigenes Token aus, wie beim Passwort-Login – Rollen, API-Tokens
|
||||
und alle Endpunkte bleiben unverändert.
|
||||
- **Rollen kommen nie aus dem Anbieter.** Neu angelegte SSO-Konten sind immer
|
||||
*Benutzer*; Admin vergibt ein Admin von Hand.
|
||||
- **Automatisch** verknüpft wird nur bei bestätigter E-Mail-Adresse. Sonst
|
||||
könnte ein Konto im Anmeldedienst mit frei gewählter Adresse ein fremdes
|
||||
Vorrania-Konto übernehmen. Beim Verknüpfen über *Mein Konto* entfällt das,
|
||||
weil dort die eigene Sitzung bürgt – eine bereits anderweitig vergebene
|
||||
Kennung wird aber auch dort abgelehnt.
|
||||
- Die App meldet sich ausschließlich im **System-Browser** an (AppAuth mit
|
||||
PKCE), nie in einem eingebetteten WebView, und sendet nie ein Client-Secret.
|
||||
|
||||
## Aktualisieren
|
||||
```bash
|
||||
cd vorrania/deploy
|
||||
|
||||
Reference in New Issue
Block a user