Wat er gebeurt in de browserstap van een federatieve VPN-login

Je klikt op Verbinden en in plaats van een wachtwoordveld opent de VPN-client je browser. Die overdracht verwart mensen die verwachten dat de tunnel zichzelf authenticeert. De browser is geen omweg: daar authenticeert de identiteitsprovider daadwerkelijk de persoon, en de client wacht alleen op het resultaat.

Eén aanmelding van begin tot eind doorlopen laat zien waar elke fout thuishoort, en dat is precies het deel dat de meeste runbooks overslaan.

Begin bij de client, niet bij de gatewayconfiguratie

De client bouwt een verzoek en stuurt de browser naar de identiteitsprovider met een serviceprovider-identificatie en een retourlocatie. De IdP van je organisatie voert vervolgens uit wat ervoor is geconfigureerd: wachtwoord, MFA, devicecontrole, voorwaardelijke toegang. Als de browser al een geldige sessie heeft, kan het zichtbare deel een seconde of twee duren. Die kortheid is hergebruik van de sessie, geen overgeslagen controle.

Lees in de federatieconfiguratie van de client eerst twee waarden: de IdP-metadata of URL die hij vertrouwt, en het callbackadres dat hij verwacht. Een mismatch daar faalt voordat er een wachtwoord is getypt.

Wat de identiteitsprovider moet teruggeven

De IdP antwoordt met een ondertekende SAML-response met daarin een assertion: wie het subject is, wie hem heeft uitgegeven, voor wie hij bedoeld is en hoe lang hij geldig blijft. Die velden zijn het contract. Issuer, audience, recipient en geldigheidsvenster moeten allemaal overeenkomen met wat de service verwacht.

Een response die door de juiste IdP is ondertekend maar aan een andere audience is gericht, is nog steeds ongeldig. Dat is de controle die mensen overslaan wanneer ze metadata tussen een lab en productie kopiëren.

Wat de VPN-service valideert voordat hij je vertrouwt

De service verifieert de handtekening tegen het vertrouwde certificaat, controleert de issuer, de audience en de recipient en beoordeelt daarna de tijdsvoorwaarden. Pas daarna koppelt hij de assertion aan een gebruiker of groep en past hij het VPN-autorisatiebeleid toe. Authenticatie en autorisatie zijn hier aparte stappen, en een geldige assertion zonder overeenkomende groep levert een sessie op die verbindt en niets bereikt.

De assertion is authenticatiemateriaal, geen wachtwoord. Hem in een andere client plakken, of bewaren voor een latere herverbinding, is geen ondersteunde login.

Twee levensduren die apart eindigen

De browsersessie bij de IdP en de VPN-sessie op de gateway verlopen op verschillende klokken. Uitloggen bij de IdP breekt een bestaande tunnel niet per se af, en de tunnel verbreken logt je niet uit bij de browser.

AWS Client VPN documenteert dat de federatieve flow geen SAML single logout ondersteunt, wat één concreet voorbeeld van de kloof is. Controleer je eigen service in plaats van symmetrie aan te nemen.

Daarom gedraagt een herverbinding zich anders om 09:00 en om 15:00. Hij kan de IdP-sessie stil hergebruiken, opnieuw om MFA vragen, of falen omdat de sessieduur van het endpoint is verlopen terwijl de browsersessie dat niet was. De AWS-federatieworkflow beschrijft zijn eigen client- en responsevereisten, en andere services gebruiken andere overdrachten.

Als de browserstap faalt, controleer dan deze volgorde

Werk van de browser naar buiten, want de foutmelding noemt meestal de laatste hop in plaats van de eerste.

Als de pagina nooit laadt, is de IdP-URL van de client of het pad ernaartoe verkeerd. Als de IdP het verzoek weigert, komen de serviceprovider-identificatie of de callback niet overeen met de configuratie. Als de browser succes toont en de client alsnog faalt, is de response op de verkeerde plek beland of mislukte de audience- en tijdvalidatie. En als de tunnel opkomt zonder toegang, is de assertion geaccepteerd maar de groepskaart niet.

Houd de verwachte pagina, de callback en de groepskaart in één document. Dan kan een gebruiker die een kapotte VPN-login meldt zeggen welke van die vier dingen hij zag, en is het antwoord al half geschreven.