Logger VPN SSO brugere automatisk ind i interne apps?

En VPN-gateway, der godkender via en identitetsudbyder, beviser én ting: udbyderen har garanteret for en bruger over for gatewayen. Den giver ikke den bruger en legitimationsoplysning til intranet-wikien, overvågningsdashboardet eller buildserveren. De tjenester logger folk ind via deres egen føderation og anvender deres egen autorisation, og tunnelen afgør kun, hvilke pakker der kan nå dem.

Tre sessioner, tre separate beslutninger

Hold tilstandene adskilt, fordi hver især udløber efter sin egen tidsplan. VPN-sessionen er gatewayens accept af en identitet plus den netværksadgang, den har givet. Identitetsudbyderens browsersession er det, browseren stadig holder for den udbyder og kan genbruge efter sin politik. Applikationssessionen tilhører én tjeneste, der har valideret et svar rettet til den.

At blande disse tilstande giver det forkerte spørgsmål, som regel formuleret som hvorfor tunnelen ikke logger brugeren ind overalt. Omformulér det: hvilken app mangler en føderationspost, hvilken afviser brugeren, og hvilken mangler en rute. Én loginprompt, der åbner intranet-appen, kan stadig springe tilbage til udbyderen, fordi den anden omdirigering er en ny autorisationsanmodning for et andet publikum.

Tilslut gatewayen som sin egen applikation

Registrér VPN som en godkendt applikation hos udbyderen med sin egen identifikator, omdirigerings-URI og brugertildeling. Beslut derefter, hvilke netværksautorisationer den login giver, da det er en VPN-politik og ikke en udbyderfunktion. Brugere, der kun skal nå overvågningssubnettet, får en anden gatewaypolitik, ikke en anden adgangskode.

Tunnelens godkendelsessvar er ikke en genanvendelig legitimationsoplysning. OIDC ID-tokens bærer et publikumsclaim, der navngiver den klient, de blev udstedt til, og SAML bearer-assertions begrænser publikummet til den modtagende tjenesteudbyder. En anden tjeneste, der accepterer den første tjenestes svar, er fejlkonfigureret, og at kopiere et token til en anden app er ikke integration.

Registrér hver intern app, og sæt derefter browserkonteksten

Hver tjeneste har brug for de understøttede SAML- eller OIDC-værdier: udsteder, klientidentifikator, callback- eller assertion-consumer-URL, påkrævede claims og tildeling. Tilgængelighed kommer ovenpå, fordi identitetskontroller aldrig leverer en rute eller et DNS-svar.

1. Opret applikationsposten, og bekræft at entitets- eller klient-ID'et matcher det, appen sender.
2. Registrér den nøjagtige callback-URL inklusive skema og port; et næsten-hit fejler, efter at brugeren er godkendt.
3. Tildel brugerne eller grupperne, og bekræft derefter at de påkrævede claims udstedes.
4. Tillad identitetsudbyderens endepunkter såvel som den private app, ellers kan omdirigeringen ikke fuldføres.

Browserkonteksten afgør, om en eksisterende udbydersession genbruges. En native klient, der åbner systembrowseren, kan dele den tilstand, mens en indlejret visning med sin egen cookiebeholder normalt ikke kan. Ny browser, private vinduer og en anden profil starter fra ingenting, hvilket er forventet og ikke en brudt SSO-konfiguration.

Kør flowet, og læs hvor det stopper

Genskab med browserens netværkspanel, og følg omdirigeringskæden. En nyttig gennemgang følger ét hop ad gangen: gateway til udbyder, udbyder tilbage til appen med en kode eller assertion, app til udbyderens token-endpoint, app-session udstedt. Det hop, hvor kæden stopper, navngiver den komponent, der skal rettes.

To kommandolinjekontroller afklarer de sædvanlige tvivl, og begge er sikre at køre fra en administratorvært:

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 aldrig har registreret, peger appen på en anden lejer eller udsteder. Når den første anmodning til appen svarer 302 til en uventet vært, er appens føderationskonfiguration stedet at se, ikke VPN-profilen.

Ret prompter ved at finde ud af, hvem der spurgte

En anden adgangskodeprompt er ikke automatisk en fejl. Appen kan anmode om et højere sikkerhedsniveau, eller udbyderen kan håndhæve en maksimal sessionsalder og en ny udfordring. At fjerne disse krav for at gøre flowet mere stille svækker en bevidst kontrol, så fastslå, hvilken komponent der spurgte, før politikken ændres.

Beslut derefter, hvad der skal forbedres. Kommer prompten fra appen, så ret dens føderationspost. Kommer den fra udbyderen efter politik, så dokumentér kravet. Hvis appen ikke kan nås efter en vellykket login, er tunnelens routing den mistænkte, fordi identitet og pakkelevering fejler forskellige steder og ser ens ud fra brugerens plads.