Prihlasuje VPN SSO používateľov do interných aplikácií automaticky?

VPN brána, ktorá sa overuje cez poskytovateľa identity, dokazuje jednu vec: poskytovateľ sa za používateľa zaručil voči bráne. Nedáva tomu používateľovi prihlasovacie údaje do intranetovej wiki, monitorovacieho panela ani build servera. Tieto služby prihlasujú ľudí cez vlastnú federáciu a uplatňujú vlastnú autorizáciu a tunel iba rozhoduje, ktoré pakety sa k nim dostanú.

Tri relácie, tri oddelené rozhodnutia

Držte stavy oddelene, pretože každý vyprší podľa vlastného plánu. Relácia VPN je prijatie identity bránou plus sieťový prístup, ktorý udelila. Relácia prehliadača u poskytovateľa identity je to, čo prehliadač pre tohto poskytovateľa stále drží a môže podľa jeho politiky znova použiť. Relácia aplikácie patrí jednej službe, ktorá overila odpoveď adresovanú jej.

Zámena týchto stavov vedie k nesprávnej otázke, zvyčajne formulovanej ako prečo tunel neprihlási používateľa všade. Preformulujte ju: ktorá aplikácia nemá záznam vo federácii, ktorá používateľa odmieta a ktorej chýba trasa. Jedna výzva na prihlásenie, ktorá otvorí intranetovú aplikáciu, sa predsa môže vrátiť k poskytovateľovi, pretože druhé presmerovanie je nová požiadavka na autorizáciu pre iné publikum.

Pripojte bránu ako vlastnú aplikáciu

Zaregistrujte VPN u poskytovateľa ako schválenú aplikáciu s vlastným identifikátorom, URI presmerovania a priradením používateľov. Potom určte, aké sieťové autorizácie toto prihlásenie udeľuje, keďže je to politika VPN, nie funkcia poskytovateľa. Používatelia, ktorí majú dosiahnuť iba monitorovaciu podsiev, dostanú inú politiku brány, nie iné heslo.

Odpoveď tunela pri autentizácii nie je opakovane použiteľný údaj. Tokeny OIDC ID nesú tvrdenie o publiku, ktoré pomenúva klienta, pre ktorého boli vydané, a SAML bearer asercie obmedzujú publikum na prijímajúceho poskytovateľa služby. Druhá služba, ktorá prijme odpoveď prvej, je nesprávne nakonfigurovaná, a kopírovanie tokenu do inej aplikácie nie je integrácia.

Zaregistrujte každú internú aplikáciu, potom nastavte kontext prehliadača

Každá služba potrebuje podporované hodnoty SAML alebo OIDC: vydavateľa, identifikátor klienta, URL spätného volania alebo konzumenta asercie, požadované tvrdenia a priradenie. Dostupnosť prichádza navrch, pretože overenia identity nikdy neposkytnú trasu ani odpoveď DNS.

1. Vytvorte záznam aplikácie a potvrďte, že ID entity alebo klienta zodpovedá tomu, čo aplikácia odosiela.
2. Zaregistrujte presnú URL spätného volania vrátane schémy a portu; takmer správna hodnota zlyhá po overení používateľa.
3. Priraďte používateľov alebo skupiny a potom potvrďte, že požadované tvrdenia sa vydávajú.
4. Povoľte koncové body poskytovateľa identity aj privátnu aplikáciu, inak presmerovanie nemôže dokončiť.

Kontext prehliadača rozhoduje, či sa existujúca relácia poskytovateľa znova použije. Natívny klient, ktorý otvorí systémový prehliadač, môže tento stav zdieľať, zatiaľ čo vložené zobrazenie s vlastnou sadou cookies zvyčajne nie. Nový prehliadač, súkromné okná a druhý profil začínajú od nuly, čo je očakávané, nie pokazená konfigurácia SSO.

Spustite tok a prečítajte, kde sa zastaví

Reprodukujte to pomocou sieťového panela prehliadača a sledujte reťazec presmerovaní. Užitočný prechod ide po jednom skoku: od brány k poskytovateľovi, od poskytovateľa späť do aplikácie s kódom alebo aserciou, od aplikácie ku koncovému bodu tokenov poskytovateľa, vydaná relácia aplikácie. Skok, na ktorom sa reťazec zastaví, pomenúva komponent na opravu.

Dve kontroly z príkazového riadka vyriešia obvyklé pochybnosti a obe sa dajú bezpečne spustiť z administratívneho hostiteľa:

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

Keď metadáta uvádzajú koncové body, ktoré ste nikdy nezaregistrovali, aplikácia ukazuje na iného nájomníka alebo vydavateľa. Keď prvá požiadavka na aplikáciu odpovie 302 na neočakávaného hostiteľa, hľadajte v konfigurácii federácie aplikácie, nie v profile VPN.

Opravte výzvy tak, že zistíte, kto ich vyžiadal

Druhá výzva na heslo nie je automaticky chyba. Aplikácia môže žiadať vyššiu úroveň záruky, alebo poskytovateľ môže vynútiť maximálny vek relácie a novú výzvu. Odstránenie týchto požiadaviek, aby bol tok tichší, oslabuje zámernú kontrolu, preto najprv zistite, ktorý komponent ich vyžiadal, a až potom meňte politiku.

Potom rozhodnite, čo zlepšiť. Ak výzva prichádza z aplikácie, opravte jej záznam vo federácii. Ak prichádza od poskytovateľa podľa politiky, zdokumentujte požiadavku. Ak je aplikácia po úspešnom prihlásení nedostupná, podozrivé je smerovanie tunela, pretože identita a doručovanie paketov zlyhávajú na rôznych miestach a z miesta používateľa vyzerajú podobne.