Ce se întâmplă în pasul de browser al unei autentificări VPN federate

Apeși Conectare, iar în locul unei casete de parolă clientul VPN îți deschide browserul. Această predare îi încurcă pe cei care se așteaptă ca tunelul să se autentifice singur. Browserul nu este un ocol: acolo furnizorul de identitate autentifică efectiv persoana, iar clientul așteaptă doar rezultatul.

Parcurgerea unei autentificări de la început la sfârșit arată unde aparține fiecare eșec, iar aceasta este partea pe care majoritatea runbook-urilor o sar.

Începe cu clientul, nu cu configurația gateway-ului

Clientul construiește o cerere și trimite browserul la furnizorul de identitate cu un identificator de furnizor de servicii și o locație de întoarcere. Apoi IdP-ul organizației tale rulează ce este configurat să ruleze: parolă, MFA, verificarea dispozitivului, acces condiționat. Dacă browserul are deja o sesiune validă, partea vizibilă poate dura o secundă sau două. Această scurtime este reutilizarea sesiunii, nu o verificare sărită.

Citește în configurația de federație a clientului două valori înainte de orice altceva: metadatele sau URL-ul IdP în care are încredere și adresa de callback pe care o așteaptă. O nepotrivire acolo eșuează înainte de a fi tastată vreo parolă.

Ce trebuie să returneze furnizorul de identitate

IdP-ul răspunde cu un răspuns SAML semnat care conține o assertion: cine este subiectul, cine a emis-o, pentru cine este și cât timp rămâne validă. Aceste câmpuri sunt contractul. Emitentul, audience, destinatarul și fereastra de valabilitate trebuie să corespundă toate cu ce așteaptă serviciul.

Un răspuns semnat de IdP-ul corect, dar adresat altei audience, este tot invalid. Aceasta este verificarea pe care oamenii o sar când copiază metadate între un laborator și producție.

Ce validează serviciul VPN înainte să aibă încredere în tine

Serviciul verifică semnătura față de certificatul de încredere, controlează emitentul, audience și destinatarul, apoi evaluează condițiile de timp. Abia după aceea mapează assertion-ul la un utilizator sau grup și aplică politica de autorizare VPN. Aici autentificarea și autorizarea sunt pași separați, iar o assertion validă fără un grup potrivit produce o sesiune care se conectează și nu ajunge nicăieri.

Assertion-ul este material de autentificare, nu o parolă. Să îl lipești în alt client sau să îl păstrezi pentru o reconectare ulterioară nu este o autentificare acceptată.

Două durate de viață care se termină separat

Sesiunea de browser la IdP și sesiunea VPN la gateway expiră pe ceasuri diferite. Deconectarea de la IdP nu desființează neapărat un tunel deja stabilit, iar deconectarea tunelului nu te scoate din browser.

AWS Client VPN documentează că fluxul său federat nu acceptă SAML single logout, ceea ce este un exemplu concret al decalajului. Verifică propriul serviciu în loc să presupui simetrie.

De aceea o reconectare se comportă diferit la 09:00 și la 15:00. Poate reutiliza silențios sesiunea IdP, poate cere din nou MFA sau poate eșua pentru că durata sesiunii endpoint-ului a expirat, în timp ce sesiunea de browser nu. Fluxul de federație AWS descrie propriile cerințe de client și de răspuns, iar alte servicii folosesc predări diferite.

Când pasul de browser eșuează, verifică acestea în ordine

Lucrează de la browser spre exterior, pentru că mesajul de eroare numește de obicei ultimul salt, nu primul.

Dacă pagina nu se încarcă niciodată, URL-ul IdP al clientului sau calea către el este greșită. Dacă IdP-ul respinge cererea, identificatorul de furnizor de servicii sau callback-ul nu corespunde configurației sale. Dacă browserul arată succes și clientul tot eșuează, răspunsul a ajuns în locul greșit sau a eșuat validarea audience și de timp. Iar dacă tunelul pornește fără acces, assertion-ul a fost acceptat, dar maparea grupurilor nu.

Ține pagina așteptată, callback-ul și maparea grupurilor într-un singur document. Atunci un utilizator care raportează o autentificare VPN defectă poate spune care dintre aceste patru lucruri le-a văzut, iar răspunsul este deja pe jumătate scris.