Loggar VPN SSO brukarane automatisk inn i interne apper?

Ein VPN-gateway som autentiserer via ein identitetsleverandør beviser éin ting: leverandøren garanterte for ein brukar overfor gatewayen. Han gir ikkje den brukaren ei legitimasjon for intranett-wikien, overvakingsdasjbordet eller byggjetenaren. Dei tenestene loggar folk inn via sin eigen føderasjon og nyttar si eiga autorisasjon, og tunnelen avgjer berre kva pakkar som kan nå dei.

Tre sesjonar, tre separate avgjerder

Hald tilstandane åtskilde, fordi kvar av dei går ut etter sin eigen tidsplan. VPN-sesjonen er gatewayen si godkjenning av ein identitet pluss nettilgangen han gav. Nettlesarsesjonen hjå identitetsleverandøren er det nettlesaren framleis held for den leverandøren og kan bruke om att etter si retningslinje. Applikasjonssesjonen høyrer til éi teneste som validerte eit svar retta til henne.

Å blande desse tilstandane gir det gale spørsmålet, vanlegvis formulert som kvifor tunnelen ikkje loggar brukaren inn overalt. Omformuler det: kva app manglar ein føderasjonsoppføring, kva app avviser brukaren, og kva app manglar ei rute. Éi påloggingsførespurnad som opnar intranett-appen kan framleis sprette tilbake til leverandøren, fordi den andre omdirigeringa er ein ny autorisasjonsførespurnad for eit anna publikum.

Kople gatewayen som sin eigen applikasjon

Registrer VPN-en som ein godkjend applikasjon hjå leverandøren, med sin eigen identifikator, omdirigerings-URI og brukartildeling. Avgjer deretter kva nettverksautorisasjonar den pålogginga gir, sidan det er VPN-retningslinje og ikkje ein leverandørfunksjon. Brukarar som berre skal nå overvakingssubnettet, får ei anna gateway-retningslinje, ikkje eit anna passord.

Autentiseringssvaret til tunnelen er ikkje ein gjenbrukbar legitimasjon. OIDC ID-token ber eit publikumskrav som namngir klienten dei vart utstelde for, og SAML bearer-påstandar avgrensar publikummet til tenesteleverandøren som tek imot dei. Ei anna teneste som godtek svaret til den første tenesta, er feilkonfigurert, og å kopiere eit token til ein annan app er ikkje integrasjon.

Registrer kvar intern app, og set deretter nettlesarkonteksten

Kvar teneste treng dei støtta SAML- eller OIDC-verdiane: utferdar, klientidentifikator, URL for tilbakekalling eller påstandskonsument, påkravde krav og tildeling. Tilgjenge kjem i tillegg, fordi identitetskontrollar aldri leverer ei rute eller eit DNS-svar.

1. Opprett applikasjonsoppføringa og stadfest at eininga eller klient-ID-en samsvarar med det appen sender.
2. Registrer den nøyaktige tilbakekallings-URL-en inkludert skjema og port; eit nesten-treff feilar etter at brukaren er autentisert.
3. Tildel brukarane eller gruppene, og stadfest deretter at dei påkravde krava vert utstelde.
4. Tillat endepunkta til identitetsleverandøren så vel som den private appen, elles kan omdirigeringa ikkje fullførast.

Nettlesarkonteksten avgjer om ein eksisterande leverandørsesjon vert brukt om att. Ein innebygd klient som opnar systemnettlesaren, kan dele den tilstanden, medan ei innfelta vising med si eiga cookiekrukke vanlegvis ikkje kan. Ny nettlesar, private vindauge og ein annan profil startar frå ingenting, noko som er venta og ikkje ein øydelagd SSO-konfigurasjon.

Køyr flyten og les kvar han stoppar

Reproduser med nettverkspanelet i nettlesaren og følg omdirigeringskjeda. Ein nyttig gjennomgang følgjer eitt hopp om gongen: gateway til leverandør, leverandør tilbake til appen med ein kode eller påstand, app til token-endepunktet til leverandøren, appsesjon utstedt. Hoppet der kjeda stoppar, namngir komponenten som må rettast.

To kommandolinjekontrollar avgjer dei vanlege tvilane, og begge er trygge å køyre frå ein adminvert:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

Når metadata listar endepunkt du aldri har registrert, peikar appen på ein annan leigetakar eller utferdar. Når den første førespurnaden til appen svarar 302 til ein uventa vert, er føderasjonskonfigurasjonen til appen staden å sjå, ikkje VPN-profilen.

Rett førespurnader ved å finne ut kven som bad om dei

Ein andre passordførespurnad er ikkje automatisk ein feil. Appen kan be om eit høgare tryggingsnivå, eller leverandøren kan handheve ein maksimal sesjonsalder og ei ny utfordring. Å fjerne desse krava for å gjere flyten stillare svekkjer ein medviten kontroll, så finn ut kva komponent som bad om det før du endrar retningslinja.

Avgjer deretter kva som skal betrast. Kjem førespurnaden frå appen, rett opp føderasjonsoppføringa. Kjem han frå leverandøren etter retningslinje, dokumenter kravet. Er appen utilgjengeleg etter ei vellukka pålogging, er rutinga til tunnelen den mistenkte, fordi identitet og pakkelevering feilar på ulike stader og ser like ut frå plassen til brukaren.