Hvad sker der i browserstepset ved et fødereret VPN-login

Du klikker på Forbind, og i stedet for et adgangskodefelt åbner VPN-klienten din browser. Den overlevering forvirrer folk, der forventer, at tunnelen godkender sig selv. Browseren er ikke en omvej: det er dér, identitetsudbyderen faktisk godkender personen, og klienten venter blot på resultatet.

At følge ét login fra start til slut viser, hvor hver fejl hører til, og det er netop den del, de fleste runbooks springer over.

Start ved klienten, ikke ved gateway-konfigurationen

Klienten bygger en anmodning og sender browseren til identitetsudbyderen med en serviceudbyder-identifikator og en returplacering. Din organisations IdP kører derefter det, den er sat op til: adgangskode, MFA, enhedstjek, betinget adgang. Hvis browseren allerede har en gyldig session, kan den synlige del tage et sekund eller to. Den korthed er genbrug af session, ikke et sprunget tjek.

Læs to værdier i klientens føderationskonfiguration før alt andet: de IdP-metadata eller den URL, den stoler på, og den callback-adresse, den forventer. Uoverensstemmelse der fejler, før nogen adgangskode skrives.

Hvad identitetsudbyderen skal returnere

IdP'en svarer med et signeret SAML-svar, der indeholder en assertion: hvem subjektet er, hvem der har udstedt det, hvem det er til, og hvor længe det er gyldigt. De felter er kontrakten. Udsteder, audience, modtager og gyldighedsvindue skal alle matche det, tjenesten forventer.

Et svar signeret af den rigtige IdP, men adresseret til en anden audience, er stadig ugyldigt. Det er det tjek, folk springer over, når de kopierer metadata mellem et laboratorium og produktion.

Hvad VPN-tjenesten validerer, før den stoler på dig

Tjenesten verificerer signaturen mod det betroede certifikat, tjekker udstederen, audiencen og modtageren og vurderer derefter tidsbetingelserne. Først derefter mapper den assertionen til en bruger eller gruppe og anvender VPN-autorisationspolitikken. Godkendelse og autorisation er adskilte trin her, og en gyldig assertion uden en matchende gruppe giver en session, der forbinder og ikke når noget.

Assertionen er godkendelsesmateriale, ikke en adgangskode. At indsætte den i en anden klient eller gemme den til en senere genopkobling er ikke et understøttet login.

To levetider, der slutter hver for sig

Browsersessionen hos IdP'en og VPN-sessionen ved gatewayen udløber på forskellige ure. Logud hos IdP'en nedriver ikke nødvendigvis en etableret tunnel, og afbrydelse af tunnelen logger dig ikke ud af browseren.

AWS Client VPN dokumenterer, at dens fødererede flow ikke understøtter SAML-enkeltlogud, hvilket er et konkret eksempel på hullet. Tjek din egen tjeneste i stedet for at antage symmetri.

Derfor opfører en genopkobling sig anderledes kl. 09:00 og kl. 15:00. Den kan genbruge IdP-sessionen i det stille, bede om MFA igen eller fejle, fordi endpoint-sessionens varighed er udløbet, mens browsersessionen ikke er. AWS' føderationsworkflow beskriver sine egne krav til klient og svar, og andre tjenester bruger andre overleveringer.

Når browsersteppet fejler, tjek disse i rækkefølge

Arbejd fra browseren og udad, fordi fejlmeddelelsen normalt navngiver det sidste hop i stedet for det første.

Hvis siden aldrig indlæses, er klientens IdP-URL eller stien dertil forkert. Hvis IdP'en afviser anmodningen, matcher serviceudbyder-identifikatoren eller callbacken ikke dens konfiguration. Hvis browseren viser succes, og klienten stadig fejler, er svaret endt det forkerte sted eller har fejlet audience- og tidsvalidering. Og hvis tunnelen kommer op uden adgang, blev assertionen accepteret, men gruppemappingen blev ikke.

Hold den forventede side, callbacken og gruppemappingen i ét dokument. Så kan en bruger, der rapporterer et brudt VPN-login, sige, hvilken af de fire ting de så, og svaret er allerede halvt skrevet.