Ali VPN SSO samodejno prijavi uporabnike v notranje aplikacije?

Prehod VPN, ki se preverja prek ponudnika identitete, dokazuje eno stvar: ponudnik je jamčil za uporabnika pred prehodom. Temu uporabniku ne izroči poverilnic za intranetni wiki, nadzorno ploščo ali strežnik za gradnjo. Te storitve prijavljajo ljudi prek lastne federacije in uporabljajo lastno avtorizacijo, tunel pa le odloča, kateri paketi lahko pridejo do njih.

Tri seje, tri ločene odločitve

Stanja hranite ločeno, ker vsako poteče po svojem urniku. Seja VPN je sprejem identitete s strani prehoda in omrežni dostop, ki ga je dodelil. Seja brskalnika pri ponudniku identitete je tisto, kar brskalnik še hrani za tega ponudnika in lahko znova uporabi v skladu z njegovo politiko. Seja aplikacije pripada eni storitvi, ki je overila odgovor, naslovljen nanjo.

Mešanje teh stanj ustvari napačno vprašanje, običajno oblikovano kot zakaj tunel ne prijavi uporabnika povsod. Preoblikujte ga: katera aplikacija nima vnosa v federaciji, katera zavrača uporabnika in kateri manjka pot. Ena poziv k prijavi, ki odpre intranetno aplikacijo, se lahko vseeno vrne k ponudniku, ker je druga preusmeritev nova zahteva za avtorizacijo za drugo občinstvo.

Povežite prehod kot lastno aplikacijo

Registrirajte VPN pri ponudniku kot odobreno aplikacijo z lastnim identifikatorjem, URI preusmeritve in dodelitvijo uporabnikov. Nato določite, katere omrežne avtorizacije daje ta prijava, saj je to politika VPN in ne funkcija ponudnika. Uporabniki, ki naj dosežejo le nadzorno podomrežje, dobijo drugo politiko prehoda, ne drugega gesla.

Odgovor preverjanja pristnosti tunela ni poverilnica za večkratno uporabo. Žetoni OIDC ID nosijo trditev občinstva, ki imenuje odjemalca, za katerega so bili izdani, in SAML bearer trditve omejujejo občinstvo na ponudnika storitve, ki jih prejme. Druga storitev, ki sprejme odgovor prve, je napačno konfigurirana, kopiranje žetona v drugo aplikacijo pa ni integracija.

Registrirajte vsako notranjo aplikacijo, nato nastavite kontekst brskalnika

Vsaka storitev potrebuje podprte vrednosti SAML ali OIDC: izdajatelja, identifikator odjemalca, URL povratnega klica ali potrošnika trditve, zahtevane trditve in dodelitev. Dosegljivost pride na vrh, ker preverjanja identitete nikoli ne zagotovijo poti ali odgovora DNS.

1. Ustvarite vnos aplikacije in potrdite, da se ID entitete ali odjemalca ujema s tem, kar pošilja aplikacija.
2. Registrirajte natančen URL povratnega klica, vključno s shemo in vrati; majhna napaka spodleti po preverjanju uporabnika.
3. Dodelite uporabnike ali skupine, nato potrdite, da se zahtevane trditve izdajo.
4. Dovolite končne točke ponudnika identitete in zasebno aplikacijo, sicer preusmeritev ne more dokončati.

Kontekst brskalnika odloči, ali se obstoječa seja ponudnika znova uporabi. Izvorni odjemalec, ki odpre sistemski brskalnik, lahko deli to stanje, vdelani pogled z lastnim kozarcem piškotkov pa običajno ne more. Nov brskalnik, zasebna okna in drugi profil začnejo od nič, kar je pričakovano in ne pokvarjena konfiguracija SSO.

Zaženite tok in preberite, kje se ustavi

Ponovite z omrežno ploščo brskalnika in opazujte verigo preusmeritev. Uporaben prehod sledi enemu skoku naenkrat: od prehoda k ponudniku, od ponudnika nazaj v aplikacijo s kodo ali trditvijo, od aplikacije do končne točke žetonov ponudnika, izdana seja aplikacije. Skok, na katerem se veriga ustavi, poimenuje komponento za popravilo.

Dva pregleda iz ukazne vrstice razrešita običajne dvome in oba je varno zagnati z administrativnega gostitelja:

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

Ko metapodatki naštejejo končne točke, ki jih nikoli niste registrirali, aplikacija kaže na drugega najemnika ali izdajatelja. Ko prva zahteva do aplikacije odgovori 302 na nepričakovanega gostitelja, je treba pogledati v konfiguracijo federacije aplikacije, ne v profil VPN.

Popravite pozive tako, da ugotovite, kdo jih je zahteval

Drugi poziv za geslo ni samodejno napaka. Aplikacija lahko zahteva višjo raven zagotovila, ali ponudnik lahko vsili največjo starost seje in nov izziv. Odstranjevanje teh zahtev, da bi bil tok tišji, oslabi namerno kontrolo, zato najprej ugotovite, katera komponenta jih je zahtevala, preden spremenite politiko.

Nato odločite, kaj izboljšati. Če poziv prihaja iz aplikacije, popravite njen vnos v federaciji. Če prihaja od ponudnika po politiki, dokumentirajte zahtevo. Če aplikacija po uspešni prijavi ni dosegljiva, je sumljivo usmerjanje tunela, ker identiteta in dostava paketov spodletita na različnih mestih in sta z uporabnikovega stola videti podobno.