Hva som skjer i nettlesersteget ved en føderert VPN-innlogging

Du klikker på Koble til, og i stedet for et passordfelt åpner VPN-klienten nettleseren din. Den overleveringen forvirrer folk som forventer at tunnelen skal autentisere seg selv. Nettleseren er ingen omvei: det er der identitetsleverandøren faktisk autentiserer personen, og klienten bare venter på resultatet.

Å gå gjennom én innlogging fra start til slutt viser hvor hver feil hører hjemme, og det er nettopp den delen de fleste runbooks hopper over.

Start i klienten, ikke i gateway-konfigurasjonen

Klienten bygger en forespørsel og sender nettleseren til identitetsleverandøren med en tjenesteleverandøridentifikator og en returadresse. Deretter kjører organisasjonens IdP det den er konfigurert til: passord, MFA, enhetskontroll, betinget tilgang. Hvis nettleseren allerede har en gyldig økt, kan den synlige delen ta et sekund eller to. Den kortheten er gjenbruk av økten, ikke en kontroll som er hoppet over.

Les klientens føderasjonskonfigurasjon for to verdier før noe annet: IdP-metadataene eller URL-en den stoler på, og callback-adressen den forventer. Et avvik der feiler før noe passord er skrevet.

Hva identitetsleverandøren må returnere

IdP-en svarer med et signert SAML-svar som inneholder en assertion: hvem subjektet er, hvem som utstedte det, hvem det er for, og hvor lenge det er gyldig. Disse feltene er kontrakten. Utsteder, audience, mottaker og gyldighetsvindu må alle samsvare med det tjenesten forventer.

Et svar som er signert av riktig IdP, men adressert til en annen audience, er fortsatt ugyldig. Det er kontrollen folk hopper over når de kopierer metadata mellom et lab-miljø og produksjon.

Hva VPN-tjenesten validerer før den stoler på deg

Tjenesten verifiserer signaturen mot det betrodde sertifikatet, kontrollerer utsteder, audience og mottaker, og vurderer deretter tidsbetingelsene. Først etter det mapper den assertionen til en bruker eller gruppe og anvender VPN-autorisasjonspolicyen. Autentisering og autorisasjon er separate steg her, og en gyldig assertion uten samsvarende gruppe gir en økt som kobler til og ikke når noe.

Assertionen er autentiseringsmateriale, ikke et passord. Å lime den inn i en annen klient, eller ta vare på den til en senere gjenoppkobling, er ikke en støttet innlogging.

To levetider som slutter hver for seg

Nettleserøkten hos IdP-en og VPN-økten i gatewayen utløper på ulike klokker. Å logge ut av IdP-en river ikke nødvendigvis ned en etablert tunnel, og å koble fra tunnelen logger deg ikke ut av nettleseren.

AWS Client VPN dokumenterer at den fødererte flyten ikke støtter SAML single logout, og det er ett konkret eksempel på gapet. Sjekk din egen tjeneste i stedet for å anta symmetri.

Dette er grunnen til at en gjenoppkobling oppfører seg annerledes kl. 09:00 og kl. 15:00. Den kan gjenbruke IdP-økten stille, spørre om MFA igjen, eller feile fordi øktvarigheten for endepunktet utløp mens nettleserøkten ikke gjorde det. AWS-føderasjonsarbeidsflyten beskriver sine egne krav til klient og svar, og andre tjenester bruker andre overleveringer.

Når nettlesersteget feiler, sjekk disse i rekkefølge

Arbeid fra nettleseren og utover, fordi feilmeldingen vanligvis navngir det siste leddet i stedet for det første.

Hvis siden aldri lastes, er klientens IdP-URL eller stien til den feil. Hvis IdP-en avviser forespørselen, samsvarer ikke tjenesteleverandøridentifikatoren eller callbacken med konfigurasjonen. Hvis nettleseren viser suksess og klienten fortsatt feiler, nådde svaret feil sted eller feilet audience- og tidsvalideringen. Og hvis tunnelen kommer opp uten tilgang, ble assertionen godtatt, men gruppemappingen var det ikke.

Hold den forventede siden, callbacken og gruppemappingen i ett dokument. Da kan en bruker som rapporterer en ødelagt VPN-innlogging si hvilken av disse fire tingene de så, og svaret er allerede halvskrevet.