Přihlašuje VPN SSO uživatele do interních aplikací automaticky?

Jedno přihlášení může pokrýt tunel i aplikace za ním, ale jen tehdy, když má každá aplikace vlastní důvěru. Zde je pořadí, ve kterém to propojit a otestovat.

VPN brána, která se ověřuje přes poskytovatele identity, dokazuje jedinou věc: poskytovatel se za uživatele zaručil vůči bráně. Nedává tomu uživateli žádný údaj pro přihlášení do intranetové wiki, monitorovacího panelu ani build serveru. Tyto služby přihlašují lidi přes vlastní federaci a uplatňují vlastní autorizaci a tunel jen rozhoduje, které pakety se k nim dostanou.

Tři relace, tři oddělená rozhodnutí

Držte stavy oddělené, protože každý vyprší podle vlastního plánu. Relace VPN je přijetí identity bránou plus síťový přístup, který udělila. Relace prohlížeče u poskytovatele identity je to, co prohlížeč pro tohoto poskytovatele stále drží a může podle jeho politiky znovu použít. Relace aplikace patří jedné službě, která ověřila odpověď adresovanou jí.

Záměna těchto stavů vede k nesprávné otázce, obvykle formulované jako proč tunel nepřihlásí uživatele všude. Přerámujte ji: která aplikace nemá záznam ve federaci, která uživatele odmítá a které chybí trasa. Jediná výzva k přihlášení, která otevře intranetovou aplikaci, se přesto může vrátit k poskytovateli, protože druhé přesměrování je nový požadavek na autorizaci pro jiné publikum.

Zapojte bránu jako vlastní aplikaci

Zaregistrujte VPN u poskytovatele jako schválenou aplikaci s vlastním identifikátorem, URI přesměrování a přiřazením uživatelů. Poté určete, jaká síťová oprávnění toto přihlášení uděluje, protože to je politika VPN, nikoli funkce poskytovatele. Uživatelé, kteří mají dosáhnout jen na monitorovací podsíť, dostanou jinou politiku brány, ne jiné heslo.

Odpověď tunelu při autentizaci není opakovaně použitelný údaj. Tokeny OIDC ID nesou tvrzení o publiku, které pojmenovává klienta, pro kterého byly vydány, a SAML bearer aserce omezují publikum na přijímajícího poskytovatele služby. Druhá služba, která přijme odpověď první, je špatně nakonfigurovaná, a kopírování tokenu do jiné aplikace není integrace.

Zaregistrujte každou interní aplikaci, pak nastavte kontext prohlížeče

Každá služba potřebuje podporované hodnoty SAML nebo OIDC: vydavatele, identifikátor klienta, URL pro zpětné volání nebo pro konzumenta aserce, požadovaná tvrzení a přiřazení. Dostupnost přichází navrch, protože ověření identity nikdy neposkytne trasu ani odpověď DNS.

  1. Vytvořte záznam aplikace a potvrďte, že ID entity nebo klienta odpovídá tomu, co aplikace odesílá.
  2. Zaregistrujte přesnou URL zpětného volání včetně schématu a portu; téměř správná hodnota selže poté, co se uživatel ověří.
  3. Přiřaďte uživatele nebo skupiny a poté potvrďte, že požadovaná tvrzení jsou vydávána.
  4. Povolte koncové body poskytovatele identity i privátní aplikaci, jinak přesměrování nemůže dokončit.

Kontext prohlížeče rozhoduje, zda se existující relace poskytovatele znovu použije. Nativní klient, který otevře systémový prohlížeč, může tento stav sdílet, zatímco vložené zobrazení s vlastní sadou cookies obvykle ne. Nový prohlížeč, soukromá okna a druhý profil začínají od nuly, což je očekávané, nikoli rozbitá konfigurace SSO.

Spusťte tok a přečtěte, kde se zastaví

Reprodukujte to pomocí síťového panelu prohlížeče a sledujte řetězec přesměrování. Užitečný průchod jde po jednom skoku: od brány k poskytovateli, od poskytovatele zpět do aplikace s kódem nebo asercí, od aplikace ke koncovému bodu tokenů poskytovatele, vydaná relace aplikace. Skok, na kterém se řetězec zastaví, pojmenuje komponentu k opravě.

Dvě kontroly z příkazového řádku vyřeší obvyklé pochybnosti a obě lze bezpečně spustit z administrativního hostitele:

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

Když metadata uvádějí koncové body, které jste nikdy nezaregistrovali, aplikace ukazuje na jiného tenanta nebo vydavatele. Když první požadavek na aplikaci odpoví 302 na neočekávaného hostitele, hledejte v konfiguraci federace aplikace, ne v profilu VPN.

Opravte výzvy tak, že najdete, kdo je vyžádal

Druhá výzva k zadání hesla není automaticky závada. Aplikace může žádat vyšší úroveň záruky, nebo poskytovatel může vynutit maximální stáří relace a novou výzvu. Odstranění těchto požadavků, aby byl tok tišší, oslabuje záměrnou kontrolu, proto nejprve zjistěte, která komponenta je vyžádala, a teprve potom měňte politiku.

Pak rozhodněte, co zlepšit. Pokud výzva přichází z aplikace, opravte její záznam ve federaci. Pokud přichází od poskytovatele z politiky, zdokumentujte požadavek. Pokud je aplikace po úspěšném přihlášení nedostupná, podezřelé je směrování tunelu, protože identita a doručování paketů selhávají na různých místech a z místa uživatele vypadají podobně.

Související články