Automatikusan bejelentkezteti a VPN SSO a felhasználókat a belső alkalmazásokba?

Az identitásszolgáltatón keresztül hitelesítő VPN-átjáró egyetlen dolgot bizonyít: a szolgáltató jótállt egy felhasználóért az átjárónál. Nem ad annak a felhasználónak hitelesítő adatot az intranet wikijéhez, a monitorozási irányítópulthoz vagy a build-szerverhez. Ezek a szolgáltatások a saját föderációjukon keresztül jelentkeztetik be az embereket, és a saját engedélyezésüket alkalmazzák, az alagút pedig csak azt dönti el, mely csomagok érhetik el őket.

Három munkamenet, három külön döntés

Tartsa külön az állapotokat, mert mindegyik a saját ütemezése szerint jár le. A VPN-munkamenet az átjáró identitás-elfogadása plusz az általa adott hálózati hozzáférés. Az identitásszolgáltatónál lévő böngésző-munkamenet az, amit a böngésző még tart a szolgáltatónak, és a szabályzata szerint újra felhasználhat. Az alkalmazás-munkamenet egyetlen szolgáltatáshoz tartozik, amely érvényesített egy hozzá címzett választ.

Ezeknek az állapotoknak az összekeverése a rossz kérdést eredményezi, amelyet általában úgy fogalmaznak meg, miért nem jelentkezteti be az alagút a felhasználót mindenhol. Fogalmazza újra: melyik alkalmazásnak nincs föderációs bejegyzése, melyik utasítja el a felhasználót, és melyikből hiányzik egy útvonal. Egyetlen bejelentkezési kérés, amely megnyitja az intranet alkalmazást, még mindig visszapattanhat a szolgáltatóhoz, mert a második átirányítás új engedélyezési kérés egy másik közönség számára.

Kötse be az átjárót saját alkalmazásként

Regisztrálja a VPN-t jóváhagyott alkalmazásként a szolgáltatónál, saját azonosítóval, átirányítási URI-val és felhasználó-hozzárendeléssel. Ezután döntse el, milyen hálózati engedélyeket ad ez a bejelentkezés, mert ez VPN-szabályzat, nem szolgáltatói funkció. A felhasználók, akiknek csak a monitorozási alhálózatot kell elérniük, más átjáró-szabályzatot kapnak, nem más jelszót.

Az alagút hitelesítési válasza nem újrafelhasználható hitelesítő adat. Az OIDC ID-tokenek közönség-állítást hordoznak, amely megnevezi az ügyfelet, amelynek kiadták őket, a SAML bearer állítások pedig a fogadó szolgáltatóra korlátozzák a közönséget. Egy második szolgáltatás, amely elfogadja az első válaszát, hibásan van konfigurálva, és a token másik alkalmazásba másolása nem integráció.

Regisztráljon minden belső alkalmazást, majd állítsa be a böngésző kontextusát

Minden szolgáltatásnak szüksége van a támogatott SAML- vagy OIDC-értékekre: kibocsátó, ügyfél-azonosító, visszahívási vagy állítás-fogyasztó URL, szükséges állítások és hozzárendelés. Az elérhetőség ezen felül jön, mert az identitás-ellenőrzések soha nem adnak útvonalat vagy DNS-választ.

1. Hozza létre az alkalmazásbejegyzést, és erősítse meg, hogy az entitás- vagy ügyfél-azonosító megegyezik azzal, amit az alkalmazás küld.
2. Regisztrálja a pontos visszahívási URL-t, beleértve a sémát és a portot; egy kis eltérés a felhasználó hitelesítése után meghiúsul.
3. Rendelje hozzá a felhasználókat vagy csoportokat, majd erősítse meg, hogy a szükséges állítások kiadásra kerülnek.
4. Engedélyezze az identitásszolgáltató végpontjait és a privát alkalmazást is, különben az átirányítás nem tud befejeződni.

A böngésző kontextusa dönti el, hogy egy meglévő szolgáltatói munkamenet újra felhasználható-e. A rendszerböngészőt megnyitó natív kliens megoszthatja ezt az állapotot, míg a saját cookie-tárolóval rendelkező beágyazott nézet általában nem. Az új böngésző, a privát ablakok és a második profil nulláról indulnak, ami várható, és nem elromlott SSO-konfiguráció.

Futtassa a folyamatot, és olvassa le, hol áll meg

Reprodukálja a böngésző hálózati paneljével, és figyelje az átirányítási láncot. Egy hasznos végigjárás egyszerre egy ugrást követ: átjárótól a szolgáltatóhoz, a szolgáltatótól vissza az alkalmazáshoz kóddal vagy állítással, az alkalmazástól a szolgáltató token-végpontjához, kiadott alkalmazás-munkamenet. Az az ugrás, ahol a lánc megáll, megnevezi a javítandó komponenst.

Két parancssori ellenőrzés tisztázza a szokásos kételyeket, és mindkettő biztonságosan futtatható adminisztrátori gazdagépről:

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

Amikor a metaadatok olyan végpontokat sorolnak fel, amelyeket soha nem regisztrált, az alkalmazás más bérlőre vagy kibocsátóra mutat. Amikor az alkalmazáshoz intézett első kérés 302-vel válaszol egy váratlan gazdagépre, az alkalmazás föderációs konfigurációja a vizsgálandó hely, nem a VPN-profil.

Javítsa a kéréseket azzal, hogy megtalálja, ki kérte

A második jelszókérés nem automatikusan hiba. Az alkalmazás magasabb bizonyossági szintet kérhet, vagy a szolgáltató maximális munkamenet-életkort és új kihívást kényszeríthet ki. Ezeknek a követelményeknek az eltávolítása, hogy a folyamat csendesebb legyen, gyengíti a szándékos ellenőrzést, ezért a szabályzat módosítása előtt állapítsa meg, melyik komponens kérte.

Ezután döntse el, mit javítson. Ha a kérés az alkalmazástól jön, javítsa a föderációs bejegyzését. Ha a szolgáltatótól jön szabályzat szerint, dokumentálja a követelményt. Ha az alkalmazás sikeres bejelentkezés után elérhetetlen, az alagút útválasztása a gyanús, mert az identitás és a csomagtovábbítás különböző helyeken hibázik és a felhasználó helyéről nézve hasonlónak tűnnek.