Logt VPN SSO gebruikers automatisch in bij interne apps?

Een VPN-gateway die zich via een identiteitsprovider authenticeert, bewijst één ding: de provider heeft voor een gebruiker ingestaan bij de gateway. Hij geeft die gebruiker geen inloggegevens voor de intranetwiki, het monitoringdashboard of de buildserver. Die diensten melden mensen aan via hun eigen federatie en passen hun eigen autorisatie toe, en de tunnel bepaalt alleen welke pakketten hen kunnen bereiken.

Drie sessies, drie afzonderlijke beslissingen

Houd de toestanden gescheiden, want elk verloopt volgens zijn eigen schema. De VPN-sessie is de acceptatie van een identiteit door de gateway plus de netwerktoegang die hij verleende. De browsersessie bij de identiteitsprovider is wat de browser nog voor die provider vasthoudt en volgens zijn beleid kan hergebruiken. De applicatiesessie hoort bij één dienst die een aan hem gericht antwoord heeft gevalideerd.

Het verwarren van die toestanden levert de verkeerde vraag op, meestal geformuleerd als waarom de tunnel de gebruiker niet overal aanmeldt. Herformuleer haar: welke applicatie heeft geen federatie-vermelding, welke weigert de gebruiker, en welke mist een route. Eén aanmeldingsprompt die de intranetapplicatie opent, kan nog steeds terugspringen naar de provider, omdat de tweede omleiding een nieuwe autorisatieaanvraag voor een ander publiek is.

Sluit de gateway aan als zijn eigen applicatie

Registreer de VPN als goedgekeurde applicatie bij de provider, met een eigen identificatie, omleidings-URI en gebruikerstoewijzing. Bepaal daarna welke netwerkautorisaties die aanmelding verleent, want dat is VPN-beleid en geen providerfunctie. Gebruikers die alleen het monitoringsubnet mogen bereiken, krijgen een ander gatewaybeleid, niet een ander wachtwoord.

De authenticatie-reactie van de tunnel is geen herbruikbaar inloggegeven. OIDC ID-tokens dragen een publieksclaim die de client noemt waarvoor ze zijn uitgegeven, en SAML-bearer-assertions beperken het publiek tot de ontvangende serviceprovider. Een tweede dienst die de reactie van de eerste accepteert, is verkeerd geconfigureerd, en een token naar een andere app kopiëren is geen integratie.

Registreer elke interne app en stel daarna de browsercontext in

Elke dienst heeft de ondersteunde SAML- of OIDC-waarden nodig: uitgever, clientidentificatie, callback- of assertion-consumer-URL, vereiste claims en toewijzing. Bereikbaarheid komt daar bovenop, omdat identiteitscontroles nooit een route of een DNS-antwoord leveren.

1. Maak de applicatie-vermelding aan en bevestig dat de entiteits- of client-ID overeenkomt met wat de app verstuurt.
2. Registreer de exacte callback-URL inclusief schema en poort; een kleine afwijking faalt nadat de gebruiker is geauthenticeerd.
3. Wijs de gebruikers of groepen toe en bevestig daarna dat de vereiste claims worden uitgegeven.
4. Sta de eindpunten van de identiteitsprovider toe naast de private app, anders kan de omleiding niet voltooien.

De browsercontext bepaalt of een bestaande providersessie wordt hergebruikt. Een native client die de systeembrowser opent, kan die toestand delen, terwijl een ingebedde weergave met een eigen cookiepot dat meestal niet kan. Nieuwe browser, privévensters en een tweede profiel beginnen bij niets, wat te verwachten is en geen kapotte SSO-configuratie.

Voer de flow uit en lees waar hij stopt

Reproduceer met het netwerkpaneel van de browser en volg de omleidingsketen. Een nuttige doorgang volgt één sprong tegelijk: gateway naar provider, provider terug naar de app met een code of assertion, app naar het token-eindpunt van de provider, app-sessie uitgegeven. De sprong waar de keten stopt, noemt het onderdeel dat moet worden gerepareerd.

Twee controles vanaf de opdrachtregel beslechten de gebruikelijke twijfels, en beide zijn veilig vanaf een admin-host:

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:)'

Wanneer de metadata eindpunten vermeldt die je nooit hebt geregistreerd, wijst de app naar een andere tenant of uitgever. Wanneer het eerste verzoek aan de app 302 antwoordt naar een onverwachte host, is de federatieconfiguratie van de applicatie de plek om te kijken, niet het VPN-profiel.

Repareer prompts door te vinden wie erom vroeg

Een tweede wachtwoordprompt is niet automatisch een defect. De applicatie kan een hoger betrouwbaarheidsniveau vragen, of de provider kan een maximale sessieleeftijd en een nieuwe uitdaging afdwingen. Die eisen verwijderen om de flow stiller te maken, verzwakt een bewuste controle, dus stel vast welk onderdeel erom vroeg voordat je het beleid wijzigt.

Bepaal daarna wat er verbeterd moet worden. Komt de prompt van de app, repareer dan de federatie-vermelding. Komt hij volgens beleid van de provider, documenteer dan de eis. Is de app na een geslaagde aanmelding onbereikbaar, dan is de routing van de tunnel verdacht, omdat identiteit en pakketaflevering op verschillende plaatsen falen en er vanuit de stoel van de gebruiker hetzelfde uitzien.