Traefik und oAuth: Eigene Webservices mit Google anmelden.

 

Die Sicherheit eines Webservice ist wesentlich von dessen Benutzeranmeldung abhĂ€ngig. Sollte ein Webservice keine eigene Benutzeranmeldung besitzen, kann beim Einsatz des Traefik-Reverse Proxy einfach eine Anmeldung vorgeschaltet werden. Der Zugriff auf das eigentliche Webservice wird damit erst erlaubt, wenn die Anmeldung am Reverse Proxy erfolgreich war. Die einfachste Variante fĂŒr eine vorgeschaltete Anmeldung ist eine Basic-Authentifizierung. Etwas aufwĂ€ndiger, aber möglicherweise komfortabler und zudem meist noch sicherer ist die Verwendung von OAuth. OAuth ermöglicht das Anmelden ĂŒber einen zusĂ€tzlichen Anmeldeanbieter: Identity-Provider, kurz IDP. Einmal am IDP angemeldet, können alle Services aufgerufen werden, die den IDP verwenden. Wer als Beispiel den IDP von Google fĂŒr die OAuth-Anmeldung verwendet, kann nach einer einmaligen Anmeldung mit dem Google-Konto die Anmeldeinformationen auch fĂŒr die eigenen Webservices nutzen. 

Mit dem Google-Konto auf den eigenen Webservices anmelden

Ziel dieses Beitrags ist das Vorschalten einer Google-Anmeldung fĂŒr die eigenen Webservices: Wird als Beispiel das Traefik-Dashboard unseres Docker-Setups aufgerufen, leitet der Reverse-Proxy den Benutzer direkt auf die Google-Anmeldung um. Ist der Benutzer bereits angemeldet, können die Anmeldeinformationen verwendet werden und der Zugriff auf das Dashboard wird ohne erneuter Anmeldung erlaubt. Sollte der Benutzer noch nicht bei Google angemeldet sein, wird er aufgefordert seine Anmeldedaten einzugeben: 

ErgĂ€nzend zum Traefik-Docker-Setup wird fĂŒr das hier vorgestellte Setup ein zusĂ€tzlicher Docker-Container (traefik-forward-auth) fĂŒr das Weiterleiten der Authentifizierung an Google und ein Public-DNS-Eintrag fĂŒr die Umleitungs-URL (Redirect-URI) benötigt. Seitens Google muss im Google Developers-Portal zudem ein OAuth-Client angelegt werden.

Das Vorschalten der Google-Anmeldung zu einem Docker-Webservice kann spÀter mit einem Label zum jeweiligen Container erfolgen:

    labels:
      - "traefik.http.routers.traefik.middlewares=forward-auth-verify"

Overlay Mode vs. Auth Host Mode

