Kas VPN SSO logib kasutajad siseäppidesse automaatselt sisse?

VPN-i lüüs, mis autentib identiteedipakkuja kaudu, tõestab üht: pakkuja käendas kasutajat lüüsi ees. See ei anna sellele kasutajale volikirja sisevõrgu viki, jälgimisarmatuuri ega koosteserveri jaoks. Need teenused logivad inimesi sisse omaenda föderatsiooni kaudu ja rakendavad omaenda autoriseerimist, ning tunnel otsustab ainult, millised paketid neid jõuda saavad.

Kolm seanssi, kolm eraldi otsust

Hoidke olekud lahus, sest igaüks lõpeb oma ajakava järgi. VPN-i seanss on lüüsi poolt identiteedi vastuvõtmine pluss antud võrguühendus. Identiteedipakkuja brauseriseanss on see, mida brauser selle pakkuja jaoks veel hoiab ja võib oma poliitika järgi uuesti kasutada. Äpiseanss kuulub ühele teenusele, mis valideeris talle adresseeritud vastuse.

Nende olekute segamini ajamine annab vale küsimuse, tavaliselt sõnastatud nii, miks tunnel ei logi kasutajat kõikjal sisse. Sõnastage see ümber: millisel äpil puudub föderatsioonikirje, milline keeldub kasutajast ja millisel puudub marsruut. Üks sisselogimisküsimine, mis avab sisevõrgu äpi, võib siiski pakkuja juurde tagasi hüpata, sest teine ümbersuunamine on uus autoriseerimistaotlus teisele publikule.

Ühendage lüüs omaette äpina

Registreerige VPN pakkuja juures kinnitatud äpina, oma identifikaatori, ümbersuunamis-URI ja kasutajamääranguga. Seejärel otsustage, milliseid võrguautoriseeringuid see sisselogimine annab, sest see on VPN-i poliitika, mitte pakkuja funktsioon. Kasutajad, kes peaksid jõudma ainult jälgimisalavõrku, saavad teistsuguse lüüsipoliitika, mitte teistsuguse parooli.

Tunneli autentimisvastus ei ole kordatav volikiri. OIDC ID-tokenid kannavad publiku väidet, mis nimetab kliendi, kelle jaoks need väljastati, ja SAML kandja kinnitused piiravad publiku vastuvõtva teenusepakkujaga. Teine teenus, mis võtab vastu esimese teenuse vastuse, on valesti konfigureeritud, ja tokeni kopeerimine teise äppi ei ole integreerimine.

Registreerige iga siseäpp, seejärel seadistage brauseri kontekst

Iga teenus vajab toetatud SAML- või OIDC-väärtusi: väljaandja, kliendiidentifikaator, tagasikutse- või kinnituskasutaja URL, nõutavad väited ja määrang. Kättesaadavus tuleb selle peale, sest identiteedikontrollid ei anna kunagi marsruuti ega DNS-vastust.

1. Looge äpikirje ja kinnitage, et üksuse või kliendi ID vastab sellele, mida äpp saadab.
2. Registreerige täpne tagasikutse-URL, sealhulgas skeem ja port; väike eksimus ebaõnnestub pärast kasutaja autentimist.
3. Määrake kasutajad või rühmad, seejärel kinnitage, et nõutavad väited väljastatakse.
4. Lubage identiteedipakkuja lõpp-punktid ja ka privaatne äpp, muidu ei saa ümbersuunamine lõppeda.

Brauseri kontekst otsustab, kas olemasolevat pakkuja seanssi kasutatakse uuesti. Süsteemibrauseri avav natiivklient saab seda olekut jagada, samas kui oma küpsisepurgiga manustatud vaade tavaliselt ei saa. Uus brauser, privaataknad ja teine profiil algavad nullist, mis on ootuspärane, mitte katkine SSO-konfiguratsioon.

Käivitage voog ja lugege, kus see peatub

Reprodutseerige brauseri võrgupaneeliga ja jälgige ümbersuunamiste ahelat. Kasulik läbimine järgib üht hüpet korraga: lüüsist pakkujani, pakkujast tagasi äppi koodi või kinnitusega, äpist pakkuja tokeni lõpp-punktini, äpiseanss väljastatud. Hüpe, kus ahel peatub, nimetab komponendi, mida parandada.

Kaks käsureakontrolli lahendavad tavalised kahtlused ja mõlemat on ohutu käivitada administraatori hostist:

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:)'

Kui metaandmed loetlevad lõpp-punkte, mida te kunagi ei registreerinud, osutab äpp teisele rentnikule või väljaandjale. Kui esimene taotlus äpile vastab 302 ootamatule hostile, tuleb vaadata äpi föderatsioonikonfiguratsiooni, mitte VPN-profiili.

Parandage küsimisi, leides, kes need esitas

Teine parooliküsimine ei ole automaatselt defekt. Äpp võib nõuda kõrgemat tagatise taset või pakkuja võib kehtestada seansi maksimaalse vanuse ja uue väljakutse. Nende nõuete eemaldamine, et voog oleks vaiksem, nõrgendab teadlikku kontrolli, seega tehke kindlaks, milline komponent seda küsis, enne kui poliitikat muudate.

Seejärel otsustage, mida parandada. Kui küsimine tuleb äpist, parandage selle föderatsioonikirje. Kui see tuleb pakkujalt poliitika järgi, dokumenteerige nõue. Kui äpp on pärast edukat sisselogimist kättesaamatu, on kahtlane tunneli marsruutimine, sest identiteet ja pakettide kohaletoimetamine ebaõnnestuvad erinevates kohtades ja näivad kasutaja istmelt sarnased.