☰

将身份验证标头从 apache 转发到 nginx 时出现奇怪问题 - 在继续进行的请求中未找到非空标头（se_custid/ein）

tag-icon • tag-icon nginx apache-2.4 azure authentication headers
将身份验证标头从 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：error] [pid 26485] [客户端SERVERIP：35888] oidc_clean_expired_state_cookies：状态已过期

nginx 中没有记录特定错误。

所以这里的问题是如何将正确的标头从 apache 转发到 nginx，以便经过身份验证的用户能够正确使用该应用程序，或者下面的配置是否足够或需要更多设置？

apache 配置部分

<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

好吧，围绕理解做了一些尝试，部署了另一个临时设置来了解挖掘更多日志。

以下是当前的理解用户请求 -> 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 和我们的应用程序。

相关内容