Ĉu VPN SSO aŭtomate ensalutas uzantojn en internajn aplikaĵojn?

Unu ensaluto povas kovri la tunelon kaj la aplikaĵojn malantaŭ ĝi, sed nur kiam ĉiu aplikaĵo havas sian propran fidon. Jen la ordo por konekti kaj testi ĝin.

VPN-pordego, kiu aŭtentikigas per identecprovizanto, pruvas unu aferon: la provizanto garantiis por uzanto antaŭ la pordego. Ĝi ne donas al tiu uzanto akreditaĵon por la intraneta vikio, la gvida panelo aŭ la konstrua servilo. Tiuj servoj ensalutas homojn per sia propra federacio kaj aplikas sian propran rajtigon, kaj la tunelo nur decidas, kiuj pakaĵoj povas atingi ilin.

Tri sesioj, tri apartaj decidoj

Tenu la statojn aparte, ĉar ĉiu eksvalidiĝas laŭ sia propra horaro. La VPN-sesio estas la akcepto de identeco fare de la pordego plus la donita reta aliro. La retumila sesio ĉe la identecprovizanto estas tio, kion la retumilo ankoraŭ tenas por tiu provizanto kaj povas reuzi laŭ sia politiko. La aplikaĵa sesio apartenas al unu servo, kiu validigis respondon adresitan al ĝi.

Konfuzi tiujn statojn produktas la malĝustan demandon, kutime formulitan kiel kial la tunelo ne ensalutas la uzanton ĉie. Reformulu ĝin: kiu aplikaĵo havas neniun federacian enskribon, kiu rifuzas la uzanton kaj al kiu mankas vojo. Unu ensaluta invito, kiu malfermas la intranetan aplikaĵon, ankoraŭ povas resalti al la provizanto, ĉar la dua alidirektado estas nova rajtiga peto por alia aŭdienco.

Konektu la pordegon kiel propran aplikaĵon

Registru la VPN kiel aprobitan aplikaĵon ĉe la provizanto, kun propra identigilo, alidirekta URI kaj uzanta atribuo. Poste difinu, kiujn retajn rajtigojn tiu ensaluto donas, ĉar tio estas VPN-politiko kaj ne trajto de la provizanto. Uzantoj, kiuj devus atingi nur la gvidadan subreton, ricevas alian pordegan politikon, ne alian pasvorton.

La aŭtentikiga respondo de la tunelo ne estas reuzebla akreditaĵo. OIDC ID-ĵetonoj portas aŭdiencan aserton nomantan la klienton por kiu ili estis eldonitaj, kaj SAML portantaj asertoj limigas la aŭdiencon al la ricevanta servoprovizanto. Dua servo, kiu akceptas la respondon de la unua, estas misagordita, kaj kopii ĵetonon en alian aplikaĵon ne estas integriĝo.

Registru ĉiun internan aplikaĵon, poste agordu la retumilan kuntekston

Ĉiu servo bezonas la subtenatajn SAML aŭ OIDC-valorojn: eldonanto, klienta identigilo, retrovoka aŭ aserto-konsumanta URL, postulataj asertoj kaj atribuo. Atingebleco venas sur tio, ĉar identecaj kontroloj neniam donas vojon aŭ respondan DNS.

  1. Kreu la aplikaĵan enskribon kaj konfirmu, ke la enteca aŭ klienta ID kongruas kun tio, kion la aplikaĵo sendas.
  2. Registru la precizan retrovokan URL inkluzive de skemo kaj pordo; preskaŭ-trafo malsukcesas post kiam la uzanto aŭtentikiĝis.
  3. Atribuu la uzantojn aŭ grupojn, poste konfirmu, ke la postulataj asertoj eldoniĝas.
  4. Permesu la finpunktojn de la identecprovizanto kaj ankaŭ la privatan aplikaĵon, alie la alidirektado ne povas finiĝi.

La retumila kunteksto decidas, ĉu ekzistanta provizanta sesio estas reuzata. Indiĝena kliento, kiu malfermas la sistemretumilon, povas kunhavigi tiun staton, dum enkorpigita vido kun propra kukuja ujo kutime ne povas. Nova retumilo, privataj fenestroj kaj dua profilo komenciĝas de nulo, kio estas atendata kaj ne rompita SSO-agordo.

Rulu la fluon kaj legu, kie ĝi haltas

Reproduktu per la reta panelo de la retumilo kaj observu la alidirektan ĉenon. Utila trapaso sekvas unu salton samtempe: pordego al provizanto, provizanto reen al la aplikaĵo kun kodo aŭ aserto, aplikaĵo al la ĵetona finpunkto de la provizanto, eldonita aplikaĵa sesio. La salto, ĉe kiu la ĉeno haltas, nomas la komponenton por ripari.

Du komandliniaj kontroloj solvas la kutimajn dubojn, kaj ambaŭ estas sekuraj por ruli de administra gastiganto:

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

Kiam la metadatenoj listigas finpunktojn, kiujn vi neniam registris, la aplikaĵo montras al alia luanto aŭ eldonanto. Kiam la unua peto al la aplikaĵo respondas 302 al neatendita gastiganto, la federacia agordo de la aplikaĵo estas la loko por rigardi, ne la VPN-profilo.

Riparu invitojn trovante, kiu demandis

Dua pasvorta invito ne estas aŭtomate difekto. La aplikaĵo povas peti pli altan nivelon de garantio, aŭ la provizanto povas trudi maksimuman sesian aĝon kaj novan defion. Forigi tiujn postulojn por igi la fluon pli trankvila malfortigas intencan kontrolon, do establu, kiu komponento demandis, antaŭ ol ŝanĝi politikon.

Poste decidu, kion plibonigi. Se la invito venas de la aplikaĵo, riparu ĝian federacian enskribon. Se ĝi venas de la provizanto laŭ politiko, dokumentu la postulon. Se la aplikaĵo neatingeblas post sukcesa ensaluto, la tunela enkursigado estas la suspektato, ĉar identeco kaj pakaĵa liverado malsukcesas en malsamaj lokoj kaj aspektas simile el la sidloko de la uzanto.

Rilataj artikoloj