En la configuración que se describe a continuación, parece que Apache no puede reenviar los encabezados requeridos a nginx o nginx, mientras que el reenvío de la solicitud inicial no es la URL completa, sino solo la ruta relativa.
La idea aquí es garantizar que Azure ADFS autentique las solicitudes a las aplicaciones alojadas en nginx. Para que esto funcione, Apache desempeña el papel de proxy para cualquier solicitud de autenticación. Apache usa mod_auth_openidc y reenvía solicitudes no autenticadas a Azure ADFS. Consulte a continuación:
Nginx -> Apache:6000-> Azure ADFS -> Apache:6000 -> Nginx
Mientras que Azure ADFS autentica correctamente al usuario, se le redirige de nuevo a Nginx:80 pero el navegador (debido a la aplicación) muestra un error extraño "Encabezado no vacío (se_custid/ein) no encontrado en la solicitud para continuar"
Dos errores más en el registro de Apache son:
[auth_openidc:error] [pid 26485] [client SERVERIP:35888] oidc_clean_expired_state_cookies: el estado ha caducado
No se registraron errores específicos en nginx.
Entonces, la pregunta aquí es cómo reenviar los encabezados correctos de Apache a nginx para que el usuario posterior a la autenticación pueda usar la aplicación correctamente o ¿la configuración siguiente es suficiente o se requieren más configuraciones?
parte de configuración de 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>
partes de configuración de 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;
}
Respuesta1
Muy bien, hicimos un poco de análisis sobre la comprensión, implementamos otra configuración temporal para comprender la excavación de más registros.
Aquí está la comprensión actual Solicitud de usuario -> Nginx:443/ourapp -> Apache:6000-> Azure ADFS ->Azure devuelve la URL al navegador ->El navegador solicita la URL devuelta
Al observar los registros de cerca, quedó claro lo que estaba sucediendo. Más sobre esto le ayudó a entenderlo.más
Después de modificar ngnix para enviar encabezados correctos con el puerto y el Host correcto,
proxy_set_header X-Forwarded-Port "443";
proxy_set_header X-Forwarded-Host "forever-authcheck.tire1network.com";
lo que resultó en la configuración de cookies correcta para original_url, por apache y mod_auth_openidc.
Ahora la redirección funciona correctamente, los reclamos llegan a NGINX y a nuestra aplicación.