SSO-ul VPN autentifică automat utilizatorii în aplicațiile interne?

Un gateway VPN care se autentifică printr-un furnizor de identitate dovedește un singur lucru: furnizorul a garantat pentru un utilizator în fața gateway-ului. El nu îi oferă acelui utilizator o acreditare pentru wiki-ul intranetului, panoul de monitorizare sau serverul de build. Acele servicii autentifică oamenii prin propria federație și aplică propria autorizare, iar tunelul decide doar ce pachete pot ajunge la ele.

Trei sesiuni, trei decizii separate

Ține stările separate, pentru că fiecare expiră după propriul program. Sesiunea VPN este acceptarea unei identități de către gateway plus accesul la rețea pe care l-a acordat. Sesiunea de browser la furnizorul de identitate este ceea ce browserul mai păstrează pentru acel furnizor și poate reutiliza conform politicii sale. Sesiunea aplicației aparține unui singur serviciu care a validat un răspuns adresat lui.

Confundarea acestor stări produce întrebarea greșită, formulată de obicei ca de ce tunelul nu autentifică utilizatorul peste tot. Reformuleaz-o: care aplicație nu are o intrare de federație, care refuză utilizatorul și căreia îi lipsește o rută. O singură cerere de autentificare care deschide aplicația intranet poate reveni totuși la furnizor, pentru că a doua redirecționare este o cerere nouă de autorizare pentru alt public.

Conectează gateway-ul ca aplicație proprie

Înregistrează VPN-ul ca aplicație aprobată la furnizor, cu identificator, URI de redirecționare și alocare de utilizatori proprii. Apoi decide ce autorizări de rețea acordă acea autentificare, deoarece este politică VPN, nu o funcție a furnizorului. Utilizatorii care trebuie să ajungă doar la subrețeaua de monitorizare primesc altă politică de gateway, nu altă parolă.

Răspunsul de autentificare al tunelului nu este o acreditare reutilizabilă. Tokenurile de ID OIDC poartă o declarație de public care numește clientul pentru care au fost emise, iar aserțiunile purtătoare SAML limitează publicul la furnizorul de servicii care le primește. Un al doilea serviciu care acceptă răspunsul primului este configurat greșit, iar copierea unui token în altă aplicație nu este integrare.

Înregistrează fiecare aplicație internă, apoi setează contextul browserului

Fiecare serviciu are nevoie de valorile SAML sau OIDC acceptate: emitent, identificator de client, URL de apel invers sau de consumator de aserțiune, revendicări obligatorii și alocare. Accesibilitatea vine deasupra, pentru că verificările de identitate nu oferă niciodată o rută sau un răspuns DNS.

1. Creează intrarea aplicației și confirmă că ID-ul de entitate sau de client corespunde cu ceea ce trimite aplicația.
2. Înregistrează URL-ul exact de apel invers, inclusiv schema și portul; o eroare mică eșuează după ce utilizatorul se autentifică.
3. Alocă utilizatorii sau grupurile, apoi confirmă că revendicările necesare sunt emise.
4. Permite punctele finale ale furnizorului de identitate și aplicația privată, altfel redirecționarea nu se poate finaliza.

Contextul browserului decide dacă o sesiune existentă a furnizorului este reutilizată. Un client nativ care deschide browserul sistemului poate partaja acea stare, în timp ce o vizualizare încorporată cu propriul borcan de cookie-uri de obicei nu poate. Browser nou, ferestre private și un al doilea profil pornesc de la zero, ceea ce este de așteptat și nu o configurație SSO stricată.

Rulează fluxul și citește unde se oprește

Reproduce cu panoul de rețea al browserului și urmărește lanțul de redirecționări. O trecere utilă urmărește un salt odată: gateway la furnizor, furnizor înapoi la aplicație cu un cod sau o aserțiune, aplicație la punctul final de tokenuri al furnizorului, sesiunea aplicației emisă. Saltul în care lanțul se oprește numește componenta de reparat.

Două verificări din linia de comandă lămuresc îndoielile obișnuite și ambele sunt sigure de rulat de pe un host de administrare:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Când metadatele listează puncte finale pe care nu le-ai înregistrat niciodată, aplicația indică alt chiriaș sau emitent. Când prima cerere către aplicație răspunde 302 către un host neașteptat, configurația de federație a aplicației este locul de verificat, nu profilul VPN.

Remediază solicitările aflând cine le-a cerut

O a doua solicitare de parolă nu este automat un defect. Aplicația poate cere un nivel de asigurare mai ridicat, sau furnizorul poate impune o vârstă maximă a sesiunii și o nouă provocare. Eliminarea acestor cerințe pentru a face fluxul mai silențios slăbește un control deliberat, așa că stabilește ce componentă le-a cerut înainte de a schimba politica.

Apoi decide ce să îmbunătățești. Dacă solicitarea vine de la aplicație, remediază intrarea ei de federație. Dacă vine de la furnizor conform politicii, documentează cerința. Dacă aplicația este inaccesibilă după o autentificare reușită, rutarea tunelului este suspectul, pentru că identitatea și livrarea pachetelor eșuează în locuri diferite și arată similar din locul utilizatorului.