Loggar VPN SSO automatiskt in användare i interna appar?

En VPN-gateway som autentiserar via en identitetsleverantör bevisar en sak: leverantören gick i god för en användare inför gatewayen. Den ger inte den användaren några inloggningsuppgifter för intranätets wiki, övervakningspanelen eller byggservern. De tjänsterna loggar in folk via sin egen federation och tillämpar sin egen auktorisering, och tunneln avgör bara vilka paket som kan nå dem.

Tre sessioner, tre separata beslut

Håll tillstånden åtskilda, eftersom var och en löper ut enligt sitt eget schema. VPN-sessionen är gatewayens acceptans av en identitet plus nätverksåtkomsten den gav. Identitetsleverantörens webbläsarsession är det webbläsaren fortfarande håller för den leverantören och kan återanvända enligt sin policy. Applikationssessionen tillhör en enda tjänst som validerade ett svar riktat till den.

Att blanda ihop dessa tillstånd ger den felaktiga frågan, oftast formulerad som varför tunneln inte loggar in användaren överallt. Omformulera den: vilken app saknar en federationspost, vilken avvisar användaren och vilken saknar en rutt. En enda inloggningsuppmaning som öppnar intranätappen kan fortfarande studsa tillbaka till leverantören, eftersom den andra omdirigeringen är en ny auktoriseringsbegäran för en annan publik.

Koppla gatewayen som en egen applikation

Registrera VPN:en som en godkänd applikation hos leverantören, med egen identifierare, omdirigerings-URI och användartilldelning. Bestäm sedan vilka nätverksauktoriseringar den inloggningen ger, eftersom det är VPN-policy och inte en leverantörsfunktion. Användare som bara ska nå övervakningssubnätet får en annan gatewaypolicy, inte ett annat lösenord.

Tunnelns autentiseringssvar är inte en återanvändbar inloggningsuppgift. OIDC ID-tokens bär ett publikpåstående som namnger klienten de utfärdades för, och SAML bearer-påståenden begränsar publiken till den mottagande tjänsteleverantören. En andra tjänst som accepterar den första tjänstens svar är felkonfigurerad, och att kopiera en token till en annan app är inte integration.

Registrera varje intern app och ställ sedan in webbläsarkontexten

Varje tjänst behöver de stödda SAML- eller OIDC-värdena: utfärdare, klientidentifierare, URL för återkallelse eller påståendekonsument, nödvändiga anspråk och tilldelning. Tillgänglighet kommer ovanpå, eftersom identitetskontroller aldrig levererar en rutt eller ett DNS-svar.

1. Skapa applikationsposten och bekräfta att entitets- eller klient-ID:t matchar det appen skickar.
2. Registrera den exakta återkallelse-URL:en inklusive schema och port; en liten avvikelse misslyckas efter att användaren autentiserats.
3. Tilldela användarna eller grupperna och bekräfta sedan att de nödvändiga anspråken utfärdas.
4. Tillåt identitetsleverantörens slutpunkter såväl som den privata appen, annars kan omdirigeringen inte slutföras.

Webbläsarkontexten avgör om en befintlig leverantörssession återanvänds. En inbyggd klient som öppnar systemwebbläsaren kan dela det tillståndet, medan en inbäddad vy med egen cookiekruka vanligtvis inte kan. Ny webbläsare, privata fönster och en andra profil börjar från ingenting, vilket är förväntat och inte en trasig SSO-konfiguration.

Kör flödet och läs var det stannar

Reproducera med webbläsarens nätverkspanel och följ omdirigeringskedjan. En användbar genomgång följer ett hopp i taget: gateway till leverantör, leverantör tillbaka till appen med en kod eller ett påstående, app till leverantörens token-slutpunkt, appsession utfärdad. Hoppet där kedjan stannar namnger komponenten som ska rättas.

Två kommandoradskontroller avgör de vanliga tvivlen, och båda är säkra att köra från en adminvärd:

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 slutpunkter du aldrig registrerat pekar appen på en annan klientorganisation eller utfärdare. När den första begäran till appen svarar 302 mot en oväntad värd är appens federationskonfiguration stället att titta på, inte VPN-profilen.

Rätta uppmaningar genom att hitta vem som bad om dem

En andra lösenordsuppmaning är inte automatiskt en defekt. Appen kan begära en högre säkerhetsnivå, eller leverantören kan tvinga fram en maximal sessionsålder och en ny utmaning. Att ta bort dessa krav för att göra flödet tystare försvagar en medveten kontroll, så fastställ vilken komponent som bad om dem innan du ändrar policyn.

Bestäm sedan vad som ska förbättras. Kommer uppmaningen från appen, rätta dess federationspost. Kommer den från leverantören enligt policy, dokumentera kravet. Om appen inte går att nå efter en lyckad inloggning är tunnelns routing den misstänkta, eftersom identitet och paketleverans misslyckas på olika ställen och ser likadana ut från användarens plats.