Im Overlay-Mode wird fĂŒr die verwendeten Domains der Pfad /_oauth umgeleitet. Beim Einsatz mehrerer Services besitzt jede Domain damit seine eigene Redirect-URI, was zur Folge hat, dass im Google-oAuth-Client mehrere Domains hinterlegt werden mĂŒssen. (https://service1.domain.tld/_oauth, https://servic2.domain.tld/_oauth). Alternativ dazu kann der "Auth Host Mode" und eine eigene Domain verwendet werden, z. B. oauth.domain.tld. Im "Auth Host Mode" reicht es diese Domain als Redirect-URI im Google-oAuth-Client fĂŒr mehrere Services zu verwenden:

Auth Host Mode: Public-DNS fĂŒr den Container traefik-forward-auth

Der Container fĂŒr OAuth benötigt im "Auth Host Mode" einen eigenen DNS-Eintrag, laut dem folgenden Beispiel: oauth.domain.tld. Der DNS-Eintrag zeigt, wie auch bei meinen anderen Docker-Webservices, auf die Public-IP des Webservers, siehe: Domain und dessen Verwaltung.

Voraussetzung: Google oAuth-Client

Vor der Anlage eines OAuth-Clients muss zunÀchst in der Google-Developer-Konsole ein neues Projekt und der Zustimmungsbildschirm konfiguriert werden, dazu melden wir uns an der Google-Developer-Seite an: https://console.developers.google.com/

Nach der Anmeldung muss vorab ein Projekt angelegt werden:

 

  

Bevor der oAuth-Client konfugiriert werden kann, wird die Konfiguration des "Consent Screen" benötigt.

 

Als "Authorised Domain" habe ich die Domain hinterlegt ĂŒber welche die Webservices im Internet zur VerfĂŒgung gestellt werden:

  

OAuth Client anlegen:

Die Anlage des OAuth-Clients startet ĂŒber "OAuth client ID":

Wie bereits erwĂ€hnt, kann bei Verwendung des "Auth Host Mode" fĂŒr alle Subdomains der zusĂ€tzlich DNS-Eintrag fĂŒr die OAuth-Anmeldung verwendet werden. Der Standardpfad fĂŒr den Docker-Container: thomseddon/traefik-forward-auth ist "_oauth"  (Variable: - URL_PATH=_oauth)

Nach dem Erstellen des oAuth-Clients wird die Client-ID und das Client Secret ausgegeben:

Umsetzung: Traefik-Anpassung

Die eigentliche OAuth-Anmeldung findet nicht in Traefik, sondern in einem zusĂ€tzlichen Container statt. Aufbauend zum Artikel "sichere https Verbindung: Traefik Reverse Proxy + LetÂŽs Encrypt", habe ich in folgender docker-compose-yml-Datei den Docker-Container thomseddon/traefik-forward-auth hinzugefĂŒgt und die Konfiguration fĂŒr dessen Verwendung angepasst.

Datei docker-compose.yml 

[+]
services:
  traefik:
    image: "traefik:v2.8"
    container_name: "traefik"
    command:
      - "--api.dashboard=true"
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
      - "--certificatesresolvers.myresolver.acme.email=admin@domain.tld"
      - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
    expose:
      # traefik dashboard port
      - 8080
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.traefik.rule=Host(`webproxy.domain.tld`)"
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.routers.traefik.tls.certresolver=myresolver"
      - "traefik.http.routers.traefik.service=api@internal"
      - "traefik.http.routers.traefik.middlewares=forward-auth-verify"
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro" 
    restart: "always"
  traefik-forward-auth:
    image: thomseddon/traefik-forward-auth:latest
    container_name: traefik-forward-auth
    environment:
      - PROVIDERS_GOOGLE_CLIENT_ID=??FromGoogleOAuthSetup??
      - PROVIDERS_GOOGLE_CLIENT_SECRET=??FromGoogleOAuthSetup??
      - SECRET=somethingrandom
      - AUTH_HOST=oauth.domain.tld    
      - COOKIE_DOMAIN=domain.tld
      - WHITELIST=EMAIL@ALLOWED
      - INSECURE_COOKIE=false
    labels:    
      - "traefik.enable=true"
      - "traefik.http.routers.forward.rule=Host(`oauth.domain.tld`)"      
      - "traefik.http.routers.forward.entrypoints=websecure"
      - "traefik.http.routers.forward.tls.certresolver=myresolver"
      - "traefik.http.services.forward.loadbalancer.server.port=4181"
      #Middleware
      - "traefik.http.middlewares.forward-auth-verify.forwardauth.address=http://traefik-forward-auth:4181"      
      - "traefik.http.middlewares.forward-auth-verify.forwardauth.authResponseHeaders=X-Forwarded-User"
networks:
  default:
    name: webproxy
    external: true

Um die Anmeldung fĂŒr das Traefik-Dashboard von Basic-Auth auf einen anderen Anmeldeanbieter weiterzuleiten, muss lediglich das Label "traefik.http.routers.traefik.middlewares" auf "forward-auth-verify" geĂ€ndert werden. (Das ursprĂŒngliche Beispiel verwendet fĂŒr die Basic-Authentifizierung das Label: "traefik-basic-auth")

Die Middleware fĂŒr "forward-auth-verify" wird in dem Beispiel im Container: traefik-forward-auth definiert. (Kommentar "#Middleware" in der docker-compose.yml-Datei)

Der Labels des Container "traefik-forward-auth" verwendet den DNS Eintrag, hier "oauth-domain.tld". Zudem wird die DomĂ€ne in der Umgebungsvariable "AUTH-HOST" hinterlegt, wodurch das spĂ€tere Anpassen des Google-oAuth-Clients beim HinzufĂŒgen eines Containers entfĂ€llt. AUTH-HOST ĂŒbernimmt die Anmeldung fĂŒr alle Subdomains bei denen eine Google-Anmeldung verwendet werden soll (z.B.: webproxy.domain.tld, Webservice1.domain.tld, webservice2.domain.tld). Damit die Umleitung fĂŒr alle Subdomains funktioniert, muss die Variable "COOKIE_DOMAIN" mit der Domain-Zone, hier domain.tld, befĂŒllt werden. 

Die Variable "SECRET" sollte mit einem zufĂ€lligen Wert befĂŒllt werden, dieser kann zum Beispiel in Linux mit dem Befehl "openssl rand -hex 16" generiert werden.
Welchen Google-Konten der Zugriff erlaubt werden soll, kann in der Umgebungsvariable "WHITELIST" hinterlegt werden. Um mehrere Email-Adressen zu erlauben, können diese mit einem "," getrennt werden: WHITELIST=adresse1@gmail.com,adresse2@gmail.com.

Fazit

Die Verwendung eines externen Anmeldeanbieters, wie Google, bietet eine komfortable Möglichkeit die eigenen Webservices mit einer sicheren Anmeldung zu versehen. Wer im Browser ohnehin bei Google angemeldet ist, kann die eigenen Webservices ohne zusÀtzlicher Anmeldung einfach und sicher verwenden.

 

positive Bewertung({{pro_count}})
Beitrag bewerten:
{{percentage}} % positiv
negative Bewertung({{con_count}})

DANKE fĂŒr deine Bewertung!

Aktualisiert: 04.07.2023 von Bernhard | Translation English |🔔 | Kommentare:1

➚ free DynDNS Service - Zugriff bei wechselnder öffentlicher IP. | ➊ Home Server | Nextcloud Server Docker | Einrichtung +https: Let’s Encrypt [ssl] ➚

Top-Artikel in diesem Bereich


NAS selber bauen: flexibel, stromsparend und gĂŒnstig [HowTo]

Wer nach einem NAS (Network Attached Storage oder Netzwerkspeicher) fĂŒr den Heimgebrauch sucht, kommt an den Herstellern Synology und QNAP nicht vorbei. Beide Hersteller liefern kleine NAS-Komplettlösungen mit der Möglichkeit, Daten lokal oder ĂŒber das Internet zu synchronisieren und beide verlangen fĂŒr die verwendete Hardware nicht gerade wenig Geld.


Bitwarden in Docker betreiben - Setup Schritt fĂŒr Schritt

Bitwarden ist ein webbasierter Passwort-Manager, Ă€hnlich LastPass, aber Open Source und der Möglichkeit diesen selbst zu betreiben (hosten). Wie sich Bitwarden im Vergleich zu anderen Passwort-Managern einordnet, habe ich auf folgender Seite ĂŒberlegt: Passwort-Manager sicher? KeePass vs. LastPass vs. Bitwarden. Bitwarden besteht aus mehreren Services, welche ĂŒber verschiedene Container bereitgestellt werden können. Das relativ aufwĂ€ndige Setup wurde mit "Bitwarden Unified" speziell fĂŒr ein Selbs...


GĂŒnstiger und sparsamer Docker Mini Server fĂŒr zu Hause

Wer zu Hause einen kleinen Server betreiben will, benötigt dazu eine Hardware mit einem geringen Stromverbrauch und dennoch genĂŒgend Leistung. UrsprĂŒnglich verwendete ich fĂŒr den Betrieb meiner Docker-Container einen selbstgebauten NAS. Die Hardware diente als Netzwerkspeicher und gleichzeitig als Plattform fĂŒr den Betrieb meiner Docker-Container. Um das Setup zu optimieren und die beiden Aufgaben zu trennen, betriebe ich die Serverdienste auf einer eigenen Hardware. Nachdem die Daten auf einem...

Fragen / Kommentare


(sortiert nach Bewertung / Datum) [alle Kommentare(neueste zuerst)]

✍anonym
04.03.2023 22:14
Gute Anleitung fĂŒr die Registrierung einer Anwendung fĂŒr Google OAuth. Habe in meinem Artikel ĂŒber die Einrichtung von Traefik in meiner Umgebung auf Deinen Artikel verlinkt: https://technikauswahl.de/2023/03/traefik-als-reverse-proxy-fuer-home-assistant-und-weitere-dienste/

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu Mehr Details