vouch proxy
1.0.0
Eine SSO-Lösung für Nginx mit dem Modul auth_request. Vouch Proxy kann alle Ihre Websites gleichzeitig schützen.
Vouch Proxy unterstützt viele OAuth- und OIDC-Anmeldeanbieter und kann die Authentifizierung erzwingen, um...
GitHub
GitHub Enterprise
IndieAuth
Okta
Locker
ADFS
Azure AD
Alibaba / Aliyun iDaas
AWS Cognito
Zucken
Zwietracht
SecureAuth
Gitea
Schlüsselmantel
OAuth2-Serverbibliothek für PHP
HomeAssistant
OpenStax
Ory Hydra
Nextcloud
die meisten anderen OpenID Connect (OIDC)-Anbieter
Bitte teilen Sie uns mit, wenn Sie Vouch Proxy bei Ihrem bevorzugten IdP oder Ihrer bevorzugten Bibliothek bereitgestellt haben, damit wir die Liste aktualisieren können.
Wenn Vouch auf demselben Host wie der Nginx-Reverse-Proxy ausgeführt wird, sollte die Antwortzeit vom /validate -Endpunkt zu Nginx weniger als 1 ms betragen.
Was Vouch Proxy macht...
Installation und Konfiguration
Vouch Proxy „in einem Pfad“
Zusätzliche Nginx-Konfigurationen
Konfiguration über Umgebungsvariablen
Tipps, Tricks und erweiterte Konfigurationen
Geltungsbereich und Ansprüche
Wird von Docker ausgeführt
Kubernetes Nginx-Ingress
Kompilieren aus dem Quellcode und Ausführen der Binärdatei
/login- und /logout-Endpunktumleitung
Fehlerbehebung, Support und Funktionsanfragen (Lesen Sie dies, bevor Sie ein Problem bei GitHub einreichen)
Ich erhalte eine Endlosumleitungsschleife, die mich zu meinem IdP (Google/Okta/GitHub/...) zurückführt.
Okay, ich habe mir die Probleme angesehen und einige Dinge mit meinen Konfigurationen ausprobiert, aber es funktioniert immer noch nicht
Beitrag zu Vouch Proxy
Erweiterte Autorisierung mit OpenResty
Der Ablauf der Anmeldung und Authentifizierung mit Google OAuth
Vouch Proxy (VP) zwingt Besucher, sich bei einem IdP (z. B. einem der oben aufgeführten Dienste) anzumelden und zu authentifizieren, bevor ihnen der Zugriff auf eine Website gestattet wird.
VP kann auch als Single Sign On (SSO)-Lösung zum Schutz aller Webanwendungen in derselben Domäne verwendet werden.
Nachdem sich ein Besucher angemeldet hat, ermöglicht Vouch Proxy mehrere Stunden lang den Zugriff auf die geschützten Websites. Jede Anfrage wird von VP überprüft, um sicherzustellen, dass sie gültig ist.
VP kann die E-Mail-Adresse, den Namen und andere Informationen des Besuchers, die der IdP bereitstellt (einschließlich Zugriffstokens), als HTTP-Header an die Webanwendung senden. VP kann verwendet werden, um die Anwendungsbenutzerverwaltung vollständig zu ersetzen.
Vouch Proxy basiert auf der Fähigkeit, ein Cookie zwischen dem Vouch Proxy-Server und der von ihm geschützten Anwendung zu teilen. Normalerweise geschieht dies durch die Ausführung von Vouch auf einer Subdomain wie vouch.yourdomain.com wobei Apps unter app1.yourdomain.com und app2.yourdomain.com ausgeführt werden. Die geschützte Domain ist .yourdomain.com und das Vouch-Proxy-Cookie muss in dieser Domain gesetzt werden, indem vouch.domains so eingestellt wird, dass es yourdomain.com einschließt, oder manchmal auch durch Setzen von vouch.cookie.domain auf yourdomain.com .
cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml
Erstellen Sie OAuth-Anmeldeinformationen für Vouch Proxy bei Google oder Github usw
Stellen Sie sicher, dass Sie die Rückruf-URL an den Vouch-Proxy-Endpunkt /auth weiterleiten
Nginx konfigurieren...
Die folgende Nginx-Konfiguration setzt Folgendes voraus:
Nginx, vouch.yourdomain.com und protectedapp.yourdomain.com laufen auf demselben Server
Beide Domänen werden als https bereitgestellt und verfügen über gültige Zertifikate (falls nicht, wechseln Sie zu listen 80 und setzen Sie vouch.cookie.secure auf false “).
server { listen 443 ssl http2; Servername protectedapp.yourdomain.com; root /var/www/html/; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # alle Anfragen zur Autorisierung an den „/validate“-Endpunkt senden auth_request /validate; location = /validate { # Leiten Sie die /validate-Anfrage an Vouch Proxy weiter. Proxy_pass http://127.0.0.1:9090/validate; # Stellen Sie sicher, dass Sie den ursprünglichen Host-Header übergeben. Proxy_set_header Host $http_host; # Vouch Proxy wirkt nur auf die Anforderungsheader. Proxy_pass_request_body off; Proxy_set_header Inhaltslänge „“; # optional X-Vouch-User hinzufügen, wie von Vouch Proxy zurückgegeben, zusammen mit der Anfrage auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # optional X-Vouch-IdP-Claims-* benutzerdefinierte Ansprüche hinzufügen, die Sie verfolgen # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name; # optional X-Vouch-IdP-AccessToken oder X-Vouch-IdP-IdToken hinzufügen # auth_request_set $auth_resp_x_vouch_idp_accesstoken $upstream_http_x_vouch_idp_accesstoken; # auth_request_set $auth_resp_x_vouch_idp_idtoken $upstream_http_x_vouch_idp_idtoken; # diese Rückgabewerte werden vom @error401-Aufruf auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt verwendet; auth_request_set $auth_resp_err $upstream_http_x_vouch_err; auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # Vouch Proxy kann hinter demselben Nginx-Reverse-Proxy ausgeführt werden. # Möglicherweise muss die Benennung des „Upstream“-Servers eingehalten werden. # Proxy_pass http://vouch.yourdomain.com/validate; # Proxy_set_header Host $http_host;
} # Wenn Validierung „401 nicht autorisiert“ zurückgibt, dann leiten Sie die Anfrage an den Fehler401block weiter. error_page 401 = @error401; location @error401 { # Weiterleitung an Vouch Proxy für Login return 302 https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err; # Normalerweise *möchten* Sie zu Vouch umleiten, das hinter derselben Nginx-Konfiguration läuft, die durch https geschützt ist. # Aber um zu beginnen, können Sie den Endbenutzer einfach an den Port weiterleiten, auf dem Vouch ausgeführt wird. # Rückkehr 302 http://vouch.yourdomain.com:9090/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$auth_resp_err;
} location / { # Autorisierte Anfragen an Ihren Dienst weiterleiten protectedapp.yourdomain.com Proxy_pass http://127.0.0.1:8080; # Möglicherweise müssen Sie diese Variablen in diesem Block gemäß https://github.com/vouch/vouch-proxy/issues/26#issuecomment-425215810 festlegen. # auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user # auth_request_set $auth_resp_x_vouch_idp_claims_groups $upstream_http_x_vouch_idp_claims_groups; # auth_request_set $auth_resp_x_vouch_idp_claims_given_name $upstream_http_x_vouch_idp_claims_given_name; # Benutzer-Header festlegen (normalerweise eine E-Mail) Proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # Übergeben Sie optional alle benutzerdefinierten Ansprüche, die Sie verfolgen. # Proxy_set_header X-Vouch-IdP-Claims-Groups $auth_resp_x_vouch_idp_claims_groups; # Proxy_set_header X-Vouch-IdP-Claims-Given_Name $auth_resp_x_vouch_idp_claims_given_name; # optional das Accesstoken oder das IDtoken übergeben # Proxy_set_header X-Vouch-IdP-AccessToken $auth_resp_x_vouch_idp_accesstoken; # Proxy_set_header X-Vouch-IdP-IdToken $auth_resp_x_vouch_idp_idtoken;
}
} Wenn Vouch hinter demselben Nginx-Reverseproxy konfiguriert ist (vielleicht, damit Sie SSL konfigurieren können), stellen Sie sicher, dass Sie den Host Header ordnungsgemäß übergeben, da sonst das JWT-Cookie nicht in der Domäne gesetzt werden kann
server { listen 443 ssl http2; Servername vouch.yourdomain.com; ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem; Standort / { Proxy_pass http://127.0.0.1:9090; # Stellen Sie sicher, dass Sie den ursprünglichen Host-Header übergeben. Proxy_set_header Host $http_host;
}
} Ab v0.33.0 kann Vouch Proxy innerhalb eines Nginx-Speicherorts (Pfads) bereitgestellt werden, indem vouch.document_root: /vp_in_a_path konfiguriert wird
Dadurch entfällt die Notwendigkeit, eine separate Domäne für Vouch Proxy einzurichten, z. B. vouch.yourdomain.com . Beispielsweise wird die VP-Anmeldung über https://protectedapp.yourdomain.com/vp_in_a_path/login bereitgestellt
server { listen 443 ssl http2; Servername protectedapp.yourdomain.com; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # Dieser Standort bedient alle Vouch-Proxy-Endpunkte als /vp_in_a_path/$uri # einschließlich /vp_in_a_path/validate, /vp_in_a_path/login, /vp_in_a_path/logout, /vp_in_a_path/auth, /vp_in_a_path/auth/$STATE usw. Standort /vp_in_a_path { Proxy_Pass http://127.0.0.1:9090; # darf nicht! haben Sie einen Schrägstrich am Ende. Proxy_set_header Host $http_host; Proxy_pass_request_body aus; Proxy_set_header Inhaltslänge „“; # diese Rückgabewerte werden vom @error401-Aufruf auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt verwendet; auth_request_set $auth_resp_err $upstream_http_x_vouch_err; auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount;
} # Wenn /vp_in_a_path/validate „401 nicht autorisiert“ zurückgibt, dann leiten Sie die Anfrage an den error401block weiter. error_page 401 = @error401; location @error401 { # Weiterleitung an Vouch Proxy für Login Return 302 https://protectedapp.yourdomain.com/vp_in_a_path/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error =$auth_resp_err;
} location / { auth_request /vp_in_a_path/validate; Proxy_Pass http://127.0.0.1:8080; # Weitere Header, die über Vouch Proxy festgelegt werden können, finden Sie in der Nginx-Konfiguration oben
}
}Weitere Nginx-Konfigurationen finden Sie im Beispielverzeichnis.
Hier ist eine minimale Einrichtung mit Googles OAuth ...
VOUCH_DOMAINS=IhreDomain.com OAUTH_PROVIDER=google OAUTH_CLIENT_ID=1234 OAUTH_CLIENT_SECRET=geheimgeheim OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth ./vouch-proxy
Umgebungsvariablennamen sind in config/config.yml_example dokumentiert
Alle Listen mit mehreren Werten müssen durch Kommas getrennt werden: VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"
Die Variable VOUCH_CONFIG kann verwendet werden, um einen alternativen Speicherort für die Konfigurationsdatei festzulegen. VOUCH_ROOT kann verwendet werden, um ein alternatives Stammverzeichnis für Vouch Proxy festzulegen, um nach Unterstützungsdateien zu suchen.
Alle Vouch Proxy-Konfigurationselemente sind in config/config.yml_example dokumentiert
Zwischenspeichern der Vouch-Proxy- /validate in Nginx
Verarbeiten von OPTIONS -Anfragen beim Schutz einer API mit Vouch Proxy
Validierung durch GitHub Team oder GitHub Org
Ausführen von VP auf einem Raspberry Pi mit dem ARM-basierten Docker-Image
Post-Ingress der Kubernetes-Architektur
Legen Sie HTTP_PROXY fest, um Vouch-Proxy-IdP-Anfragen über einen ausgehenden Proxyserver weiterzuleiten
Reverse Proxy für Google Cloud Run Services
Aktivieren Sie natives TLS in Vouch Proxy
FreeBSD-Unterstützung
systemd Start von Vouch Proxy
Verwenden von Node.js anstelle von Nginx zum Weiterleiten von Anforderungen
Entwickeln einer Single Page App (SPA) unter Nutzung einer VP-geschützten API
Integrieren Sie Vouch Proxy in eine serverseitige Anwendung für Benutzerauthentifizierung und -authentifizierung
Filtern Sie vor der VP-Validierung nach IP-Adresse, indem Sie satisfy any;
Bitte helfen Sie uns, diese Liste zu erweitern.
Mit Vouch Proxy können Sie verschiedene scopes (Standard und benutzerdefiniert) anfordern, um weitere Informationen über den Benutzer zu erhalten oder Zugriff auf die APIs des Anbieters zu erhalten. Intern startet Vouch Proxy nach erfolgreicher Authentifizierung eine Anfrage an user_info_url . Die erforderlichen claims werden aus der Antwort des Anbieters extrahiert und im VP-Cookie gespeichert.
Das VP-Cookie kann in mehrere Cookies aufgeteilt werden, um den Browser-Cookie-Größenbeschränkungen gerecht zu werden. Aber wenn Sie es brauchen, brauchen Sie es. Für große Cookies und Header muss Nginx mit größeren Puffern konfiguriert werden. Weitere Informationen finden Sie unter „large_client_header_buffers“ und „proxy_buffer_size“.
scopes und claims in Vouch Proxy mit Nginx einKonfigurieren Sie Vouch Proxy für Nginx und Ihren IdP wie gewohnt (siehe: Installation und Konfiguration)
Legen Sie die erforderlichen scope im oauth Abschnitt der vouch-proxy config.yml fest (Beispielkonfiguration).
Setzen Sie idtoken: X-Vouch-IdP-IdToken im headers -Abschnitt der config.yml von vouch-proxy
Melden Sie sich an und rufen Sie den Endpunkt /validate in einem modernen Browser auf
Überprüfen Sie den Antwortheader auf einen X-Vouch-IdP-IdToken Header
Kopieren Sie den Wert des Headers in den Debugger unter https://jwt.io/ und stellen Sie sicher, dass die erforderlichen Ansprüche Teil des JWT sind
Ist dies nicht der Fall, müssen Sie die scopes im oauth Abschnitt Ihrer config.yml anpassen oder Ihren OAuth-Anbieter neu konfigurieren
Legen Sie die erforderlichen claims im header Abschnitt der vouch-proxy config.yml fest
Melden Sie sich an und rufen Sie den Endpunkt /validate in einem modernen Browser auf
Überprüfen Sie die Antwortheader auf Header der Form X-Vouch-IdP-Claims-<ClaimName>
Wenn sie nicht vorhanden sind, löschen Sie Ihre Cookies und zwischengespeicherten Browserdaten
? Wenn sie immer noch nicht vorhanden sind, aber im JWT vorhanden sind (insbesondere benutzerdefinierte Ansprüche), liegt möglicherweise ein Fehler vor
Entfernen Sie das idtoken: X-Vouch-IdP-IdToken aus dem headers -Abschnitt der config.yml von vouch-proxy, wenn Sie es nicht benötigen
Verwenden Sie auth_request_set nach auth_request innerhalb des geschützten Speicherorts in der Nginx server.conf
Verbrauchen Sie den Anspruch (Beispiel für eine Nginx-Konfiguration).
Docker run -d
-p 9090:9090
--name Vouch-Proxy
-v ${PWD}/config:/config
quay.io/vouch/vouch-proxyoder
Docker run -d
-p 9090:9090
--name Vouch-Proxy
-e VOUCH_DOMAINS=IhreDomain.com
-e OAUTH_PROVIDER=google
-e OAUTH_CLIENT_ID=1234
-e OAUTH_CLIENT_SECRET=geheimnisgeheim
-e OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth
quay.io/vouch/vouch-proxy Ab v0.36.0 wird der Docker-Prozess im Container als Benutzer vouch mit UID 999 und GID 999 ausgeführt. Möglicherweise müssen Sie die Berechtigungen von /config/config.yml und /config/secret so einstellen, dass sie für diesen Benutzer lesbar sind. oder verwenden Sie andernfalls docker run --user $UID:$GID ... oder erstellen Sie den Docker-Container möglicherweise aus der Quelle und verwenden Sie die verfügbaren ARGs für UID und GID.
Automatisierte Container-Builds für jede Vouch Proxy-Version sind auf quay.io verfügbar. Jede Veröffentlichung produziert..
ein minimaler Go-Binärcontainer, der aus Dockerfile erstellt wurde
quay.io/vouch/vouch-proxy:latest
quay.io/vouch/vouch-proxy:xyz wie quay.io/vouch/vouch-proxy:0.28.0
ein alpine basierender Container, der aus Dockerfile.alpine erstellt wurde
quay.io/vouch/vouch-proxy:alpine-latest
quay.io/vouch/vouch-proxy:alpine-xyz
Vouch-Proxy- arm Bilder sind auf Docker Hub verfügbar
voucher/vouch-proxy:latest-arm
Wenn Sie Kubernetes mit Nginx-Ingress verwenden, können Sie Ihren Ingress mit den folgenden Annotationen konfigurieren (beachten Sie die Angabe der Annotation auth-signin ):
nginx.ingress.kubernetes.io/auth-signin: „https://vouch.yourdomain.com/login?url=$scheme://$http_host$request_uri&vouch-failcount=$auth_resp_failcount&X-Vouch-Token=$auth_resp_jwt&error=$ auth_resp_err"
nginx.ingress.kubernetes.io/auth-url: https://vouch.yourdomain.com/validate
nginx.ingress.kubernetes.io/auth-response-headers: X-Vouch-Benutzer
nginx.ingress.kubernetes.io/auth-snippet: | # Diese Rückgabewerte werden vom @error401-Aufruf verwendet
auth_request_set $auth_resp_jwt $upstream_http_x_vouch_jwt;
auth_request_set $auth_resp_err $upstream_http_x_vouch_err;
auth_request_set $auth_resp_failcount $upstream_http_x_vouch_failcount; # Wenn VP extern auf k8s gehostet wird, stellen Sie sicher, dass das SSL-Zertifikat gültig ist, um MITM-Risiko zu vermeiden # Proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; # Proxy_ssl_session_reuse on; # Proxy_ssl_verify_ Depth 2; # Proxy_ssl_verify on;Helm Charts werden von Punkle, Martina-If und Halkeye verwaltet und sind unter https://github.com/vouch/helm-charts verfügbar
./do.sh goget ./do.sh bauen ./vouch-proxy
Ab v0.29.0 werden alle Vorlagen, statischen Assets und Konfigurationsvorgaben in .defaults.yml mithilfe von go:embed-Anweisungen in die statische Binärdatei integriert.
Ab v0.11.0 sind zusätzliche Prüfungen vorhanden, um die Angriffsfläche der URL-Umleitung zu verringern.
Die übergebene URL...
muss entweder mit http oder https beginnen
Es muss eine Domänenüberschneidung mit einer Domäne in der vouch.domains -Liste oder der vouch.cookie.domain (falls eine dieser Domänen konfiguriert ist) geben.
Es darf kein Parameter vorhanden sein, der eine URL enthält, um URL-Verkettungsangriffe zu verhindern
Der Vouch-Proxy- /logout Endpunkt akzeptiert einen url Parameter in der Abfragezeichenfolge, der verwendet werden kann, um einen Benutzer 302 zum revocation_endpoint Ihres ursprünglichen OAuth-Anbieters/IDP/OIDC-Anbieters umzuleiten
https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoke
Diese URL muss in der Konfigurationsdatei in der Liste vouch.post_logout_redirect_uris vorhanden sein
# Um Umleitungsangriffe zu verhindern, müssen alle umgeleiteten URLs zu /logout angegeben werden. # Die URL muss weiterhin als https://vouch.yourdomain.com/logout?url=${EINE DER UNTENSTEHENDEN URLS}post_logout_redirect_uris an Vouch Proxy übergeben werden : # Ihre Apps-Anmeldeseite
- https://yourdomain.com/login # Ihre IdPs melden sich mit Enpoint # von https://accounts.google.com/.well-known/openid-configuration ab
- https://oauth2.googleapis.com/revoke # Möglicherweise führen Sie eine Daisy-Chaining-Verbindung zu Ihrem IdP durch
- https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login Beachten Sie, dass Ihr IdP wahrscheinlich über eine eigene, separate post_logout_redirect_uri -Liste verfügt.
Abmelderessourcen..
Okta
Auth0
Es kann schwierig sein, die Sterne zwischen Nginx, Vouch Proxy und Ihrem IdP in Einklang zu bringen. Wir möchten Ihnen dabei helfen, so schnell wie möglich einsatzbereit zu sein. Das häufigste Problem ist...
Überprüfen Sie noch einmal, ob Sie Vouch Proxy und Ihre Apps auf einer gemeinsamen Domäne ausführen, die Cookies teilen kann. Beispielsweise können vouch.yourdomain.com und app.yourdomain.com Cookies auf der Domain .yourdomain.com teilen. (Es funktioniert nicht, wenn Sie versuchen, vouch.yourdomain.org und app.yourdomain.net zu verwenden.)
Möglicherweise müssen Sie die Domäne, auf der das Cookie gesetzt werden soll, explizit definieren. Sie können dies in der Konfigurationsdatei tun, indem Sie die Option festlegen:
vouch: cookie: # erzwingen, dass die Domäne des Cookies festgelegt wird: Domäne: yourdomain.com
Wenn weiterhin Probleme auftreten, versuchen Sie Folgendes:
vouch.testing: true . Dadurch wird die Schleife verlangsamt.
set vouch.logLevel: debug .
Der Host: -Header in der http-Anfrage, die oauth.callback_url und die konfigurierten vouch.domains müssen alle übereinstimmen, damit das Cookie, das das JWT trägt, ordnungsgemäß im Browser platziert und dann bei jeder Anfrage zurückgegeben werden kann
Es hilft , wie ein Keks zu denken .
Ein Cookie wird in einer Domain gesetzt. Wenn Sie siteA.yourdomain.com und siteB.yourdomain.com durch Vouch Proxy geschützt haben, möchten Sie, dass das Vouch Proxy-Cookie in .yourdomain.com gesetzt wird
Wenn Sie sich bei vouch.yourdomain.com authentifizieren, kann das Cookie von dev.anythingelse.com nicht gesehen werden
Sofern Sie nicht https verwenden, sollten Sie vouch.cookie.secure: false festlegen
Cookies sind für alle Ports einer Domain verfügbar
Bitte sehen Sie sich die geschlossenen Probleme an, in denen die Umleitung erwähnt wird
Bitte reichen Sie eine neue Ausgabe wie folgt ein.
TLDR:
set vouch.testing: true
set vouch.logLevel: debug
Führen Sie zwei vollständige Roundtrips von ./vouch-proxy durch, um die Ausgabe zu erfassen.
VP-Startup
/validate
/login – auch wenn der Fehler hier ist
/auth
/validate – alles erfassen
Fassen Sie alle Ihre Protokolle und Konfigurationen in einem gist zusammen.
./do.sh bug_report ist dein Freund
Aktivieren Sie vouch.testing: true und legen Sie vouch.logLevel: debug fest.
Verwenden Sie einen Gist oder einen anderen Einfügedienst wie hasteb.in. Geben Sie Ihre Protokolle und Konfigurationen nicht in die Github-Ausgabe ein . Die Verwendung eines Einfügedienstes ist wichtig, da dieser den Abstand beibehält und Zeilennummern und Formatierungen bereitstellt. Wir sind auf der Suche nach Nadeln im Heuhaufen mit Setups mit mehreren beweglichen Teilen, diese Funktionen helfen erheblich. Einklebedienste sparen Ihre und unsere Zeit und helfen uns, Ihnen schnell zu helfen. Wenn Sie diesen Rat befolgen, ist es wahrscheinlicher, dass Sie zeitnah gute Unterstützung von uns erhalten.
Führen Sie ./do.sh bug_report secretdomain.com secretpass [anothersecret..] aus, wodurch eine redigierte Version Ihrer Konfiguration erstellt und das Entfernen jeder dieser Zeichenfolgen protokolliert wird
und befolgen Sie die Anweisungen am Ende, um Ihre Nginx-Konfiguration zu redigieren
all das geht auf das Wesentliche ein
Öffnen Sie dann ein neues Problem in diesem Repository
Ein Fehlerbericht kann aus einer Docker-Umgebung mit dem Bild quay.io/vouch/vouch-proxy:alpine generiert werden...
docker run --name vouch_proxy -v $PWD/config:/config -v $PWD/certs:/certs -it --rm --entrypoint /do.sh quay.io/vouch/vouch-proxy:alpine bug_report yourdomain.com anotherdomain.com someothersecretWir würden uns über Ihren Beitrag freuen! Einzelheiten entnehmen Sie bitte unseren Beitragsrichtlinien.
OpenResty® ist eine vollwertige Webplattform, die den Standard-Nginx-Kern LuaJIT, viele sorgfältig geschriebene Lua-Bibliotheken, viele hochwertige Nginx-Module von Drittanbietern und die meisten ihrer externen Abhängigkeiten integriert.
Sie können Nginx ziemlich einfach durch OpenResty ersetzen.
Mit OpenResty und Lua ist es möglich, eine individuelle und erweiterte Autorisierung für alle weitergegebenen Header- oder Schadensnachweise bereitzustellen.
OpenResty und Konfigurationen für verschiedene Szenarien sind im Beispielverzeichnis verfügbar.
Bob besucht https://private.oursites.com
der Nginx-Reverse-Proxy...
wenn /validate zurückgibt...
Antworten Sie Bob mit einer 302-Weiterleitung zu https://vouch.oursites.com/login?url=https://private.oursites.com
200 OK, dann ERFOLGREICH, lassen Sie Bob durch
401 NotAuthorized dann
erhält die Anfrage für private.oursites.com von Bob
verwendet das für den /validate -Pfad konfigurierte auth_request Modul
/validate ist so konfiguriert, dass Anfragen proxy_pass an den Authentifizierungsdienst unter https://vouch.oursites.com/validate weitergeleitet werden
Gutschein-Proxy https://vouch.oursites.com/validate
Geben Sie 401 NotAuthorized an Nginx zurück (das die Anfrage an die Anmeldung weiterleitet).
gibt 200 OK an Nginx zurück, was den Zugriff ermöglicht (Bob bemerkt nichts)
Erhält die Anfrage für private.oursites.com von Bob über Nginx proxy_pass
sucht nach einem Cookie namens „oursitesSSO“, das ein JWT enthält
wenn das Cookie gefunden wird und das JWT gültig ist
wenn das Cookie NICHT gefunden wird oder das JWT NICHT gültig ist
Bob wird zunächst kurz zu https://vouch.oursites.com/login?url=https://private.oursites.com weitergeleitet
löscht das Cookie mit dem Namen „oursitesSSO“, falls vorhanden
generiert eine Nonce und speichert sie in der Sitzungsvariablen $STATE
speichert die URL https://private.oursites.com aus der Abfragezeichenfolge in der Sitzungsvariablen $requestedURL
Antworten Sie Bob mit einer 302-Weiterleitung zum OAuth-Anmeldeformular von Google, einschließlich der $STATE Nonce
Bob meldet sich mit OAuth bei seinem Google-Konto an
nach erfolgreicher Anmeldung
Google antwortet Bob mit einer 302-Weiterleitung zu https://vouch.oursites.com/auth?state=$STATE
Bob wird zu https://vouch.oursites.com/auth?state=$STATE weitergeleitet
Geben Sie Bob ein JWT in Form eines Cookies mit dem Namen „oursitesSSO“ aus.
Rufen Sie die Sitzungsvariable $requestedURL ab und 302 leiten Sie Bob zurück zu https://private.oursites.com
wenn die $STATE-Nonce aus der URL mit der Sitzungsvariablen „state“ übereinstimmt
Stellen Sie eine „dritte Bein“-Anfrage an Google (von Server zu Server), um den OAuth-Code für Bobs Benutzerinformationen, einschließlich der E-Mail-Adresse [email protected], auszutauschen
wenn die E-Mail-Adresse mit der Domain oursites.com übereinstimmt (das stimmt)
Beachten Sie, dass Bob abgesehen von einer harmlosen Weiterleitung immer nur https://private.oursites.com und den Google-Anmeldebildschirm in seinem Browser sieht. Obwohl Vouch mehrmals mit Bobs Browser interagiert, dient dies lediglich dem Setzen von Cookies. Wenn die 302-Weiterleitungen ordnungsgemäß funktionieren, meldet sich Bob schnell an.
Sobald das JWT festgelegt ist, wird Bob für alle anderen Websites autorisiert, die für die Verwendung von https://vouch.oursites.com/validate aus dem Nginx-Modul auth_request konfiguriert sind.
Wenn Bob das nächste Mal zur Anmeldung an Google weitergeleitet wird, da er die Vouch Proxy OAuth-App bereits autorisiert hat, leitet Google ihn sofort zurück, setzt das Cookie und schickt ihn fröhlich auf die Reise. In einigen Browsern wie Chrome bemerkt Bob möglicherweise nicht einmal, dass er sich mit Vouch Proxy angemeldet hat.
