Meldet VPN SSO brûkers automatysk oan by ynterne apps?

Ien oanmelding kin de tunnel en de apps derachter dekke, mar allinnich as elke app syn eigen fertrouwen hat. Hjir is de folchoarder om it te ferbinen en te testen.

In VPN-gateway dy't fia in identiteitsproviders autentisearret, bewissiget ien ding: de provider hat foar in brûker by de gateway ynstien. Hy jout dy brûker gjin bewiis foar de intranet-wiki, it monitoaringsoersjoch of de build-tsjinner. Dy tsjinsten melde minsken oan fia har eigen federaasje en tapasse har eigen autorisaasje, en de tunnel beslút allinnich hokker pakketten har berikke kinne.

Trije sesjes, trije aparte besluten

Hâld de tastannen apart, want elk ferfalt neffens syn eigen skema. De VPN-sesje is de akseptaasje fan in identiteit troch de gateway plus de netwurktoegong dy't er jûn hat. De browsersesje by de identiteitsprovider is wat de browser noch foar dy provider hâldt en neffens syn belied wer brûke kin. De applikaasjesesje heart by ien tsjinst dy't in antwurd dat oan him rjochte wie, falidearre hat.

It trochelinoar heljen fan dy tastannen jout de ferkearde fraach, meast foarme as wêrom't de tunnel de brûker net oeral oanmeldt. Werformulearje it: hokker app hat gjin federaasje-ynstap, hokker wegeret de brûker en hokker mist in rûte. Ien oanmeldingsprompt dy't de intranet-app iepenet, kin noch hieltyd weromspringe nei de provider, want de twadde trochstjoering is in nij autorisaasjefertal om in oar publyk.

Ferbyn de gateway as syn eigen applikaasje

Registrearje de VPN as goedkard applikaasje by de provider, mei syn eigen identifikaasje, trochstjoer-URI en brûkerstawizing. Beslút dan hokker netwurkautorisaasjes dy oanmelding jout, want dat is VPN-belied en net in funksje fan de provider. Brûkers dy't allinnich it monitoaring-subnet berikke moatte, krije in oar gatewaybelied, net in oar wachtwurd.

It autentikaasje-antwurd fan de tunnel is gjin werbrûkber bewiis. OIDC ID-tokens drage in publykseask dy't de klant neamt wêrfoar't se oanmakke binne, en SAML-dragerbewearings beheine it publyk ta de ûntfangende tsjinstprovider. In twadde tsjinst dy't it antwurd fan de earste akseptearret, is ferkeard konfigurearre, en in token nei in oare app kopiearje is gjin yntegraasje.

Registrearje elke ynterne app, set dan de browserkontekst

Elke tsjinst hat de stipe SAML- of OIDC-wearden nedich: útjouwer, klantidentifikaasje, weromrop- of bewearing-consument-URL, ferplichte easken en tawizing. Berikberens komt derboppe, want identiteitskontrôles leverje nea in rûte of in DNS-antwurd.

  1. Meitsje de applikaasje-ynstap oan en befêstigje dat de entiteit- of klant-ID oerienkomt mei wat de app stjoert.
  2. Registrearje de krekte weromrop-URL, ynklusyf skema en poarte; in hast-treffer mislearret neidat de brûker autentisearre is.
  3. Wize de brûkers of groepen ta, befêstigje dan dat de ferplichte easken útjûn wurde.
  4. Stean de einpunten fan de identiteitsprovider ta likegoed as de privee-app, oars kin de trochstjoering net foltôgje.

De browserkontekst beslút oft in besteande providersesje wer brûkt wurdt. In natyske klant dy't de systeembrowser iepenet, kin dy tastân diele, wylst in ynbêde werjefte mei syn eigen koekjepot dat meast net kin. Nije browser, privee finsters en in twadde profyl begjinne fan nul, wat ferwachte is en gjin brutsen SSO-konfiguraasje.

Rin de stream en lês wêr't er stopt

Reprodusearje mei it netwurkpaniel fan de browser en folgje de trochstjoerkeatling. In nuttige trochgong folget ien sprong tagelyk: gateway nei provider, provider werom nei de app mei in koade of bewearing, app nei it token-einpunt fan de provider, applikaasjesesje útjûn. De sprong wêr't de keatling stopt, neamt it ûnderdiel dat reparearre wurde moat.

Twa kommandorigel-kontrôles besljochtsje de gewoane twifels, en beide binne feilich om fan in admin-host ôf te rinnen:

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

As de metadata einpunten listet dy't jo nea registrearre hawwe, wiist de app nei in oare hierder of útjouwer. As it earste fersyk oan de app 302 antwurdet nei in ûnferwachte host, is de federaasjekonfiguraasje fan de app it plak om te sjen, net it VPN-profyl.

Reparasearje prompts troch te finen wa't se frege hat

In twadde wachtwurdprompt is net automatysk in mankement. De app kin in heger garânsjenivo freegje, of de provider kin in maksimale sesjesâldens en in nije útdaging ôftwinge. It fuortheljen fan dy easken om de stream stiller te meitsjen, ferswakket in bewuste kontrôle, dus fêstigje earst hokker ûnderdiel it frege hat foardat jo belied feroarje.

Beslút dan wat te ferbetterjen. As de prompt fan de app komt, reparearje dan syn federaasje-ynstap. As er neffens belied fan de provider komt, dokumintearje de eask. As de app nei in slagge oanmelding net berikber is, is de tunnelrouting de fertochte, want identiteit en pakketleverje mislearje op ferskate plakken en sjogge der fan de brûker syn stoel itselde út.

Relatearre artikelen