vouch proxy
1.0.0
Une solution SSO pour Nginx utilisant le module auth_request. Vouch Proxy peut protéger tous vos sites Web en même temps.
Vouch Proxy prend en charge de nombreux fournisseurs de connexion OAuth et OIDC et peut appliquer l'authentification pour...
GitHub
GitHub Entreprise
IndépendantAuth
Okta
Mou
ADFS
Azure AD
Alibaba / Aliyun iDaas
AWS Cognito
Tic
Discorde
Authentification sécurisée
Gitéa
Porte-clés
Bibliothèque de serveur OAuth2 pour PHP
Assistante à domicile
OuvrirStax
Ory Hydra
Suivantcloud
la plupart des autres fournisseurs OpenID Connect (OIDC)
Veuillez nous informer lorsque vous avez déployé Vouch Proxy avec votre IdP ou votre bibliothèque préférée afin que nous puissions mettre à jour la liste.
Si Vouch s'exécute sur le même hôte que le proxy inverse Nginx, le temps de réponse du point de terminaison /validate vers Nginx doit être inférieur à 1 ms .
Que fait le proxy garant...
Installation et configuration
Garantir Proxy "dans un chemin"
Configurations Nginx supplémentaires
Configuration via des variables environnementales
Trucs, astuces et configurations avancées
Portées et réclamations
Exécuter depuis Docker
Entrée Kubernetes Nginx
Compiler à partir des sources et exécuter le binaire
Redirection des points de terminaison /login et /logout
Dépannage, assistance et demandes de fonctionnalités (lisez ceci avant de soumettre un problème sur GitHub)
Je reçois une boucle de redirection infinie qui me renvoie à mon IdP (Google/Okta/GitHub/...)
D'accord, j'ai regardé les problèmes et essayé quelques choses avec mes configurations mais ça ne fonctionne toujours pas
Contribuer à Vouch Proxy
Autorisation avancée à l'aide d'OpenResty
Le flux de connexion et d'authentification à l'aide de Google Oauth
Vouch Proxy (VP) oblige les visiteurs à se connecter et à s'authentifier auprès d'un IdP (tel que l'un des services répertoriés ci-dessus) avant de leur permettre d'accéder à un site Web.
VP peut également être utilisé comme solution d'authentification unique (SSO) pour protéger toutes les applications Web du même domaine.
Une fois qu'un visiteur s'est connecté, Vouch Proxy permet d'accéder aux sites Web protégés pendant plusieurs heures. Chaque demande est vérifiée par VP pour s'assurer qu'elle est valide.
VP peut envoyer l'e-mail du visiteur, son nom et d'autres informations fournies par l'IdP (y compris les jetons d'accès) à l'application Web sous forme d'en-têtes HTTP. VP peut être utilisé pour remplacer entièrement la gestion des utilisateurs des applications.
Vouch Proxy repose sur la possibilité de partager un cookie entre le serveur Vouch Proxy et l'application qu'il protège. Généralement, cela se fera en exécutant Vouch sur un sous-domaine tel que vouch.yourdomain.com avec des applications exécutées sur app1.yourdomain.com et app2.yourdomain.com . Le domaine protégé est .yourdomain.com et le cookie Vouch Proxy doit être défini dans ce domaine en définissant vouch.domains pour inclure yourdomain.com ou parfois en définissant vouch.cookie.domain sur yourdomain.com .
cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml
créer des informations d'identification OAuth pour Vouch Proxy sur Google ou github, etc.
assurez-vous de diriger l'URL de rappel vers le point de terminaison Vouch Proxy /auth
configurer Nginx...
La configuration Nginx suivante suppose...
Nginx, vouch.yourdomain.com et protectedapp.yourdomain.com fonctionnent sur le même serveur
les deux domaines sont servis en https et ont des certificats valides (sinon, changez pour listen 80 et définissez vouch.cookie.secure sur false )
serveur {écouter 443 ssl http2 ; nom_serveur protectedapp.votredomaine.com ; racine /var/www/html/; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem ; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem ; # envoyer toutes les requêtes au point de terminaison `/validate` pour autorisation auth_request /validate ; location = /validate { # transmettre la requête /validate à Vouch Proxy proxy_pass http://127.0.0.1:9090/validate ; # assurez-vous de transmettre l'en-tête d'hôte d'origine proxy_set_header Host $http_host; # Vouch Proxy n'agit que sur les en-têtes de requête proxy_pass_request_body off; proxy_set_header Longueur de contenu "" ; # ajoutez éventuellement X-Vouch-User tel que renvoyé par Vouch Proxy avec la requête auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user ; # ajoutez éventuellement les revendications personnalisées X-Vouch-IdP-Claims-* que vous suivez # 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; # ajouter facultativement X-Vouch-IdP-AccessToken ou X-Vouch-IdP-IdToken # 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; # ces valeurs de retour sont utilisées par l'appel @error401 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; # Vouch Proxy peut fonctionner derrière le même proxy inverse Nginx # peut devoir se conformer au nom du serveur "en amont" # proxy_pass http://vouch.yourdomain.com/validate ; # proxy_set_header Hôte $http_host ;
} # si la validation renvoie « 401 non autorisé », alors transmettez la demande au bloc d'erreurs401 error_page 401 = @error401 ; location @error401 { # rediriger vers Vouch Proxy pour la connexion 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; # vous *voulez* généralement rediriger vers Vouch exécuté derrière la même configuration Nginx protégée par https # mais pour commencer, vous pouvez simplement rediriger l'utilisateur final vers le port sur lequel Vouch s'exécute # return 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;
} emplacement / { # transférer les demandes autorisées vers votre service protectedapp.yourdomain.com proxy_pass http://127.0.0.1:8080 ; # vous devrez peut-être définir ces variables dans ce bloc selon https://github.com/vouch/vouch-proxy/issues/26#issuecomment-425215810 # 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; # définir l'en-tête de l'utilisateur (généralement un e-mail) proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # transmettez éventuellement toutes les revendications personnalisées que vous suivez # 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; # éventuellement transmettre le jeton d'accès ou le jeton d'identification # 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;
}
} Si Vouch est configuré derrière le même proxy inverse nginx (peut-être pour que vous puissiez configurer SSL), assurez-vous de transmettre correctement l'en-tête Host , sinon le cookie JWT ne peut pas être défini dans le domaine.
serveur {écouter 443 ssl http2 ; nom_serveur garant.votredomaine.com ; ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem ; ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem ; emplacement / { proxy_pass http://127.0.0.1:9090 ; # assurez-vous de transmettre l'en-tête d'hôte d'origine proxy_set_header Host $http_host;
}
} À partir de v0.33.0 Vouch Proxy peut être servi dans un emplacement Nginx (chemin) en configurant vouch.document_root: /vp_in_a_path
Cela évite d'avoir à configurer un domaine distinct pour Vouch Proxy tel que vouch.yourdomain.com . Par exemple, la connexion VP sera servie depuis https://protectedapp.yourdomain.com/vp_in_a_path/login
serveur {écouter 443 ssl http2 ; nom_serveur protectedapp.votredomaine.com ; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem ; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem ; # Cet emplacement sert tous les points de terminaison Vouch Proxy en tant que /vp_in_a_path/$uri # y compris /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, etc. location /vp_in_a_path { proxy_pass http://127.0.0.1:9090 ; # il ne faut pas ! avoir une barre oblique à la fin proxy_set_header Host $http_host ; proxy_pass_request_body désactivé ; proxy_set_header Longueur de contenu "" ; # ces valeurs de retour sont utilisées par l'appel @error401 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;
} # si /vp_in_a_path/validate renvoie « 401 non autorisé », alors transmettez la demande au bloc d'erreurs error401 error_page 401 = @error401 ; location @error401 { # rediriger vers Vouch Proxy pour la connexion 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;
} emplacement / { auth_request /vp_in_a_path/validate ; proxy_pass http://127.0.0.1:8080 ; # voir la configuration Nginx ci-dessus pour les en-têtes supplémentaires qui peuvent être définis à partir de Vouch Proxy
}
}Des configurations Nginx supplémentaires peuvent être trouvées dans le répertoire des exemples.
Voici une configuration minimale utilisant OAuth de Google...
VOUCH_DOMAINS=votredomaine.com OAUTH_PROVIDER=google OAUTH_CLIENT_ID=1234 OAUTH_CLIENT_SECRET=secretsecret OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth ./vouche-proxy
Les noms des variables d'environnement sont documentés dans config/config.yml_example
Toutes les listes comportant plusieurs valeurs doivent être séparées par des virgules : VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"
La variable VOUCH_CONFIG peut être utilisée pour définir un autre emplacement pour le fichier de configuration. VOUCH_ROOT peut être utilisé pour définir un répertoire racine alternatif pour que Vouch Proxy recherche les fichiers de support.
Tous les éléments de configuration de Vouch Proxy sont documentés dans config/config.yml_example
Mise en cache de la réponse Vouch Proxy /validate dans Nginx
Gestion des requêtes OPTIONS lors de la protection d'une API avec Vouch Proxy
Validation par l'équipe GitHub ou GitHub Org
Exécuter VP sur un Raspberry Pi à l'aide de l'image Docker basée sur ARM
Entrée après l'architecture Kubernetes
définir HTTP_PROXY pour relayer les requêtes Vouch Proxy IdP via un serveur proxy sortant
Proxy inverse pour les services Google Cloud Run
Activer TLS natif dans Vouch Proxy
Prise en charge de FreeBSD
démarrage systemd de Vouch Proxy
Utiliser Node.js au lieu de Nginx pour acheminer les requêtes
Développer une application à page unique (SPA) tout en consommant une API protégée par VP
Intégrez Vouch Proxy dans une application côté serveur pour User Authn et Authz
Filtrer par adresse IP avant la validation du VP en utilisant satisfy any;
S'il vous plaît, aidez-nous à élargir cette liste.
Avec Vouch Proxy, vous pouvez demander différentes scopes (standard et personnalisées) pour obtenir plus d'informations sur l'utilisateur ou accéder aux API du fournisseur. En interne, Vouch Proxy lance une requête vers user_info_url après une authentification réussie. Les claims requises sont extraites de la réponse du fournisseur et stockées dans le cookie VP.
Le cookie VP peut être divisé en plusieurs cookies pour respecter les limites de taille des cookies du navigateur. Mais si vous en avez besoin, vous en avez besoin. Les cookies et en-têtes volumineux nécessitent que Nginx soit configuré avec des tampons plus grands. Voir large_client_header_buffers et proxy_buffer_size pour plus d'informations.
scopes et claims dans Vouch Proxy avec NginxConfigurez Vouch Proxy pour Nginx et votre IdP comme d'habitude (voir : Installation et configuration)
Définissez les scope nécessaires dans la section oauth du vouch-proxy config.yml (exemple de configuration)
définissez idtoken: X-Vouch-IdP-IdToken dans la section headers du config.yml de vouch-proxy
connectez-vous et appelez le point de terminaison /validate dans un navigateur moderne
vérifiez l'en-tête de réponse pour un en-tête X-Vouch-IdP-IdToken
copiez la valeur de l'en-tête dans le débogueur sur https://jwt.io/ et assurez-vous que les revendications nécessaires font partie du jwt
si ce n'est pas le cas, vous devez ajuster les scopes dans la section oauth de votre config.yml ou reconfigurer votre fournisseur oauth
Définissez les claims nécessaires dans la section header du fichier vouch-proxy config.yml
connectez-vous et appelez le point de terminaison /validate dans un navigateur moderne
vérifiez les en-têtes de réponse pour les en-têtes du formulaire X-Vouch-IdP-Claims-<ClaimName>
S'ils ne sont pas là, effacez vos cookies et les données de navigateur mises en cache
? S'ils ne sont toujours pas là mais existent dans le jwt (en particulier les revendications personnalisées), il pourrait y avoir un bug
supprimez l' idtoken: X-Vouch-IdP-IdToken de la section des headers du config.yml de vouch-proxy si vous n'en avez pas besoin
Utilisez auth_request_set après auth_request à l'intérieur de l'emplacement protégé dans le server.conf nginx.conf
Consommer la revendication (exemple de configuration nginx)
Docker exécuter -d
-p 9090:9090
--name garant-proxy
-v ${PWD}/config:/config
quay.io/vouch/vouch-proxyou
Docker exécuter -d
-p 9090:9090
--name garant-proxy
-e VOUCH_DOMAINS=votredomaine.com
-e OAUTH_PROVIDER=google
-e OAUTH_CLIENT_ID=1234
-e OAUTH_CLIENT_SECRET=secretsecret
-e OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth
quay.io/vouch/vouch-proxy À partir de v0.36.0 le processus Docker dans le conteneur s'exécute en tant que vouch d'utilisateur avec l'UID 999 et le GID 999. Vous devrez peut-être définir les autorisations de /config/config.yml et /config/secret pour qu'elles correspondent à être lisibles par cet utilisateur, ou sinon, utilisez docker run --user $UID:$GID ... ou peut-être créez le conteneur Docker à partir des sources et utilisez les ARG disponibles pour l'UID et le GID.
Des versions de conteneurs automatisées pour chaque version de Vouch Proxy sont disponibles sur quay.io. Chaque version produit ..
un conteneur binaire go minimal construit à partir de Dockerfile
quay.io/vouch/vouch-proxy:latest
quay.io/vouch/vouch-proxy:xyz tel que quay.io/vouch/vouch-proxy:0.28.0
un conteneur basé sur alpine construit à partir de Dockerfile.alpine
quay.io/vouch/vouch-proxy:alpine-latest
quay.io/vouch/vouch-proxy:alpine-xyz
Les images arm proxy Vouch sont disponibles sur Docker Hub
voucher/vouch-proxy:latest-arm
Si vous utilisez Kubernetes avec nginx-ingress, vous pouvez configurer votre entrée avec les annotations suivantes (remarque citant l'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-User
nginx.ingress.kubernetes.io/auth-snippet : | # ces valeurs de retour sont utilisées par l'appel @error401
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; # lorsque VP est hébergé en externe par k8s, assurez-vous que le certificat SSL est valide pour éviter les risques MITM # proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt ; # proxy_ssl_session_reuse activé ; # proxy_ssl_verify_degree 2 ; # proxy_ssl_verify activé ;Les graphiques de barre sont gérés par Punkle, Martina-if et Halkeye et sont disponibles sur https://github.com/vouch/helm-charts
./do.sh goget ./do.sh construire ./vouche-proxy
Depuis v0.29.0 tous les modèles, actifs statiques et valeurs de configuration par défaut dans .defaults.yml sont intégrés dans le binaire statique à l'aide des directives go:embed.
Depuis v0.11.0 des contrôles supplémentaires sont en place pour réduire la surface d'attaque de la redirection d'URL.
L'URL transmise...
doit commencer par http ou https
doit avoir un domaine qui chevauche soit un domaine dans la liste vouch.domains , soit avec vouch.cookie.domain (si l'un ou l'autre est configuré)
ne peut pas avoir de paramètre incluant une URL pour empêcher les attaques par chaînage d'URL
Le point de terminaison Vouch Proxy /logout accepte un paramètre url dans la chaîne de requête qui peut être utilisé pour rediriger 302 un utilisateur vers le point de terminaison revocation_endpoint de votre fournisseur OAuth/IDP/OIDC d'origine.
https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoke
cette url doit être présente dans le fichier de configuration sur la liste vouch.post_logout_redirect_uris
# afin d'éviter les attaques de redirection, toutes les URL redirigées vers /logout doivent être spécifiées# l'URL doit toujours être transmise à Vouch Proxy sous la forme https://vouch.yourdomain.com/logout?url=${UNE DES URL CI-DESSOUS}post_logout_redirect_uris : # la page de connexion de vos applications
- https://yourdomain.com/login # le point de déconnexion de votre IdP # depuis https://accounts.google.com/.well-known/openid-configuration
- https://oauth2.googleapis.com/revoke # vous pouvez être connecté en série à votre IdP
- https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login Notez que votre IdP aura probablement sa propre liste post_logout_redirect_uri distincte.
ressources de déconnexion..
Okta
Auth0
Faire en sorte que les étoiles s'alignent entre Nginx, Vouch Proxy et votre IdP peut être délicat. Nous voulons vous aider à être opérationnel le plus rapidement possible. Le problème le plus courant est..
Vérifiez à nouveau que vous exécutez Vouch Proxy et vos applications sur un domaine commun pouvant partager des cookies. Par exemple, vouch.yourdomain.com et app.yourdomain.com peuvent partager des cookies sur le domaine .yourdomain.com . (Cela ne fonctionnera pas si vous essayez d'utiliser vouch.yourdomain.org et app.yourdomain.net .)
Vous devrez peut-être définir explicitement le domaine sur lequel le cookie doit être installé. Vous pouvez le faire dans le fichier de configuration en définissant l'option :
garant : cookie : # force le domaine du cookie à définir le domaine : votredomaine.com
Si vous continuez à rencontrer des problèmes, essayez ce qui suit :
activez vouch.testing: true . Cela ralentira la boucle.
définissez vouch.logLevel: debug .
l'en-tête Host: dans la requête http, le oauth.callback_url et le vouch.domains configurés doivent tous s'aligner pour que le cookie qui transporte le JWT puisse être placé correctement dans le navigateur puis renvoyé à chaque requête
ça aide de penser comme un cookie .
un cookie est placé dans un domaine. Si votre siteA.yourdomain.com et siteB.yourdomain.com sont protégés par Vouch Proxy, vous souhaitez que le cookie Vouch Proxy soit défini dans .yourdomain.com
si vous vous authentifiez sur vouch.yourdomain.com le cookie ne pourra pas être vu par dev.anythingelse.com
sauf si vous utilisez https, vous devez définir vouch.cookie.secure: false
les cookies sont disponibles sur tous les ports d'un domaine
veuillez consulter les problèmes qui ont été résolus et qui mentionnent la redirection
Veuillez soumettre un nouveau numéro de la manière suivante.
TLDR :
définir vouch.testing: true
définir vouch.logLevel: debug
effectuez deux allers-retours complets de ./vouch-proxy capturant la sortie.
Vice-président du démarrage
/validate
/login - même si l'erreur est ici
/auth
/validate - capturer tout
mettez tous vos journaux et configurations dans un gist .
./do.sh bug_report est votre ami
activez vouch.testing: true et définissez vouch.logLevel: debug .
utilisez un service Gist ou un autre service de collage tel que hasteb.in. NE METTRE PAS VOS JOURNAUX ET VOTRE CONFIG DANS LE NUMÉRO GITHUB . L'utilisation d'un service de collage est importante car elle maintiendra l'espacement et fournira les numéros de ligne et le formatage. Nous recherchons des aiguilles dans des meules de foin avec des configurations à plusieurs pièces mobiles, ces fonctionnalités aident considérablement. Les services de collage vous font gagner du temps et notre temps et nous aident à vous aider rapidement. Vous aurez plus de chances d'obtenir un bon soutien de notre part en temps opportun en suivant ces conseils.
exécutez ./do.sh bug_report secretdomain.com secretpass [anothersecret..] qui créera une version expurgée de votre configuration et des journaux en supprimant chacune de ces chaînes
et suivez les instructions à la fin pour rédiger votre configuration Nginx
tout cela rentre dans l'essentiel
puis ouvrez un nouveau numéro dans ce référentiel
Un rapport de bug peut être généré à partir d'un environnement Docker en utilisant l'image quay.io/vouch/vouch-proxy:alpine ...
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 someothersecretNous serions ravis que vous contribuiez ! Veuillez vous référer à nos directives de contribution pour plus de détails.
OpenResty® est une plate-forme Web à part entière qui intègre le noyau standard Nginx, LuaJIT, de nombreuses bibliothèques Lua soigneusement écrites, de nombreux modules Nginx tiers de haute qualité et la plupart de leurs dépendances externes.
Vous pouvez remplacer nginx par OpenResty assez facilement.
Avec OpenResty et Lua, il est possible de fournir une autorisation personnalisée et avancée sur n'importe quel en-tête ou justificatif de réclamation transmis.
OpenResty et les configurations pour une variété de scénarios sont disponibles dans le répertoire des exemples.
Bob visite https://private.oursites.com
le proxy inverse Nginx...
si /validate renvoie...
répondez à Bob avec une redirection 302 vers https://vouch.oursites.com/login?url=https://private.oursites.com
200 OK puis SUCCÈS laissez passer Bob
401 NotAuthorized alors
reçoit la demande de private.oursites.com de Bob
utilise le module auth_request configuré pour le chemin /validate
/validate est configuré pour les requêtes proxy_pass au service d'authentification à l' https://vouch.oursites.com/validate
Proxy garant https://vouch.oursites.com/validate
renvoyer 401 NotAuthorized à Nginx (qui transmet la demande à la connexion)
renvoie 200 OK à Nginx, ce qui autorisera l'accès (bob ne remarque rien)
reçoit la demande de private.oursites.com de Bob via Nginx proxy_pass
recherche un cookie nommé "oursitesSSO" qui contient un JWT
si le cookie est trouvé et que le JWT est valide
si le cookie n'est PAS trouvé, ou si le JWT n'est PAS valide
Bob est d'abord transféré brièvement vers https://vouch.oursites.com/login?url=https://private.oursites.com
efface le cookie nommé "oursitesSSO" s'il existe
génère un nonce et le stocke dans la variable de session $STATE
stocke l'URL https://private.oursites.com à partir de la chaîne de requête dans la variable de session $requestedURL
répondre à Bob avec une redirection 302 vers le formulaire de connexion OAuth de Google, y compris le nom occasionnel $STATE
Bob se connecte à son compte Google en utilisant Oauth
après une connexion réussie
Google répond à Bob avec une redirection 302 vers https://vouch.oursites.com/auth?state=$STATE
Bob est redirigé vers https://vouch.oursites.com/auth?state=$STATE
émettre à bob un JWT sous la forme d'un cookie nommé "oursitesSSO"
récupérez la variable de session $requestedURL et redirigez Bob vers https://private.oursites.com
si le $STATE nonce de l'url correspond à la variable de session "state"
faire une demande de « troisième étape » à Google (serveur à serveur) pour échanger le code OAuth contre les informations utilisateur de Bob, y compris l'adresse e-mail [email protected]
si l'adresse e-mail correspond au domaine oursites.com (c'est le cas)
Notez qu'en dehors de certaines redirections inoffensives, Bob ne voit que https://private.oursites.com et l'écran de connexion Google dans son navigateur. Bien que Vouch interagisse plusieurs fois avec le navigateur de Bob, il s'agit simplement de définir des cookies, et si les redirections 302 fonctionnent correctement, Bob se connectera rapidement.
Une fois le JWT défini, Bob sera autorisé pour tous les autres sites configurés pour utiliser https://vouch.oursites.com/validate à partir du module auth_request Nginx.
La prochaine fois que Bob est redirigé vers Google pour se connecter, puisqu'il a déjà autorisé l'application Vouch Proxy OAuth, Google le renvoie immédiatement, définit le cookie et le renvoie sur son bon chemin. Dans certains navigateurs tels que Chrome, Bob peut même ne pas remarquer qu'il s'est connecté à l'aide de Vouch Proxy.
