auth_request 모듈을 사용하는 Nginx용 SSO 솔루션입니다. Vouch Proxy는 모든 웹사이트를 한 번에 보호할 수 있습니다.
Vouch Proxy는 다양한 OAuth 및 OIDC 로그인 공급자를 지원하며 다음에 대한 인증을 시행할 수 있습니다.
GitHub
GitHub 엔터프라이즈
인디인증
옥타
느슨하게
ADFS
Azure AD
알리바바 / 알리윤 iDaas
AWS 코그니토
경련
불화
보안 인증
기테아
열쇠망토
PHP용 OAuth2 서버 라이브러리
홈어시스턴트
오픈스탁스
오리 히드라
넥스트클라우드
대부분의 기타 OpenID Connect(OIDC) 제공업체
목록을 업데이트할 수 있도록 선호하는 IdP 또는 라이브러리와 함께 Vouch Proxy를 배포한 경우 알려 주시기 바랍니다.
Vouch가 Nginx 역방향 프록시와 동일한 호스트에서 실행 중인 경우 /validate
엔드포인트에서 Nginx까지의 응답 시간은 1ms 미만 이어야 합니다.
보증 프록시의 기능...
설치 및 구성
"경로에 있는" 프록시를 보증합니다.
추가 Nginx 구성
환경 변수를 통한 구성
팁, 요령 및 고급 구성
범위 및 청구
도커에서 실행
Kubernetes Nginx 인그레스
소스에서 컴파일하고 바이너리 실행
/login 및 /logout 엔드포인트 리디렉션
문제 해결, 지원 및 기능 요청(GitHub에 문제를 제출하기 전에 이 내용을 읽으십시오)
내 IdP(Google/Okta/GitHub/...)로 돌아가는 무한 리디렉션 루프가 발생합니다.
알겠습니다. 문제를 살펴보고 구성으로 몇 가지 작업을 시도했지만 여전히 작동하지 않습니다.
Vouch Proxy에 기여
OpenResty를 사용한 고급 인증
Google Oauth를 이용한 로그인 및 인증 흐름
Vouch Proxy(VP)는 방문자가 웹사이트에 액세스할 수 있도록 하기 전에 IdP(예: 위에 나열된 서비스 중 하나)에 로그인하고 인증하도록 합니다.
VP는 SSO(Single Sign On) 솔루션으로도 사용되어 동일한 도메인에 있는 모든 웹 애플리케이션을 보호할 수 있습니다.
방문자가 로그인한 후 Vouch Proxy를 사용하면 몇 시간 동안 보호된 웹사이트에 액세스할 수 있습니다. 모든 요청은 VP가 확인하여 유효한지 확인합니다.
VP는 IdP가 제공하는 방문자의 이메일, 이름 및 기타 정보(액세스 토큰 포함)를 웹 애플리케이션에 HTTP 헤더로 보낼 수 있습니다. VP는 애플리케이션 사용자 관리를 완전히 대체하는 데 사용될 수 있습니다.
Vouch Proxy는 Vouch Proxy 서버와 이것이 보호하는 애플리케이션 간에 쿠키를 공유하는 기능에 의존합니다. 일반적으로 이는 app1.yourdomain.com
및 app2.yourdomain.com
에서 실행되는 앱과 함께 vouch.yourdomain.com
과 같은 하위 도메인에서 Vouch를 실행하여 수행됩니다. 보호되는 도메인은 .yourdomain.com
이며 Vouch.domains를 yourdomain.com
포함하도록 설정하거나 때로는 vouch.cookie.domain을 yourdomain.com
으로 설정하여 Vouch 프록시 쿠키를 이 도메인에 설정해야 합니다.
cp ./config/config.yml_example_$OAUTH_PROVIDER ./config/config.yml
Google이나 github 등에서 Vouch Proxy에 대한 OAuth 자격 증명을 만듭니다.
콜백 URL을 Vouch Proxy /auth
엔드포인트로 지정해야 합니다.
Nginx 구성...
다음 Nginx 구성은 다음과 같이 가정합니다.
Nginx, vouch.yourdomain.com
및 protectedapp.yourdomain.com
이 동일한 서버에서 실행 중입니다.
두 도메인 모두 https
로 제공되며 유효한 인증서가 있습니다(그렇지 않은 경우 listen 80
으로 변경하고 vouch.cookie.secure를 false
로 설정).
서버 { 443 SSL http2 듣기; server_name protectedapp.yourdomain.com; 루트 /var/www/html/; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # 인증을 위해 `/validate` 엔드포인트로 모든 요청을 보냅니다 auth_request /validate; location = /validate { # /validate 요청을 Vouch Proxy로 전달합니다. proxy_pass http://127.0.0.1:9090/validate; # 원래 호스트 헤더를 전달해야 합니다. proxy_set_header Host $http_host; # Vouch Proxy는 요청 헤더에서만 작동합니다.proxy_pass_request_body off; Proxy_set_header 콘텐츠 길이 ""; # 요청과 함께 Vouch 프록시가 반환한 X-Vouch-User를 선택적으로 추가합니다. auth_request_set $auth_resp_x_vouch_user $upstream_http_x_vouch_user; # 선택적으로 추적 중인 X-Vouch-IdP-Claims-* 사용자 지정 클레임을 추가합니다. # 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; # 선택적으로 X-Vouch-IdP-AccessToken 또는 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; # 이러한 반환 값은 @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 프록시는 동일한 Nginx 역방향 프록시 뒤에서 실행될 수 있습니다. # "업스트림" 서버 명명을 준수해야 할 수도 있습니다. # Proxy_pass http://vouch.yourdomain.com/validate; # Proxy_set_header 호스트 $http_host; } # 유효성 검사에서 `401 승인되지 않음`이 반환되면 요청을 error401block으로 전달합니다. error_page 401 = @error401; 위치 @error401 { # 로그인 반환을 위해 Vouch 프록시로 리디렉션 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; # 일반적으로 https로 보호되는 동일한 Nginx 구성 뒤에서 실행되는 Vouch로 리디렉션하고 *원*하지만 시작하려면 # return 302에서 vouch가 실행 중인 포트로 최종 사용자를 전달하면 됩니다. 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; } 위치 / { # 승인된 요청을 서비스로 전달 protectedapp.yourdomain.com Proxy_pass http://127.0.0.1:8080; # 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; # 사용자 헤더 설정(일반적으로 이메일) Proxy_set_header X-Vouch-User $auth_resp_x_vouch_user; # 선택적으로 추적 중인 사용자 지정 클레임을 전달합니다. # 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; # 선택적으로 accesstoken 또는 idtoken을 전달합니다. # 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; } }
Vouch가 동일한 nginx reverseproxy 뒤에 구성된 경우(아마도 SSL을 구성할 수 있도록) Host
헤더를 올바르게 전달해야 합니다. 그렇지 않으면 JWT 쿠키를 도메인에 설정할 수 없습니다.
서버 { 443 SSL http2 듣기; 서버 이름 vouch.yourdomain.com; ssl_certificate /etc/letsencrypt/live/vouch.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/vouch.yourdomain.com/privkey.pem; 위치 / {proxy_pass http://127.0.0.1:9090; # 원래 호스트 헤더를 전달해야 합니다. proxy_set_header Host $http_host; } }
v0.33.0
부터 vouch.document_root: /vp_in_a_path
구성하여 Nginx 위치(경로) 내에서 Vouch Proxy를 제공할 수 있습니다.
이렇게 하면 vouch.yourdomain.com
과 같은 Vouch Proxy용 별도 도메인을 설정할 필요가 없습니다. 예를 들어 VP 로그인은 https://protectedapp.yourdomain.com/vp_in_a_path/login
에서 제공됩니다.
서버 { 443 SSL http2 듣기; server_name protectedapp.yourdomain.com; ssl_certificate /etc/letsencrypt/live/protectedapp.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/protectedapp.yourdomain.com/privkey.pem; # 이 위치는 모든 Vouch 프록시 엔드포인트를 /vp_in_a_path/$uri로 제공합니다. # /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 등을 포함합니다. location /vp_in_a_path { proxy_pass http://127.0.0.1:9090; #그러면안돼! 끝에 슬래시가 있습니다. Proxy_set_header Host $http_host; Proxy_pass_request_body 꺼짐; Proxy_set_header 콘텐츠 길이 ""; # 이러한 반환 값은 @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; } # /vp_in_a_path/validate가 '401 승인되지 않음'을 반환하면 요청을 error401block으로 전달합니다. error_page 401 = @error401; 위치 @error401 { # 로그인 반환을 위해 Vouch 프록시로 리디렉션 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; } 위치 / { auth_request /vp_in_a_path/validate; 프록시패스 http://127.0.0.1:8080; # Vouch Proxy에서 설정할 수 있는 추가 헤더는 위의 Nginx 구성을 참조하세요. } }
추가 Nginx 구성은 예제 디렉터리에서 찾을 수 있습니다.
다음은 Google의 OAuth를 사용한 최소 설정입니다.
VOUCH_DOMAINS=yourdomain.com OAUTH_PROVIDER=구글 OAUTH_CLIENT_ID=1234 OAUTH_CLIENT_SECRET=비밀비밀 OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth ./vouch-proxy
환경 변수 이름은 config/config.yml_example에 문서화되어 있습니다.
여러 값이 있는 모든 목록은 쉼표로 구분되어야 합니다. VOUCH_DOMAINS="yourdomain.com,yourotherdomain.com"
VOUCH_CONFIG
변수를 사용하여 구성 파일의 대체 위치를 설정할 수 있습니다. VOUCH_ROOT
지원 파일을 찾기 위해 Vouch Proxy의 대체 루트 디렉터리를 설정하는 데 사용할 수 있습니다.
모든 Vouch 프록시 구성 항목은 config/config.yml_example에 문서화되어 있습니다.
Nginx에서 Vouch Proxy 캐싱 /validate
응답
Vouch Proxy로 API를 보호할 때 OPTIONS
요청 처리
GitHub 팀 또는 GitHub 조직의 검증
ARM 기반 Docker 이미지를 사용하여 Raspberry Pi에서 VP 실행
Kubernetes 아키텍처 사후 수신
아웃바운드 프록시 서버를 통해 Vouch Proxy IdP 요청을 릴레이하도록 HTTP_PROXY
설정합니다.
Google Cloud Run 서비스용 역방향 프록시
Vouch Proxy에서 기본 TLS 활성화
FreeBSD 지원
Vouch Proxy의 systemd
시작
Nginx 대신 Node.js를 사용하여 요청 라우팅
VP 보호 API를 사용하면서 단일 페이지 앱(SPA) 개발
사용자 인증 및 인증을 위해 Vouch Proxy를 서버 측 애플리케이션에 통합
satisfy any;
이 목록을 확장할 수 있도록 도와주세요.
Vouch Proxy를 사용하면 다양한 scopes
(표준 및 사용자 정의)를 요청하여 사용자에 대한 추가 정보를 얻거나 공급자의 API에 액세스할 수 있습니다. 내부적으로 Vouch Proxy는 인증 성공 후 user_info_url
에 대한 요청을 시작합니다. 필요한 claims
공급자의 응답에서 추출되어 VP 쿠키에 저장됩니다.
VP 쿠키는 브라우저 쿠키 크기 제한을 수용하기 위해 여러 쿠키로 분할될 수 있습니다. 하지만 필요하다면 필요합니다. 큰 쿠키와 헤더를 사용하려면 Nginx를 더 큰 버퍼로 구성해야 합니다. 자세한 내용은 Large_client_header_buffers 및 Proxy_buffer_size를 참조하세요.
scopes
및 claims
설정Nginx 및 IdP에 대한 Vouch Proxy를 정상적으로 구성합니다(참조: 설치 및 구성).
vouch-proxy config.yml
의 oauth
섹션에서 필요한 scope
를 설정합니다(예제 구성).
idtoken: X-Vouch-IdP-IdToken
vouch-proxy의 config.yml
headers
섹션에 X-Vouch-IdP-IdToken
최신 브라우저에서 로그인하고 /validate
엔드포인트를 호출하세요.
X-Vouch-IdP-IdToken
헤더에 대한 응답 헤더를 확인하세요.
헤더 값을 https://jwt.io/의 디버거에 복사하고 필요한 클레임이 jwt의 일부인지 확인하세요.
그렇지 않은 경우 config.yml
의 oauth
섹션에서 scopes
조정하거나 oauth 공급자를 재구성해야 합니다.
vouch-proxy config.yml
의 header
섹션에 필요한 claims
설정합니다.
최신 브라우저에서 로그인하고 /validate
엔드포인트를 호출하세요.
X-Vouch-IdP-Claims-<ClaimName>
형식의 헤더에 대한 응답 헤더를 확인하세요.
쿠키가 없으면 쿠키와 캐시된 브라우저 데이터를 삭제하세요.
? 여전히 거기에 없지만 jwt(특히 사용자 정의 클레임)에 존재하는 경우 버그가 있을 수 있습니다.
필요하지 않은 경우 vouch-proxy의 config.yml
headers
섹션에서 idtoken: X-Vouch-IdP-IdToken
제거하세요.
nginx server.conf
의 보호된 위치 내에서 auth_request
뒤에 auth_request_set
사용하세요.
클레임 사용(예: nginx 구성)
도커 실행 -d -p 9090:9090 --name 보증 프록시 -v ${PWD}/config:/config quay.io/vouch/vouch-proxy
또는
도커 실행 -d -p 9090:9090 --name 보증 프록시 -e VOUCH_DOMAINS=yourdomain.com -e OAUTH_PROVIDER=google -e OAUTH_CLIENT_ID=1234 -e OAUTH_CLIENT_SECRET=비밀비밀 -e OAUTH_CALLBACK_URL=https://vouch.yourdomain.com/auth quay.io/vouch/vouch-proxy
v0.36.0
부터 컨테이너의 도커 프로세스는 UID 999 및 GID 999를 사용하여 사용자 vouch
으로 실행됩니다. 이 사용자가 읽을 수 있도록 /config/config.yml
및 /config/secret
의 권한을 설정해야 할 수도 있습니다. 또는 docker run --user $UID:$GID ...
사용하거나 소스에서 docker 컨테이너를 빌드하고 UID 및 GID에 사용 가능한 ARG를 사용할 수도 있습니다.
각 Vouch Proxy 릴리스에 대한 자동화된 컨테이너 빌드는 quay.io에서 제공됩니다. 각 릴리스는 ..
Dockerfile
로 구축된 최소 Go 바이너리 컨테이너
quay.io/vouch/vouch-proxy:latest
quay.io/vouch/vouch-proxy:xyz
(예: quay.io/vouch/vouch-proxy:0.28.0
Dockerfile.alpine
으로 구축된 alpine
기반 컨테이너
quay.io/vouch/vouch-proxy:alpine-latest
quay.io/vouch/vouch-proxy:alpine-xyz
Vouch Proxy arm
이미지는 Docker Hub에서 사용할 수 있습니다.
voucher/vouch-proxy:latest-arm
nginx-ingress와 함께 kubernetes를 사용하는 경우 다음 주석으로 수신을 구성할 수 있습니다( 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: | # 이 반환 값은 @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; # VP가 k8s 외부에서 호스팅되는 경우 SSL 인증서가 유효한지 확인하여 MITM 위험을 방지합니다. # Proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt; # Proxy_ssl_session_reuse 켜짐; # 프록시_ssl_verify_깊이 2; # Proxy_ssl_verify 켜짐;
Helm 차트는 punkle, martina-if 및 halkeye에서 관리하며 https://github.com/vouch/helm-charts에서 사용할 수 있습니다.
./do.sh goget ./do.sh 빌드 ./vouch-proxy
v0.29.0
부터 .defaults.yml
의 모든 템플릿, 정적 자산 및 구성 기본값은 go:embed 지시문을 사용하여 정적 바이너리에 내장됩니다.
v0.11.0
부터 URL 리디렉션의 공격 표면을 줄이기 위한 추가 검사가 이루어졌습니다.
전달된 URL...
http
또는 https
로 시작해야 합니다.
vouch.domains
목록의 도메인 또는 vouch.cookie.domain
(둘 중 하나가 구성된 경우)과 도메인이 중복되어야 합니다.
URL 체인 공격을 방지하기 위해 URL을 포함하는 매개변수를 가질 수 없습니다.
Vouch 프록시 /logout
엔드포인트는 사용자를 원래 OAuth 제공자/IDP/OIDC 제공자의 revocation_endpoint로 302
리디렉션하는 데 사용할 수 있는 쿼리 문자열의 url
매개변수를 허용합니다.
https://vouch.oursites.com/logout?url=https://oauth2.googleapis.com/revoke
이 URL은 vouch.post_logout_redirect_uris
목록의 구성 파일에 있어야 합니다.
# 리디렉션 공격을 방지하려면 /logout으로 리디렉션된 모든 URL을 지정해야 합니다.# URL은 여전히 https://vouch.yourdomain.com/logout?url=${ONE OF THE URLS BELOW}post_logout_redirect_uris로 Vouch Proxy에 전달되어야 합니다. : # 앱 로그인 페이지 - https://yourdomain.com/login # 귀하의 IdP 로그아웃 enpoint # https://accounts.google.com/.well-known/openid-configuration에서 - https://oauth2.googleapis.com/revoke # IdP에 데이지 체인 연결되어 있을 수 있습니다. - https://myorg.okta.com/oauth2/123serverid/v1/logout?post_logout_redirect_uri=http://myapp.yourdomain.com/login
IdP는 자체적인 별도의 post_logout_redirect_uri
목록을 보유할 가능성이 높습니다.
로그아웃 자원..
옥타
인증0
Nginx, Vouch Proxy 및 IdP 간에 별표를 정렬하는 것은 까다로울 수 있습니다. 우리는 귀하가 가능한 한 빨리 시작하고 실행할 수 있도록 돕고 싶습니다. 가장 일반적인 문제는..
쿠키를 공유할 수 있는 공통 도메인에서 Vouch Proxy와 앱을 실행하고 있는지 다시 확인하세요. 예를 들어 vouch.yourdomain.com
및 app.yourdomain.com
.yourdomain.com
도메인에서 쿠키를 공유할 수 있습니다. ( vouch.yourdomain.org
및 app.yourdomain.net
사용하려고 하면 작동하지 않습니다.)
쿠키가 설정되어야 하는 도메인을 명시적으로 정의해야 할 수도 있습니다. 옵션을 설정하여 구성 파일에서 이 작업을 수행할 수 있습니다.
보증: 쿠키: # 쿠키의 도메인을 강제로 도메인: yourdomain.com으로 설정합니다.
문제가 계속 발생하면 다음을 시도해 보세요.
vouch.testing: true
를 켜십시오 . 이렇게 하면 루프 속도가 느려집니다.
vouch.logLevel: debug
설정합니다.
http 요청의 Host:
헤더, oauth.callback_url
및 구성된 vouch.domains
JWT를 전달하는 쿠키가 브라우저에 적절하게 배치된 다음 각 요청에서 반환될 수 있도록 모두 정렬되어야 합니다.
쿠키처럼 생각하는 데 도움이됩니다 .
쿠키는 도메인으로 설정됩니다. Vouch Proxy로 보호되는 siteA.yourdomain.com
및 siteB.yourdomain.com
있는 경우 Vouch Proxy 쿠키를 .yourdomain.com
으로 설정하려고 합니다.
vouch.yourdomain.com
에 인증하면 dev.anythingelse.com
에서 쿠키를 볼 수 없습니다.
https를 사용하지 않는 한 vouch.cookie.secure: false
설정해야 합니다.
쿠키는 도메인의 모든 포트에서 사용할 수 있습니다 .
리디렉션이 언급된 종결된 문제를 참조하세요.
다음과 같은 방법으로 새로운 호를 제출해주세요..
주요 내용:
vouch.testing: true
vouch.logLevel: debug
출력을 캡처하는 ./vouch-proxy
의 두 번의 전체 왕복을 수행합니다.
VP 스타트업
/validate
/login
- 오류가 발생하더라도
/auth
/validate
- 모든 것을 캡처합니다.
모든 로그와 구성을 gist
에 넣으세요.
./do.sh bug_report
당신의 친구입니다
vouch.testing: true
켜고 vouch.logLevel: debug
설정하세요.
요점이나 hasteb.in과 같은 다른 붙여넣기 서비스를 사용하세요. 로그와 구성을 Github 문제에 넣지 마세요 . 붙여넣기 서비스를 사용하면 간격이 유지되고 줄 번호와 서식이 제공되므로 중요합니다. 우리는 여러 개의 움직이는 부품이 있는 설정으로 건초 더미에서 바늘을 찾고 있는데, 이러한 기능은 상당히 도움이 됩니다. 붙여넣기 서비스는 귀하의 시간과 우리의 시간을 절약하고 신속하게 도움을 드릴 수 있도록 도와드립니다. 이 조언을 따르면 적시에 우리로부터 좋은 지원을 받을 가능성이 더 높습니다.
./do.sh bug_report secretdomain.com secretpass [anothersecret..]
실행하면 구성의 수정된 버전이 생성되고 각 문자열을 제거하는 로그가 기록됩니다.
Nginx 구성을 수정하려면 마지막 지침을 따르세요.
그 모든 것들은 요점에 들어갑니다
그런 다음 이 저장소에서 새 이슈를 엽니다.
quay.io/vouch/vouch-proxy:alpine
이미지를 사용하여 Docker 환경에서 버그 보고서를 생성할 수 있습니다.
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 someothersecret
우리는 당신이 기여하길 바랍니다! 자세한 내용은 기여 가이드라인을 참조하세요.
OpenResty®는 표준 Nginx 코어, LuaJIT, 신중하게 작성된 여러 Lua 라이브러리, 수많은 고품질 타사 Nginx 모듈 및 대부분의 외부 종속성을 통합하는 완전한 웹 플랫폼입니다.
nginx를 OpenResty로 상당히 쉽게 교체할 수 있습니다.
OpenResty 및 Lua를 사용하면 모든 헤더 또는 클레임 보증에 대해 사용자 정의된 고급 인증을 제공할 수 있습니다.
OpenResty 및 다양한 시나리오에 대한 구성은 예제 디렉터리에서 사용할 수 있습니다.
Bob은 https://private.oursites.com
방문합니다.
Nginx 리버스 프록시...
/validate
반환되는 경우...
https://vouch.oursites.com/login?url=https://private.oursites.com
으로 302 리디렉션을 사용하여 Bob에게 응답합니다.
200 OK, 성공하면 Bob이 통과할 수 있습니다.
401 승인되지 않음
Bob으로부터 private.oursites.com에 대한 요청을 받았습니다.
/validate
경로에 대해 구성된 auth_request
모듈을 사용합니다.
/validate
는 https://vouch.oursites.com/validate
의 인증 서비스에 요청을 proxy_pass
하도록 구성되어 있습니다.
보증 프록시 https://vouch.oursites.com/validate
Nginx에 401 NotAuthorized
반환(로그인 요청을 전달함)
액세스를 허용하는 Nginx에 200 OK
반환합니다(bob은 아무것도 알아차리지 못합니다).
Nginx proxy_pass
통해 Bob으로부터 private.oursites.com에 대한 요청을 받습니다.
JWT가 포함된 "oursitesSSO"라는 쿠키를 찾습니다.
쿠키가 발견되고 JWT가 유효한 경우
쿠키를 찾을 수 없거나 JWT가 유효하지 않은 경우
Bob은 먼저 https://vouch.oursites.com/login?url=https://private.oursites.com
으로 간략하게 전달됩니다.
"oursitesSSO"라는 쿠키가 있으면 삭제합니다.
nonce를 생성하여 세션 변수 $STATE에 저장합니다.
세션 변수 $requestedURL
의 쿼리 문자열에서 URL https://private.oursites.com
저장합니다.
$STATE
nonce를 포함하여 Google의 OAuth 로그인 양식에 대한 302 리디렉션으로 Bob에게 응답합니다.
Bob은 Oauth를 사용하여 Google 계정에 로그인합니다.
로그인 성공 후
Google은 https://vouch.oursites.com/auth?state=$STATE
로의 302 리디렉션을 통해 Bob에게 응답합니다.
Bob은 https://vouch.oursites.com/auth?state=$STATE
로 전달됩니다.
bob에게 "oursitesSSO"라는 쿠키 형식으로 JWT를 발행합니다.
세션 변수 $requestedURL
검색하고 302 bob을 https://private.oursites.com
으로 다시 리디렉션합니다.
URL의 $STATE nonce가 세션 변수 "state"와 일치하는 경우
이메일 주소 [email protected]을 포함하여 Bob의 사용자 정보에 대한 OAuth 코드를 교환하도록 Google(서버 간)에 "세 번째 다리" 요청을 합니다.
이메일 주소가 oursites.com 도메인과 일치하는 경우(그렇습니다)
일부 무고한 리디렉션 외에 Bob은 브라우저에서 https://private.oursites.com
과 Google 로그인 화면만 볼 수 있습니다. Vouch는 Bob의 브라우저와 여러 번 상호작용하지만 단지 쿠키를 설정하기 위한 것이며 302 리디렉션이 제대로 작동하면 Bob은 빠르게 로그인합니다.
JWT가 설정되면 auth_request
Nginx 모듈에서 https://vouch.oursites.com/validate
사용하도록 구성된 다른 모든 사이트에 대해 Bob에게 권한이 부여됩니다.
다음에 Bob이 로그인을 위해 Google로 전달되면 Bob이 이미 Vouch Proxy OAuth 앱을 승인했기 때문에 Google은 즉시 그를 다시 전달하고 쿠키를 설정한 후 즐거운 길로 보냅니다. Chrome과 같은 일부 브라우저에서는 Bob이 Vouch Proxy를 사용하여 로그인했다는 사실조차 인식하지 못할 수도 있습니다.