Prijavljuje li VPN SSO korisnike automatski u interne aplikacije?

VPN gateway koji se autentificira putem davatelja identiteta dokazuje samo jedno: davatelj je jamčio za korisnika pred gatewayem. On tom korisniku ne daje vjerodajnicu za intranet wiki, nadzornu ploču ili poslužitelj za izgradnju. Te usluge prijavljuju ljude kroz vlastitu federaciju i primjenjuju vlastitu autorizaciju, a tunel samo odlučuje koji paketi mogu do njih stići.

Tri sesije, tri odvojene odluke

Držite stanja odvojeno jer svako istječe po vlastitom rasporedu. VPN sesija je prihvaćanje identiteta od strane gatewaya plus mrežni pristup koji je dodijelio. Sesija preglednika kod davatelja identiteta je ono što preglednik još drži za tog davatelja i može ponovno koristiti prema njegovoj politici. Sesija aplikacije pripada jednoj usluzi koja je validirala odgovor upućen njoj.

Miješanje tih stanja daje pogrešno pitanje, obično formulirano kao zašto tunel ne prijavljuje korisnika svugdje. Preformulirajte: koja aplikacija nema unos u federaciji, koja odbija korisnika i kojoj nedostaje ruta. Jedan upit za prijavu koji otvara intranet aplikaciju ipak može skočiti natrag na davatelja, jer je drugo preusmjeravanje novi zahtjev za autorizaciju za drugu publiku.

Povežite gateway kao vlastitu aplikaciju

Registrirajte VPN kao odobrenu aplikaciju kod davatelja, s vlastitim identifikatorom, URI-jem preusmjeravanja i dodjelom korisnika. Zatim odredite koje mrežne autorizacije ta prijava daje, jer je to VPN politika, a ne značajka davatelja. Korisnici koji trebaju dosezati samo nadzornu podmrežu dobivaju drugu gateway politiku, a ne drugu lozinku.

Odgovor autentifikacije tunela nije vjerodajnica za višekratnu upotrebu. OIDC ID tokeni nose tvrdnju publike koja imenuje klijenta za kojeg su izdani, a SAML bearer tvrdnje ograničavaju publiku na davatelja usluge koji ih prima. Druga usluga koja prihvaća odgovor prve usluge pogrešno je konfigurirana, a kopiranje tokena u drugu aplikaciju nije integracija.

Registrirajte svaku internu aplikaciju, zatim postavite kontekst preglednika

Svaka usluga treba podržane SAML ili OIDC vrijednosti: izdavatelja, identifikator klijenta, URL za povratni poziv ili za potrošača tvrdnje, potrebne tvrdnje i dodjelu. Dostupnost dolazi povrh toga jer provjere identiteta nikada ne daju rutu ni odgovor DNS-a.

1. Izradite unos aplikacije i potvrdite da se ID entiteta ili klijenta podudara s onim što aplikacija šalje.
2. Registrirajte točan URL povratnog poziva uključujući shemu i port; blizak promašaj pada nakon što se korisnik autentificira.
3. Dodijelite korisnike ili grupe, zatim potvrdite da su potrebne tvrdnje izdane.
4. Dopustite krajnje točke davatelja identiteta kao i privatnu aplikaciju, inače se preusmjeravanje ne može dovršiti.

Kontekst preglednika odlučuje hoće li se postojeća sesija davatelja ponovno koristiti. Izvorni klijent koji otvara sistemski preglednik može dijeliti to stanje, dok ugrađeni prikaz s vlastitom posudicom za kolačiće to obično ne može. Novi preglednik, privatni prozori i drugi profil počinju od ničega, što je očekivano, a ne pokvarena SSO konfiguracija.

Pokrenite tok i pročitajte gdje se zaustavlja

Reproducirajte s mrežnom pločom preglednika i promatrajte lanac preusmjeravanja. Koristan prolaz slijedi jedan skok po jedan: gateway do davatelja, davatelj natrag u aplikaciju s kodom ili tvrdnjom, aplikacija do krajnje točke tokena davatelja, izdana sesija aplikacije. Skok na kojem se lanac zaustavlja imenuje komponentu koju treba popraviti.

Dvije provjere iz naredbenog retka rješavaju uobičajene nedoumice i obje je sigurno pokrenuti s administratorskog hosta:

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

Kada metapodaci navode krajnje točke koje nikada niste registrirali, aplikacija pokazuje na drugog zakupca ili izdavatelja. Kada prvi zahtjev prema aplikaciji odgovori 302 na neočekivani host, konfiguracija federacije aplikacije mjesto je za pregled, a ne VPN profil.

Ispravite upite tako što ćete pronaći tko ih je zatražio

Drugi upit za lozinku nije automatski nedostatak. Aplikacija može zatražiti višu razinu osiguranja, ili davatelj može nametnuti najveću starost sesije i novi izazov. Uklanjanje tih zahtjeva kako bi tok bio tiši slabi namjernu kontrolu, pa prije promjene politike utvrdite koja je komponenta zatražila.

Zatim odlučite što poboljšati. Ako upit dolazi od aplikacije, popravite njezin unos u federaciji. Ako dolazi od davatelja po politici, dokumentirajte zahtjev. Ako je aplikacija nedostupna nakon uspješne prijave, sumnjivo je usmjeravanje tunela, jer identitet i dostava paketa padaju na različitim mjestima i izgledaju slično s korisnikova mjesta.