VPN SSO-k automatikoki saioa hasten du erabiltzaileak barne-aplikazioetan?

Saio-hasiera bakar batek tunela eta haren atzeko aplikazioak estal ditzake, baina aplikazio bakoitzak bere konfiantza duenean soilik. Hona hemen konektatzeko eta probatzeko ordena.

Identitate-hornitzaile baten bidez autentifikatzen den VPN ateak gauza bat frogatzen du: hornitzaileak erabiltzaile baten alde erantzun ziola ateari. Ez dio erabiltzaile horri sarbide-agiririk ematen intraneteko wikirako, monitorizazio-panelera edo konpilazio-zerbitzarirako. Zerbitzu horiek jendea beren federazioaren bidez hasten dute saioa eta beren baimena aplikatzen dute, eta tunelek soilik erabakitzen du zein paketek irits daitezkeen haiengana.

Hiru saio, hiru erabaki bereizi

Eduki egoerak bereizita, bakoitza bere egutegiaren arabera iraungitzen delako. VPN saioa atea identitate bat onartzea gehi eman zuen sare-sarbidea da. Identitate-hornitzailearen nabigatzaile-saioa nabigatzaileak hornitzaile horretarako oraindik gordetzen duena da, eta beren politikaren arabera berrerabil dezakeena. Aplikazio-saioa berari zuzendutako erantzun bat baliozkotu zuen zerbitzu bakarrari dagokio.

Egoera horiek nahasteak galdera okerra sortzen du, normalean tunelek zergatik ez duen erabiltzailea nonahi saioa hasten gisa formulatua. Birformulatu: zein aplikaziok ez du federazio-sarrerarik, zeinek ukatzen du erabiltzailea eta zeini falta zaio bidea. Intraneteko aplikazioa irekitzen duen saio-hasiera abisu bakar batek hornitzailera itzul daiteke oraindik, bigarren birbideratzea audientzia ezberdin baterako baimen-eskaera berria delako.

Konektatu atea bere aplikazio gisa

Erregistratu VPNa hornitzailean onartutako aplikazio gisa, bere identifikatzaile, birbideratze-URI eta erabiltzaileen esleipenarekin. Gero erabaki saio-hasiera horrek zein sare-baimen ematen dituen, hori VPN politika baita, ez hornitzailearen funtzioa. Monitorizazio-azpisarera soilik iritsi behar duten erabiltzaileek ate-politika ezberdina jasotzen dute, ez pasahitz ezberdina.

Tunelaren autentifikazio-erantzuna ez da berrerabilgarria den sarbide-agiria. OIDC ID tokenek audientzia-adierazpena daramate, zein bezerorentzat sortu ziren izendatuz, eta SAML bearer baieztapenek audientzia hartzen duen zerbitzu-hornitzailearekin mugatzen dute. Lehenengo zerbitzuaren erantzuna onartzen duen bigarren zerbitzua gaizki konfiguratuta dago, eta token bat beste aplikazio batera kopiatzea ez da integrazioa.

Erregistratu barne-aplikazio bakoitza, gero ezarri nabigatzailearen testuingurua

Zerbitzu bakoitzak onartutako SAML edo OIDC balioak behar ditu: igorlea, bezero-identifikatzailea, dei-itzulera edo baieztapen-kontsumitzailearen URL-a, beharrezko adierazpenak eta esleipena. Irisgarritasuna gainean dator, identitate-egiaztapenek inoiz ez dutelako biderik ez DNS erantzunik ematen.

  1. Sortu aplikazio-sarrera eta berretsi entitate edo bezero IDa aplikazioak bidaltzen duenarekin bat datorrela.
  2. Erregistratu dei-itzulerako URL zehatza, eskema eta ataka barne; hutsegite txiki batek huts egiten du erabiltzaileak autentifikatu ondoren.
  3. Esleitu erabiltzaileak edo taldeak, gero berretsi beharrezko adierazpenak igortzen direla.
  4. Baimendu identitate-hornitzailearen amaierako puntuak eta aplikazio pribatua ere, bestela birbideratzeak ezin du osatu.

Nabigatzailearen testuinguruak erabakitzen du hornitzailearen lehendik dagoen saioa berrerabiltzen den. Sistema-nabigatzailea irekitzen duen bezero natiboak egoera hori parteka dezake, baina bere cookie-ontzia duen ikuspegi integratuak normalean ezin du. Nabigatzaile berriak, leiho pribatuek eta bigarren profilek hutsetik hasten dira, espero dena eta ez SSO konfigurazio hautsia.

Exekutatu fluxua eta irakurri non gelditzen den

Berproduzitu nabigatzailearen sare-panelarekin eta behatu birbideratze-katea. Ibilbide erabilgarriak jauzi bat aldi bakoitzean jarraitzen du: atetik hornitzailera, hornitzailerik aplikaziora kode edo baieztapen batekin, aplikaziotik hornitzailearen token amaierako puntura, aplikazio-saioa igorrita. Katea gelditzen den jauziak konpondu beharreko osagaia izendatzen du.

Komando-lerroko bi egiaztapenek ohiko zalantzak argitzen dituzte, eta biak seguruak dira administrazio-ostalari batetik exekutatzeko:

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

Metadatuak inoiz erregistratu ez zituzten amaierako puntuak zerrendatzen dituenean, aplikazioa beste maizter edo igorle batera ari da seinalatzen. Aplikazioari egindako lehen eskaerak ustekabeko ostalari batera 302 erantzuten duenean, aplikazioaren federazio-konfigurazioa da begiratzeko lekua, ez VPN profila.

Konpondu abisuak nork eskatu duen aurkituta

Bigarren pasahitz-abisua ez da automatikoki akats bat. Aplikazioak berme-maila handiagoa eska dezake, edo hornitzaileak saioaren gehieneko adina eta erronka berria ezar ditzake. Fluxua isilagoa egiteko baldintza horiek kentzeak nahita ezarritako kontrola ahultzen du, beraz, zehaztu zein osagak eskatu zuen politika aldatu aurretik.

Gero erabaki zer hobetu. Abisua aplikaziotik badator, konpondu haren federazio-sarrera. Hornitzailetik politikaren arabera badator, dokumentatu baldintza. Saio-hasiera arrakastatsuaren ondoren aplikazioa eskuraezina bada, tunelaren bideratzea da susmagarria, zeren identitatea eta paketeen entrega leku ezberdinetan huts egiten dute eta antzekoak dirudite erabiltzailearen eserlekutik.

Erlazionatutako artikuluak