Kva som skjer i nettlesarsteget ved ei føderert VPN-innlogging

Du klikkar på Kople til, og i staden for eit passordfelt opnar VPN-klienten nettlesaren din. Denne overleveringa forvirrar folk som ventar at tunnelen skal autentisere seg sjølv. Nettlesaren er ingen omveg: det er der identitetsleverandøren faktisk autentiserer personen, og klienten berre ventar på resultatet.

Å gå gjennom éi innlogging frå start til slutt viser kvar kvar feil høyrer heime, og det er nettopp den delen dei fleste runbooks hoppar over.

Start i klienten, ikkje i gateway-konfigurasjonen

Klienten byggjer ei førespurnad og sender nettlesaren til identitetsleverandøren med ein tenesteleverandøridentifikator og ei returadresse. Deretter køyrer IdP-en til organisasjonen det ho er konfigurert til: passord, MFA, einingekontroll, vilkårsstyrt tilgang. Viss nettlesaren allereie har ei gyldig økt, kan den synlege delen ta eit sekund eller to. Den stuttheita er gjenbruk av økta, ikkje ein kontroll som er hoppa over.

Les føderasjonskonfigurasjonen til klienten for to verdiar før noko anna: IdP-metadataa eller URL-en han stolar på, og callback-adressa han ventar. Eit avvik der feilar før noko passord er skrive.

Kva identitetsleverandøren må returnere

IdP-en svarar med eit signert SAML-svar som inneheld ein assertion: kven subjektet er, kven som utferda det, kven det er for, og kor lenge det er gyldig. Desse felta er kontrakten. Utferdar, audience, mottakar og gyldigheitsvindauge må alle samsvare med det tenesta ventar.

Eit svar som er signert av rett IdP, men adressert til ein annan audience, er framleis ugyldig. Det er kontrollen folk hoppar over når dei kopierer metadata mellom eit lab-miljø og produksjon.

Kva VPN-tenesta validerer før ho stolar på deg

Tenesta verifiserer signaturen mot det betrudde sertifikatet, kontrollerer utferdar, audience og mottakar, og vurderer deretter tidsvilkåra. Først etter det mappar ho assertionen til ein brukar eller gruppe og brukar VPN-autorisasjonspolicyen. Autentisering og autorisasjon er separate steg her, og ein gyldig assertion utan samsvarande gruppe gir ei økt som koplar til og ikkje når noko.

Assertionen er autentiseringsmateriale, ikkje eit passord. Å lime han inn i ein annan klient, eller ta vare på han til ei seinare gjenoppkopling, er ikkje ei støtta innlogging.

To levetider som sluttar kvar for seg

Nettlesarøkta hos IdP-en og VPN-økta i gatewayen går ut på ulike klokker. Å logge ut av IdP-en riv ikkje nødvendigvis ned ein etablert tunnel, og å kople frå tunnelen loggar deg ikkje ut av nettlesaren.

AWS Client VPN dokumenterer at den fødererte flyten ikkje støttar SAML single logout, og det er eitt konkret døme på gapet. Sjekk di eiga teneste i staden for å gå ut frå symmetri.

Dette er grunnen til at ei gjenoppkopling oppfører seg annleis kl. 09:00 og kl. 15:00. Ho kan gjenbruke IdP-økta stille, spørje om MFA igjen, eller feile fordi øktvarigheita for endepunktet gjekk ut medan nettlesarøkta ikkje gjorde det. AWS-føderasjonsarbeidsflyten skildrar sine eigne krav til klient og svar, og andre tenester brukar andre overleveringar.

Når nettlesarsteget feilar, sjekk desse i rekkefølgje

Arbeid frå nettlesaren og utover, fordi feilmeldinga vanlegvis namngir det siste leddet i staden for det første.

Viss sida aldri blir lasta, er IdP-URL-en til klienten eller stien til han feil. Viss IdP-en avviser førespurnaden, samsvarar ikkje tenesteleverandøridentifikatoren eller callbacken med konfigurasjonen. Viss nettlesaren viser suksess og klienten framleis feilar, nådde svaret feil stad eller feila audience- og tidsvalideringa. Og viss tunnelen kjem opp utan tilgang, vart assertionen godteken, men gruppemappinga var det ikkje.

Hald den venta sida, callbacken og gruppemappinga i eitt dokument. Då kan ein brukar som rapporterer ei øydelagd VPN-innlogging seie kva av desse fire tinga dei såg, og svaret er allereie halvskrive.