Logger VPN SSO brukerne automatisk inn i interne apper?

Én pålogging kan dekke tunnelen og appene bak den, men bare når hver app har sin egen tillit. Her er rekkefølgen for å koble det opp og teste det.

En VPN-gateway som autentiserer via en identitetsleverandør beviser én ting: leverandøren garanterte for en bruker overfor gatewayen. Den gir ikke den brukeren en legitimasjon for intranett-wikien, overvåkingsdashbordet eller byggeserveren. Disse tjenestene logger folk inn via sin egen føderasjon og anvender sin egen autorisasjon, og tunnelen avgjør bare hvilke pakker som kan nå dem.

Tre sesjoner, tre separate beslutninger

Hold tilstandene atskilt, fordi hver av dem utløper etter sin egen tidsplan. VPN-sesjonen er gatewayens aksept av en identitet pluss nettverkstilgangen den ga. Identitetsleverandørens nettlesersesjon er det nettleseren fortsatt holder for den leverandøren og kan gjenbruke etter sin policy. Applikasjonssesjonen tilhører én tjeneste som validerte et svar rettet til den.

Å blande disse tilstandene gir det gale spørsmålet, vanligvis formulert som hvorfor tunnelen ikke logger brukeren inn overalt. Omformuler det: hvilken app mangler en føderasjonsoppføring, hvilken avviser brukeren, og hvilken mangler en rute. Én påloggingsforespørsel som åpner intranett-appen kan fortsatt sprette tilbake til leverandøren, fordi den andre omdirigeringen er en ny autorisasjonsforespørsel for et annet publikum.

Koble gatewayen som sin egen applikasjon

Registrer VPN-en som en godkjent applikasjon hos leverandøren, med sin egen identifikator, omdirigerings-URI og brukertildeling. Bestem deretter hvilke nettverksautorisasjoner den påloggingen gir, siden det er VPN-policy og ikke en leverandørfunksjon. Brukere som bare skal nå overvåkingssubnettet, får en annen gateway-policy, ikke et annet passord.

Tunnelens autentiseringssvar er ikke en gjenbrukbar legitimasjon. OIDC ID-tokener bærer et publikumskrav som navngir klienten de ble utstedt for, og SAML bearer-påstander begrenser publikummet til tjenesteleverandøren som mottar dem. En annen tjeneste som godtar den første tjenestens svar, er feilkonfigurert, og å kopiere et token til en annen app er ikke integrasjon.

Registrer hver intern app, og sett deretter nettleserkonteksten

Hver tjeneste trenger de støttede SAML- eller OIDC-verdiene: utsteder, klientidentifikator, URL for tilbakeringing eller påstandskonsument, påkrevde krav og tildeling. Tilgjengelighet kommer i tillegg, fordi identitetskontroller aldri leverer en rute eller et DNS-svar.

  1. Opprett applikasjonsoppføringen og bekreft at entitets- eller klient-ID-en samsvarer med det appen sender.
  2. Registrer den nøyaktige tilbakeringings-URL-en inkludert skjema og port; et nesten-treff feiler etter at brukeren er autentisert.
  3. Tildel brukerne eller gruppene, og bekreft deretter at de påkrevde kravene utstedes.
  4. Tillat identitetsleverandørens endepunkter så vel som den private appen, ellers kan omdirigeringen ikke fullføres.

Nettleserkonteksten avgjør om en eksisterende leverandørsesjon gjenbrukes. En innebygd klient som åpner systemnettleseren, kan dele den tilstanden, mens en innfelt visning med sin egen cookiekrukke vanligvis ikke kan. Ny nettleser, private vinduer og en annen profil starter fra ingenting, noe som er forventet og ikke en ødelagt SSO-konfigurasjon.

Kjør flyten og les hvor den stopper

Reproduser med nettleserens nettverkspanel og følg omdirigeringskjeden. En nyttig gjennomgang følger ett hopp om gangen: gateway til leverandør, leverandør tilbake til appen med en kode eller påstand, app til leverandørens token-endepunkt, appsesjon utstedt. Hoppet der kjeden stopper, navngir komponenten som må rettes.

To kommandolinjekontroller avgjør de vanlige tvilene, og begge er trygge å kjøre fra en 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 metadataene lister endepunkter du aldri har registrert, peker appen på en annen leietaker eller utsteder. Når den første forespørselen til appen svarer 302 til en uventet vert, er appens føderasjonskonfigurasjon stedet å se, ikke VPN-profilen.

Rett forespørsler ved å finne ut hvem som ba om dem

En annen passordforespørsel er ikke automatisk en feil. Appen kan be om et høyere sikkerhetsnivå, eller leverandøren kan håndheve en maksimal sesjonsalder og en ny utfordring. Å fjerne disse kravene for å gjøre flyten stillere svekker en bevisst kontroll, så finn ut hvilken komponent som ba om det før du endrer policyen.

Bestem deretter hva som skal forbedres. Kommer forespørselen fra appen, rett opp føderasjonsoppføringen. Kommer den fra leverandøren etter policy, dokumenter kravet. Hvis appen ikke er tilgjengelig etter en vellykket pålogging, er tunnelens ruting den mistenkte, fordi identitet og pakkelevering feiler på forskjellige steder og ser like ut fra brukerens plass.

Relaterte artikler