Vai VPN SSO automātiski pieraksta lietotājus iekšējās lietotnēs?

VPN vārteja, kas autentificējas pie identitātes nodrošinātāja, pierāda vienu lietu: nodrošinātājs galvoja par lietotāju vārtejas priekšā. Tā nepiešķir šim lietotājam akreditācijas datus iekšējā tīkla viki, uzraudzības panelim vai build serverim. Šie pakalpojumi pieraksta cilvēkus caur savu federāciju un piemēro savu autorizāciju, un tunelis tikai izlemj, kuri paketes var tos sasniegt.

Trīs sesijas, trīs atsevišķi lēmumi

Turiet stāvokļus atsevišķi, jo katrs beidzas pēc sava grafika. VPN sesija ir vārtejas identitātes pieņemšana plus piešķirtā tīkla piekļuve. Identitātes nodrošinātāja pārlūka sesija ir tas, ko pārlūks vēl glabā šim nodrošinātājam un var atkārtoti izmantot saskaņā ar tā politiku. Lietotnes sesija pieder vienam pakalpojumam, kas validēja tam adresētu atbildi.

Šo stāvokļu sajaukšana rada nepareizo jautājumu, parasti formulētu kā kāpēc tunelis nepieraksta lietotāju visur. Pārformulējiet: kurai lietotnei nav federācijas ieraksta, kura noraida lietotāju un kurai trūkst maršruta. Viena pierakstīšanās uzvedne, kas atver iekšējā tīkla lietotni, joprojām var atlēkt atpakaļ pie nodrošinātāja, jo otrais novirzījums ir jauns autorizācijas pieprasījums citai auditorijai.

Savienojiet vārteju kā savu lietotni

Reģistrējiet VPN kā apstiprinātu lietotni pie nodrošinātāja ar savu identifikatoru, novirzīšanas URI un lietotāju piešķiršanu. Pēc tam izlemiet, kādas tīkla autorizācijas šī pierakstīšanās piešķir, jo tā ir VPN politika, nevis nodrošinātāja funkcija. Lietotāji, kuriem jāsasniedz tikai uzraudzības apakštīkls, saņem citu vārtejas politiku, nevis citu paroli.

Tuneļa autentifikācijas atbilde nav atkārtoti izmantojami akreditācijas dati. OIDC ID marķieri satur auditorijas apgalvojumu, kas nosauc klientu, kuram tie izsniegti, un SAML bearer apgalvojumi ierobežo auditoriju ar saņēmēju pakalpojumu nodrošinātāju. Otrs pakalpojums, kas pieņem pirmā atbildi, ir nepareizi konfigurēts, un marķiera kopēšana citā lietotnē nav integrācija.

Reģistrējiet katru iekšējo lietotni, pēc tam iestatiet pārlūka kontekstu

Katrai lietotnei ir vajadzīgas atbalstītās SAML vai OIDC vērtības: izdevējs, klienta identifikators, atzvanīšanas vai apgalvojuma patērētāja URL, nepieciešamie apgalvojumi un piešķiršana. Sasniedzamība nāk virsū, jo identitātes pārbaudes nekad nenodrošina maršrutu vai DNS atbildi.

1. Izveidojiet lietotnes ierakstu un apstipriniet, ka entītijas vai klienta ID atbilst tam, ko lietotne sūta.
2. Reģistrējiet precīzu atzvanīšanas URL, ieskaitot shēmu un portu; neliela kļūda neizdodas pēc lietotāja autentifikācijas.
3. Piešķiriet lietotājus vai grupas, pēc tam apstipriniet, ka nepieciešamie apgalvojumi tiek izsniegti.
4. Atļaujiet identitātes nodrošinātāja galapunktus un arī privāto lietotni, citādi novirzīšana nevar pabeigties.

Pārlūka konteksts izlemj, vai esošā nodrošinātāja sesija tiks atkārtoti izmantota. Vietējais klients, kas atver sistēmas pārlūku, var koplietot šo stāvokli, bet iegultais skats ar savu sīkfailu krātuvi parasti nevar. Jauns pārlūks, privātie logi un otrs profils sāk no nulles, kas ir gaidīts, nevis salauzta SSO konfigurācija.

Palaidiet plūsmu un izlasiet, kur tā apstājas

Atveidojiet ar pārlūka tīkla paneli un novērojiet novirzīšanas ķēdi. Noderīga pāreja seko vienam lēcienam pēc otra: no vārtejas pie nodrošinātāja, no nodrošinātāja atpakaļ lietotnē ar kodu vai apgalvojumu, no lietotnes pie nodrošinātāja marķiera galapunkta, tiek izsniegta lietotnes sesija. Lēciens, kurā ķēde apstājas, nosauc labojamo komponentu.

Divi komandrindas pārbaudes atrisina ierastās šaubas, un abas ir droši palaist no administratora resursdatora:

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

Kad metadati uzskaita galapunktus, ko nekad neesat reģistrējis, lietotne norāda uz citu nomnieku vai izdevēju. Kad pirmā pieprasījums lietotnei atbild 302 uz negaidītu resursdatoru, jāmeklē lietotnes federācijas konfigurācijā, nevis VPN profilā.

Labojiet uzvednes, noskaidrojot, kas tās pieprasīja

Otra paroles uzvedne nav automātiski defekts. Lietotne var pieprasīt augstāku apliecinājuma līmeni, vai nodrošinātājs var noteikt maksimālo sesijas vecumu un jaunu izaicinājumu. Šo prasību noņemšana, lai plūsma būtu klusāka, vājina apzinātu kontroli, tāpēc pirms politikas maiņas nosakiet, kurš komponents to pieprasīja.

Pēc tam izlemiet, ko uzlabot. Ja uzvedne nāk no lietotnes, labojiet tās federācijas ierakstu. Ja tā nāk no nodrošinātāja saskaņā ar politiku, dokumentējiet prasību. Ja pēc veiksmīgas pierakstīšanās lietotne nav sasniedzama, aizdomās ir tuneļa maršrutēšana, jo identitāte un pakešu piegāde neizdodas dažādās vietās un no lietotāja vietas izskatās līdzīgi.