A i fut VPN SSO përdoruesit automatikisht në aplikacionet e brendshme?

Një portë VPN që autentikohet përmes një ofruesi identiteti provon një gjë: ofruesi garantoi për një përdorues përpara portës. Ajo nuk i jep atij përdoruesi kredenciale për wiki-n e intranetit, panelin e monitorimit ose serverin e ndërtimit. Këto shërbime i fusin njerëzit përmes federatës së tyre dhe zbatojnë autorizimin e tyre, dhe tuneli vendos vetëm cilat paketa mund t'i arrijnë ato.

Tre sesione, tre vendime të ndara

Mbajini gjendjet të ndara, sepse secila skadon sipas planit të vet. Sesioni VPN është pranimi i një identiteti nga porta plus qasja në rrjet që ajo dha. Sesioni i shfletuesit te ofruesi i identitetit është ajo që shfletuesi mban ende për atë ofrues dhe mund të ripërdoret sipas politikës së tij. Sesioni i aplikacionit i përket një shërbimi të vetëm që vërtetoi një përgjigje drejtuar atij.

Përzierja e këtyre gjendjeve prodhon pyetjen e gabuar, e formuluar zakonisht si pse tuneli nuk e fut përdoruesin kudo. Riformulojeni: cili aplikacion nuk ka hyrje federate, cili e refuzon përdoruesin dhe cilit i mungon një rrugë. Një kërkesë e vetme hyrjeje që hap aplikacionin e intranetit mund të kthehet përsëri te ofruesi, sepse ridrejtimi i dytë është një kërkesë e re autorizimi për një audiencë tjetër.

Lidheni portën si aplikacionin e vet

Regjistroni VPN-në si aplikacion të miratuar te ofruesi, me identifikuesin, URI-në e ridrejtimit dhe caktimin e përdoruesve të vet. Pastaj vendosni cilat autorizime rrjeti jep ajo hyrje, sepse është politikë VPN dhe jo veçori e ofruesit. Përdoruesit që duhet të arrijnë vetëm nënnrrjetin e monitorimit marrin një politikë tjetër porte, jo një fjalëkalim tjetër.

Përgjigja e autentikimit të tunelit nuk është kredencial i ripërdorshëm. Token-at ID të OIDC mbajnë një pretendim audiencë që emërton klientin për të cilin u lëshuan, dhe deklaratat mbartëse SAML e kufizojnë audiencën te ofruesi i shërbimit që i pranon. Një shërbim i dytë që pranon përgjigjen e të parit është konfiguruar gabimisht, dhe kopjimi i një token-i në një aplikacion tjetër nuk është integrim.

Regjistroni çdo aplikacion të brendshëm, pastaj vendosni kontekstin e shfletuesit

Çdo shërbim ka nevojë për vlerat SAML ose OIDC të mbështetura: lëshuesi, identifikuesi i klientit, URL-ja e kthimit ose e konsumatorit të deklaratës, pretendimet e kërkuara dhe caktimi. Arritshmëria vjen sipër, sepse kontrollet e identitetit nuk ofrojnë kurrë një rrugë ose një përgjigje DNS.

1. Krijoni hyrjen e aplikacionit dhe konfirmoni që ID-ja e entitetit ose e klientit përputhet me atë që dërgon aplikacioni.
2. Regjistroni URL-në e saktë të kthimit, duke përfshirë skemën dhe portin; një gabim i vogël dështon pas autentikimit të përdoruesit.
3. Caktoni përdoruesit ose grupet, pastaj konfirmoni që pretendimet e kërkuara lëshohen.
4. Lejoni pikat fundore të ofruesit të identitetit dhe aplikacionin privat, përndryshe ridrejtimi nuk mund të përfundojë.

Konteksti i shfletuesit vendos nëse një sesion ekzistues i ofruesit ripërdoret. Një klient vendas që hap shfletuesin e sistemit mund ta ndajë atë gjendje, ndërsa një pamje e integruar me kavanozin e vet të cookies zakonisht nuk mundet. Shfletues i ri, dritare private dhe një profil i dytë fillojnë nga zeroja, gjë që pritet dhe nuk është konfigurim SSO i prishur.

Ekzekutoni rrjedhën dhe lexoni ku ndalon

Riprodhojeni me panelin e rrjetit të shfletuesit dhe vëzhgoni zinxhirin e ridrejtimeve. Një kalim i dobishëm ndjek një kërcim në një kohë: nga porta te ofruesi, nga ofruesi përsëri te aplikacioni me një kod ose deklaratë, nga aplikacioni te pika fundore e token-ave të ofruesit, sesioni i aplikacionit lëshohet. Kërcimi ku ndalon zinxhiri emërton komponentin për t'u rregulluar.

Dy kontrolle të rreshtit të komandave zgjidhin dyshimet e zakonshme, dhe të dyja janë të sigurta të ekzekutohen nga një host administrimi:

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

Kur metadatat listojnë pika fundore që nuk i keni regjistruar kurrë, aplikacioni tregon një qiramarrës ose lëshues tjetër. Kur kërkesa e parë drejt aplikacionit përgjigjet 302 drejt një hosti të papritur, konfigurimi i federatës së aplikacionit është vendi për të shikuar, jo profili VPN.

Rregulloni kërkesat duke gjetur kush i kërkoi

Një kërkesë e dytë fjalëkalimi nuk është automatikisht defekt. Aplikacioni mund të kërkojë një nivel më të lartë sigurie, ose ofruesi mund të imponojë një moshë maksimale sesioni dhe një sfidë të re. Heqja e këtyre kërkesave për ta bërë rrjedhën më të qetë dobëson një kontroll të qëllimshëm, prandaj përcaktoni cili komponent i kërkoi përpara se të ndryshoni politikën.

Pastaj vendosni çfarë të përmirësoni. Nëse kërkesa vjen nga aplikacioni, rregulloni hyrjen e tij federate. Nëse vjen nga ofruesi sipas politikës, dokumentoni kërkesën. Nëse aplikacioni është i paarritshëm pas një hyrjeje të suksesshme, dyshohet rrugëtimi i tunelit, sepse identiteti dhe dorëzimi i paketave dështojnë në vende të ndryshme dhe duken njësoj nga vendi i përdoruesit.