Co se děje v kroku prohlížeče při federovaném přihlášení k VPN

Kliknete na Připojit a klient VPN vám místo pole pro heslo otevře prohlížeč. Toto předání mate lidi, kteří čekají, že se tunel ověří sám. Prohlížeč není objížďka: právě v něm poskytovatel identity skutečně ověří osobu a klient jen čeká na výsledek.

Sledování jednoho přihlášení od začátku do konce ukáže, ke kterému kroku patří která porucha, a přesně tuhle část většina runbooků vynechává.

Začněte u klienta, ne u konfigurace brány

Klient sestaví požadavek a pošle prohlížeč poskytovateli identity s identifikátorem poskytovatele služeb a adresou návratu. Potom IdP vaší organizace provede, co má nastaveno: heslo, MFA, kontrolu zařízení, podmíněný přístup. Pokud už prohlížeč má platnou relaci, viditelná část může trvat sekundu nebo dvě. Tahle krátkost je opětovné použití relace, ne vynechaná kontrola.

Než cokoli jiného, přečtěte si v konfiguraci federace klienta dvě hodnoty: metadata nebo URL IdP, kterému důvěřuje, a adresu zpětného volání, kterou očekává. Nesoulad tam selže dřív, než se napíše jakékoli heslo.

Co musí poskytovatel identity vrátit

IdP odpovídá podepsanou odpovědí SAML s tvrzením: kdo je subjekt, kdo ho vydal, komu je určen a jak dlouho platí. Tato pole jsou smlouva. Vydavatel, publikum, příjemce a okno platnosti musí odpovídat tomu, co služba očekává.

Odpověď podepsaná správným IdP, ale adresovaná jinému publiku, je pořád neplatná. To je kontrola, kterou lidé vynechávají, když kopírují metadata z laboratoře do produkce.

Co služba VPN ověří, než vám uvěří

Služba ověří podpis proti důvěryhodnému certifikátu, zkontroluje vydavatele, publikum a příjemce a potom vyhodnotí časové podmínky. Teprve pak namapuje tvrzení na uživatele nebo skupinu a použije autorizační politiku VPN. Ověření identity a autorizace jsou tu samostatné kroky a platné tvrzení bez odpovídající skupiny dá relaci, která se připojí a nikam nedosáhne.

Tvrzení je autentizační materiál, ne heslo. Vložit ho do jiného klienta nebo si ho nechat pro pozdější opětovné připojení není podporované přihlášení.

Dvě životnosti, které končí odděleně

Relace prohlížeče u IdP a relace VPN na bráně vyprší podle různých hodin. Odhlášení z IdP nutně nerozpojí zavedený tunel a odpojení tunelu vás neodhlásí z prohlížeče.

AWS Client VPN dokumentuje, že jeho federovaný tok nepodporuje jednotlivé odhlášení SAML, což je konkrétní příklad té mezery. Ověřte si vlastní službu, místo abyste předpokládali symetrii.

Proto se opětovné připojení chová jinak v 09:00 a v 15:00. Může tiše znovu použít relaci IdP, znovu požádat o MFA, nebo selhat, protože vypršela doba relace koncového bodu, zatímco relace prohlížeče ne. Pracovní postup federace AWS popisuje vlastní požadavky na klienta a odpověď a jiné služby používají jiná předání.

Když krok prohlížeče selže, zkontrolujte tohle v tomto pořadí

Pracujte od prohlížeče ven, protože chybová zpráva obvykle pojmenuje poslední, ne první skok.

Pokud se stránka nikdy nenačte, je URL IdP v klientovi nebo cesta k němu špatná. Pokud IdP požadavek odmítne, identifikátor poskytovatele služeb nebo zpětné volání neodpovídá jeho konfiguraci. Pokud prohlížeč ukáže úspěch a klient přesto selže, odpověď dorazila na špatné místo nebo neprošla ověřením publika a času. A pokud se tunel zvedne bez přístupu, tvrzení bylo přijato, ale mapování skupiny ne.

Mějte očekávanou stránku, zpětné volání a mapování skupin v jednom dokumentu. Pak uživatel, který nahlásí rozbité přihlášení k VPN, řekne, kterou z těch čtyř věcí viděl, a odpověď je z poloviny napsaná.