Ar VPN SSO automatiškai prisijungia naudotojus prie vidinių programų?

VPN šliuzas, kuris autentifikuojasi per tapatybės teikėją, įrodo vieną dalyką: teikėjas garantavo už naudotoją šliuzo atžvilgiu. Jis neduoda tam naudotojui prisijungimo duomenų intraneto viki, stebėjimo skydeliui ar kūrimo serveriui. Tos paslaugos prisijungia žmones per savo federaciją ir taiko savo autorizaciją, o tunelis tik nusprendžia, kurie paketai gali juos pasiekti.

Trys sesijos, trys atskiri sprendimai

Laikykite būsenas atskirai, nes kiekviena baigiasi pagal savo grafiką. VPN sesija yra šliuzo tapatybės priėmimas ir suteikta tinklo prieiga. Tapatybės teikėjo naršyklės sesija yra tai, ką naršyklė dar laiko tam teikėjui ir gali naudoti pakartotinai pagal jo politiką. Programos sesija priklauso vienai paslaugai, kuri patvirtino jai adresuotą atsakymą.

Sumaišius šias būsenas gaunamas neteisingas klausimas, paprastai suformuluotas kaip kodėl tunelis neprisijungia naudotojo visur. Performuluokite: kuri programa neturi federacijos įrašo, kuri atmeta naudotoją ir kuriai trūksta maršruto. Vienas prisijungimo raginimas, atidarantis intraneto programą, vis tiek gali grįžti pas teikėją, nes antrasis peradresavimas yra nauja autorizacijos užklausa kitai auditorijai.

Prijunkite šliuzą kaip atskirą programą

Užregistruokite VPN kaip patvirtintą programą teikėjo aplinkoje su savo identifikatoriumi, peradresavimo URI ir naudotojų priskyrimu. Tada nuspręskite, kokias tinklo autorizacijas suteikia tas prisijungimas, nes tai VPN politika, o ne teikėjo funkcija. Naudotojai, kurie turi pasiekti tik stebėjimo potinklį, gauna kitą šliuzo politiką, o ne kitą slaptažodį.

Tunelio autentifikavimo atsakymas nėra pakartotinai naudojami prisijungimo duomenys. OIDC ID žetonai turi auditorijos teiginį, nurodantį klientą, kuriam jie buvo išduoti, o SAML bearer teiginiai apriboja auditoriją priimančiu paslaugos teikėju. Antroji paslauga, kuri priima pirmosios atsakymą, sukonfigūruota neteisingai, o žetono kopijavimas į kitą programą nėra integracija.

Užregistruokite kiekvieną vidinę programą, tada nustatykite naršyklės kontekstą

Kiekvienai paslaugai reikia palaikomų SAML arba OIDC reikšmių: išdavėjo, kliento identifikatoriaus, atgalinio iškvietimo arba teiginio vartotojo URL, reikiamų teiginių ir priskyrimo. Pasiekiamumas ateina ant viršaus, nes tapatybės patikros niekada nesuteikia maršruto ar DNS atsakymo.

1. Sukurkite programos įrašą ir patvirtinkite, kad subjekto arba kliento ID atitinka tai, ką siunčia programa.
2. Užregistruokite tikslią atgalinio iškvietimo URL, įskaitant schemą ir prievadą; maža klaida nepavyksta po to, kai naudotojas autentifikuojasi.
3. Priskirkite naudotojus arba grupes, tada patvirtinkite, kad reikiami teiginiai išduodami.
4. Leiskite tapatybės teikėjo galinius taškus ir privačią programą, kitaip peradresavimas negalės baigtis.

Naršyklės kontekstas nusprendžia, ar bus pakartotinai naudojama esama teikėjo sesija. Savoji kliento programa, atidaranti sistemos naršyklę, gali bendrinti tą būseną, o įterptas rodinys su savo slapukų talpykla paprastai negali. Nauja naršyklė, privatūs langai ir antras profilis pradeda nuo nulio, o tai tikėtina, o ne sugedusi SSO konfigūracija.

Paleiskite srautą ir perskaitykite, kur jis sustoja

Atkurkite naudodami naršyklės tinklo skydelį ir stebėkite peradresavimų grandinę. Naudingas ėjimas seka vieną šuolį vienu metu: nuo šliuzo prie teikėjo, nuo teikėjo atgal į programą su kodu ar teiginiu, nuo programos prie teikėjo žetono galinio taško, išduodama programos sesija. Šuolis, kuriame grandinė sustoja, įvardija taisomą komponentą.

Du komandinės eilutės patikrinimai išsprendžia įprastas abejones, ir abu saugu paleisti iš administratoriaus kompiuterio:

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

Kai metaduomenys išvardija galinius taškus, kurių niekada neregistravote, programa nurodo į kitą nuomininką ar išdavėją. Kai pirmoji užklausa programai atsako 302 į netikėtą kompiuterį, žiūrėti reikia programos federacijos konfigūracijos, o ne VPN profilio.

Taisykite raginimus sužinodami, kas jų paprašė

Antras slaptažodžio raginimas savaime nėra defektas. Programa gali prašyti aukštesnio užtikrinimo lygio, arba teikėjas gali reikalauti didžiausio sesijos amžiaus ir naujo iššūkio. Tų reikalavimų pašalinimas, kad srautas būtų tylesnis, silpnina sąmoningą kontrolę, todėl prieš keisdami politiką nustatykite, kuris komponentas jų paprašė.

Tada nuspręskite, ką pagerinti. Jei raginimas ateina iš programos, taisykite jos federacijos įrašą. Jei pagal politiką ateina iš teikėjo, dokumentuokite reikalavimą. Jei po sėkmingo prisijungimo programa nepasiekiama, įtariamas tunelio maršrutizavimas, nes tapatybė ir paketų pristatymas nepavyksta skirtingose vietose ir atrodo panašiai iš naudotojo vietos.