Puncte:0

Problemă ciudată cu redirecționarea antetelor de autentificare de la apache la nginx - Antetul care nu este gol (se_custid/ein) nu a fost găsit în cererea de continuare

drapel ng

În configurația descrisă mai jos, se pare că apache nu este capabil să redirecționeze anteturile necesare către nginx sau nginx, în timp ce redirecționarea cererii inițiale nu redirecționează adresa URL completă, ci doar calea relativă.

Ideea aici este să ne asigurăm că cererile către aplicația găzduită pe nginx sunt autentificate de Azure ADFS. pentru ca acest lucru să funcționeze, apache joacă rolul de proxy pentru orice solicitare de autentificare. Apache folosește mod_auth_openidc și trimite cererea neautentificată către Azure ADFS. Vedeți mai jos:

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

În timp ce utilizatorul este autentificat corect de Azure ADFS, este redirecționat înapoi la Nginx:80, dar browserul (din cauza aplicației) afișează o eroare ciudată „Antetul necompletat (se_custid/ein) nu a fost găsit în cererea de a continua”

Încă două erori în jurnalul Apache sunt:

[auth_openidc:error] [pid 26485] [client SERVERIP:35888] oidc_clean_expired_state_cookies: starea a expirat

Nu s-au înregistrat erori specifice în nginx.

Deci întrebarea aici este cum să redirecționați anteturile corecte de la apache la nginx, astfel încât utilizatorul după autentificare să poată folosi aplicația corect sau este suficientă configurația de mai jos sau sunt necesare mai multe setări?

partea de configurare 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>



părți de configurare nginx

nginx:80


locație /ourapp/ {
  proxy_ssl_server_name activat;
  proxy_pass https://forever-authcheck.tire1network.com:6000;
  proxy_set_header se-journey "direct";
  proxy_set_header Gazdă $gazdă;
  proxy_set_header X-Real-IP $adresă_la distanță;
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header X-Forwarded-Host $remote_addr;
  proxy_redirect implicit;
  

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









Puncte:0
drapel ng

bine am făcut un pic de încercare în jurul înțelegerii, am implementat o altă configurare temporară pentru a înțelege săpa mai multe jurnale.

Aici este înțelegerea curentă Solicitarea utilizatorului -> Nginx:443/ourapp -> Apache:6000-> Azure ADFS -> Azure returnează adresa URL la browser -> Browser Solicită adresa URL returnată

Privind îndeaproape jurnalele, a fost clar ce se întâmplă, Mai mult, aceasta l-a ajutat să înțeleagă Mai mult

După ce ați ajustat ngnix pentru a trimite antetele drepte cu portul și gazda corectă,

proxy_set_header X-Forwarded-Port „443”;

proxy_set_header X-Forwarded-Host „forever-authcheck.tire1network.com”;

care a dus la setările corecte ale cookie-urilor pentru original_url, de către apache și mod_auth_openidc.

Acum redirecționarea funcționează corect, revendicările ajung la NGINX și la aplicația noastră.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.