VPN SSO foydalanuvchilarni ichki ilovalarga avtomatik kiritadimi?

Bitta kirish tunnelni va uning orqasidagi ilovalarni qamrab olishi mumkin, lekin faqat har bir ilovaning o'z ishonchi bo'lsa. Uni ulash va sinash tartibi quyidagicha.

Identifikatsiya provayderi orqali autentifikatsiya qiluvchi VPN shlyuzi bitta narsani isbotlaydi: provayder foydalanuvchi uchun shlyuz oldida kafolat berdi. U bu foydalanuvchiga ichki tarmoq vikisiga, monitoring paneliga yoki build serveriga hech qanday hisob ma'lumotlarini bermaydi. Bu xizmatlar odamlarni o'z federatsiyasi orqali kiritadi va o'z avtorizatsiyasini qo'llaydi, tunnel esa faqat qaysi paketlar ularga yetib borishini hal qiladi.

Uch sessiya, uchta alohida qaror

Holatlarni alohida saqlang, chunki har biri o'z jadvali bo'yicha tugaydi. VPN sessiyasi — bu shlyuzning identifikatsiyani qabul qilishi va bergan tarmoq ruxsati. Provayderdagi brauzer sessiyasi — brauzer hali ham shu provayder uchun saqlaydigan va siyosatiga ko'ra qayta ishlatishi mumkin bo'lgan narsa. Ilova sessiyasi esa o'ziga yuborilgan javobni tasdiqlagan bitta xizmatga tegishli.

Bu holatlarni aralashtirish noto'g'ri savol tug'diradi, odatda tunnel nega foydalanuvchini hamma joyda kiritmaydi deb so'raladi. Savolni boshqacha qo'ying: qaysi ilovada federatsiya yozuvi yo'q, qaysi biri foydalanuvchini rad etadi va qaysi birida marshrut yetishmaydi. Ichki tarmoq ilovasini ochadigan bitta kirish so'rovi baribir provayderga qaytishi mumkin, chunki ikkinchi yo'naltirish boshqa auditoriya uchun yangi avtorizatsiya so'rovi.

Shlyuzni o'z ilovasi sifatida ulang

VPNni provayderda tasdiqlangan ilova sifatida ro'yxatdan o'tkazing, o'z identifikatori, yo'naltirish URI va foydalanuvchilarni tayinlash bilan. Keyin bu kirish qanday tarmoq avtorizatsiyalarini berishini hal qiling, chunki bu VPN siyosati, provayder xususiyati emas. Faqat monitoring quyi tarmog'iga yetishi kerak bo'lgan foydalanuvchilar boshqa shlyuz siyosatini oladi, boshqa parolni emas.

Tunnelning autentifikatsiya javobi qayta ishlatiladigan hisob ma'lumoti emas. OIDC ID tokenlari qaysi mijoz uchun chiqarilganini ko'rsatuvchi auditoriya da'vosini olib yuradi, SAML bearer bayonotlari esa auditoriyani qabul qiluvchi xizmat provayderi bilan cheklaydi. Birinchi xizmatning javobini qabul qiladigan ikkinchi xizmat noto'g'ri sozlangan, tokenni boshqa ilovaga ko'chirish esa integratsiya emas.

Har bir ichki ilovani ro'yxatdan o'tkazing, keyin brauzer kontekstini sozlang

Har bir xizmatga qo'llab-quvvatlanadigan SAML yoki OIDC qiymatlari kerak: chiqaruvchi, mijoz identifikatori, qayta qo'ng'iroq yoki bayonot iste'molchisi URL, talab qilinadigan da'volar va tayinlash. Yetib borish shundan keyin keladi, chunki identifikatsiya tekshiruvlari hech qachon marshrut yoki DNS javobini bermaydi.

  1. Ilova yozuvini yarating va sub'ekt yoki mijoz ID ilova yuboradigan narsaga mos kelishini tasdiqlang.
  2. Sxema va portni o'z ichiga olgan aniq qayta qo'ng'iroq URLni ro'yxatdan o'tkazing; kichik xato foydalanuvchi autentifikatsiya qilinganidan keyin muvaffaqiyatsiz bo'ladi.
  3. Foydalanuvchilar yoki guruhlarni tayinlang, keyin talab qilinadigan da'volar chiqarilishini tasdiqlang.
  4. Xususiy ilova bilan birga identifikatsiya provayderining so'nggi nuqtalariga ham ruxsat bering, aks holda yo'naltirish tugamaydi.

Brauzer konteksti mavjud provayder sessiyasi qayta ishlatilishini hal qiladi. Tizim brauzerini ochadigan mahalliy mijoz bu holatni bo'lishishi mumkin, o'z cookie idishi bo'lgan ichki ko'rinish esa odatda bo'lisha olmaydi. Yangi brauzer, maxfiy oynalar va ikkinchi profil noldan boshlanadi, bu kutilgan holat, buzilgan SSO konfiguratsiyasi emas.

Oqimni ishga tushiring va qayerda to'xtashini o'qing

Brauzerning tarmoq paneli bilan qayta hosil qiling va yo'naltirish zanjirini kuzating. Foydali o'tish bir vaqtning o'zida bitta sakrashni kuzatadi: shlyuzdan provayderga, provayderdan kod yoki bayonot bilan ilovaga, ilovadan provayderning token so'nggi nuqtasiga, ilova sessiyasi chiqariladi. Zanjir to'xtaydigan sakrash tuzatiladigan komponentni nomlaydi.

Ikki buyruq qatori tekshiruvi odatiy shubhalarni hal qiladi va ikkalasini ham administrator xostidan ishga tushirish xavfsiz:

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

Metama'lumotlar siz hech qachon ro'yxatdan o'tkazmagan so'nggi nuqtalarni sanab o'tsa, ilova boshqa ijarachi yoki chiqaruvchiga ishora qiladi. Ilovaga birinchi so'rov kutilmagan xostga 302 deb javob bersa, qarash kerak bo'lgan joy — ilovaning federatsiya konfiguratsiyasi, VPN profili emas.

Kim so'raganini topib, so'rovlarni tuzating

Ikkinchi parol so'rovi avtomatik ravishda nuqson emas. Ilova yuqoriroq kafolat darajasini so'rashi mumkin, yoki provayder sessiyaning eng katta yoshini va yangi sinovni talab qilishi mumkin. Oqimni tinchroq qilish uchun bu talablarni olib tashlash ataylab qo'yilgan nazoratni zaiflashtiradi, shuning uchun siyosatni o'zgartirishdan oldin qaysi komponent so'raganini aniqlang.

Keyin nimani yaxshilashni hal qiling. So'rov ilovadan kelsa, uning federatsiya yozuvini tuzating. Siyosat bo'yicha provayderdan kelsa, talabni hujjatlashtiring. Muvaffaqiyatli kirishdan keyin ilovaga yetib bo'lmasa, shubhali — tunnelning marshrutlanishi, chunki identifikatsiya va paketlarni yetkazish turli joylarda muvaffaqiyatsiz bo'ladi va foydalanuvchi o'rnidan bir xil ko'rinadi.

O'xshash maqolalar