Vad som händer i webbläsarsteget vid en federerad VPN-inloggning

Du klickar på Anslut och i stället för ett lösenordsfält öppnar VPN-klienten din webbläsare. Den överlämningen förvirrar dem som förväntar sig att tunneln ska autentisera sig själv. Webbläsaren är ingen omväg: det är där identitetsleverantören faktiskt autentiserar personen, och klienten väntar bara på resultatet.

Att gå igenom en inloggning från början till slut visar var varje fel hör hemma, och det är just den delen de flesta runbooks hoppar över.

Börja i klienten, inte i gateway-konfigurationen

Klienten bygger en begäran och skickar webbläsaren till identitetsleverantören med en tjänsteleverantörsidentifierare och en returadress. Organisationens IdP kör sedan det den är konfigurerad för: lösenord, MFA, enhetskontroll, villkorlig åtkomst. Om webbläsaren redan har en giltig session kan den synliga delen ta en sekund eller två. Den kortheten är återanvändning av sessionen, inte en överhoppad kontroll.

Läs klientens federationskonfiguration efter två värden innan något annat: de IdP-metadata eller den URL som den litar på, och den callback-adress som den förväntar sig. En felaktighet där misslyckas innan något lösenord skrivs.

Vad identitetsleverantören måste returnera

IdP:n svarar med ett signerat SAML-svar som innehåller en assertion: vem subjektet är, vem som utfärdade det, vem det gäller och hur länge det är giltigt. Dessa fält är kontraktet. Utfärdare, audience, mottagare och giltighetsfönster måste alla stämma med det tjänsten förväntar sig.

Ett svar som signerats av rätt IdP men adresserats till en annan audience är fortfarande ogiltigt. Det är kontrollen folk hoppar över när de kopierar metadata mellan en labbmiljö och produktion.

Vad VPN-tjänsten validerar innan den litar på dig

Tjänsten verifierar signaturen mot det betrodda certifikatet, kontrollerar utfärdaren, audience och mottagaren och utvärderar sedan tidsvillkoren. Först därefter mappar den assertionen till en användare eller grupp och tillämpar VPN-auktoriseringspolicyn. Autentisering och auktorisering är separata steg här, och en giltig assertion utan matchande grupp ger en session som ansluter och inte når något.

Assertionen är autentiseringsmaterial, inte ett lösenord. Att klistra in den i en annan klient, eller spara den för en senare återanslutning, är inte en inloggning som stöds.

Två livslängder som slutar var för sig

Webbläsarsessionen hos IdP:n och VPN-sessionen i gatewayen löper ut på olika klockor. Att logga ut från IdP:n river inte nödvändigtvis en etablerad tunnel, och att koppla från tunneln loggar inte ut dig från webbläsaren.

AWS Client VPN dokumenterar att dess federerade flöde inte stöder SAML single logout, vilket är ett konkret exempel på gapet. Kontrollera din egen tjänst i stället för att anta symmetri.

Det är därför en återanslutning beter sig olika kl. 09:00 och kl. 15:00. Den kan återanvända IdP-sessionen tyst, fråga efter MFA igen, eller misslyckas för att slutpunktens sessionslängd gick ut medan webbläsarsessionen inte gjorde det. AWS federationsarbetsflöde beskriver sina egna krav på klient och svar, och andra tjänster använder andra överlämningar.

När webbläsarsteget misslyckas, kontrollera dessa i ordning

Arbeta från webbläsaren och utåt, eftersom felmeddelandet oftast namnger det sista hoppet i stället för det första.

Om sidan aldrig laddas är klientens IdP-URL eller sökvägen till den fel. Om IdP:n avvisar begäran stämmer inte tjänsteleverantörsidentifieraren eller callbacken med dess konfiguration. Om webbläsaren visar framgång och klienten ändå misslyckas nådde svaret fel plats eller misslyckades med audience- och tidsvalidering. Och om tunneln kommer upp utan åtkomst godtogs assertionen, men gruppmappningen gjorde det inte.

Håll den förväntade sidan, callbacken och gruppmappningen i ett dokument. Då kan en användare som rapporterar en trasig VPN-inloggning säga vilken av dessa fyra saker de såg, och svaret är redan halvskrivet.