將 auth 標頭從 apache 轉送到 nginx 時出現奇怪的問題 - 在繼續的請求中找不到非空標頭(se_custid/ein)

將 auth 標頭從 apache 轉送到 nginx 時出現奇怪的問題 - 在繼續的請求中找不到非空標頭(se_custid/ein)

在下面描述的設定中,看起來 apache 無法將所需的標頭轉送到 nginx 或 nginx,而轉送初始請求不是轉送完整 URL,而只是轉送相對路徑。

這裡的想法是確保對 nginx 上託管的應用程式的請求由 Azure ADFS 進行身份驗證。為此,apache 正在扮演任何身份驗證請求的代理角色。 Apache 正在使用 mod_auth_openidc,並將未經驗證的請求轉送至 Azure ADFS 請參閱下文:

Nginx -> Apache:6000-> Azure ADFS -> Apache:6000 -> Nginx

雖然使用者透過 Azure ADFS 正確進行身份驗證,但被重定向回 Nginx:80,但瀏覽器(由於應用程式)顯示奇怪的錯誤“在繼續的請求中找不到非空標頭(se_custid/ein)”

apache 日誌中另外兩個錯誤是:

[auth_openidc:錯誤] [pid 26485] [客戶端SERVERIP:35888] oidc_clean_expired_state_cookies:狀態已過期

nginx 中沒有記錄任何特定錯誤。

所以這裡的問題是如何將正確的標頭從 apache 轉發到 nginx,以便身份驗證後的用戶能夠正確使用該應用程序,或者以下配置是否足夠或需要更多設定?

阿帕契配置部分

<Location /ourapp>
   AuthType openid-connect
   Require valid-user
</Location>

LoadModule auth_openidc_module modules/mod_auth_openidc.so
OIDCProviderMetadataURL https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/v2.0/.well-known/openid-configuration
OIDCClientID XXXXXXXXXXXXXXX
OIDCClientSecret XXXXXXXXXX
OIDCRedirectURI https://forever-authcheck.tire1network.com:6000/ourapp 
OIDCCryptoPassphrase XXXXXXXXXXXX
OIDCScope "openid email profile"
#OIDCRemoteUserClaim email
OIDCProviderAuthorizationEndpoint https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/oauth2/v2.0/authorize
OIDCProviderTokenEndpoint https://login.microsoftonline.com/XXXX_XXX-xxx-XXXXXX/oauth2/v2.0/token
#OIDCPKCEMethod S256

OIDCPassIDTokenAs claims
OIDCCookiePath /
OIDCCookieDomain forever-authcheck.tire1network.com
OIDCCookie APP-OIDC-SESSION
OIDCCookieHTTPOnly On
OIDCSessionInactivityTimeout 600
OIDCSessionMaxDuration 36006

<VirtualHost *:6000>

    ProxyPreserveHost On
    ErrorLog  /var/log/httpd/voidcerror.log
    LogLevel debug
    ServerName forever-authcheck.tire1network.com

    Header always set Access-Control-Allow-Origin "*"
    Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
    Header always set Access-Control-Max-Age "1000"
    Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"
    
    ProxyPreserveHost On
    Header set ein %{OIDC_CLAIM_EIN}e
    ProxyPass /ourapp/ forever-authcheck.tire1network.com/in/
    ProxyPassReverse /ourapp/ forever-authcheck.tire1network.com/in/
    ProxyPreserveHost On
    ServerName  forever-authcheck.tire1network.com
    
    SSLEngine on
    SSLCertificateFile "/etc/pki/outcert/Certificate.pem"
    SSLCertificateKeyFile "/etc/pki/outcert/CertificateKey.pem"
    SSLCertificateChainFile "/etc/pki/outcert/CertificateChain.p12"
</VirtualHost>



nginx 設定部分

nginx:80


location /ourapp/ {
  proxy_ssl_server_name on;
  proxy_pass https://forever-authcheck.tire1network.com:6000;
  proxy_set_header se-journey "direct";
  proxy_set_header  Host $host;
  proxy_set_header  X-Real-IP $remote_addr;
  proxy_set_header  X-Forwarded-For $remote_addr;
  proxy_set_header  X-Forwarded-Host $remote_addr;
  proxy_redirect default;
  

  proxy_ssl_certificate     /etc/pki/outcert/Certificate.pem;
  proxy_ssl_certificate_key /etc/pki/outcert/CertificateKey.pem;
  proxy_ssl_verify       off;
}









答案1

好吧,圍繞著理解做了一些tshoot,部署了另一個臨時設定來理解挖掘更多日誌。

這是目前理解的 User Request -> Nginx:443/ourapp -> Apache:6000-> Azure ADFS ->Azure 將 URL 傳回瀏覽器 ->瀏覽器請求返回的URL

透過仔細查看日誌,很清楚發生了什麼,更多這一點有助於它理解它更多的

調整 ngnix 以發送帶有連接埠和正確主機的正確標頭後,

proxy_set_header X-Forwarded-Port "443";

proxy_set_header X-Forwarded-Host "forever-authcheck.tire1network.com";

這導致 apache 和 mod_auth_openidc 為original_url 設定了正確的 cookie。

現在重定向工作正常,索賠已到達 NGINX 和我們的應用程式。

相關內容