VPN SSO istifadəçiləri daxili tətbiqlərə avtomatik daxil edirmi?

Kimlik provayderi vasitəsilə autentifikasiya edən VPN gateway yalnız bir şeyi sübut edir: provayder bir istifadəçiyə gateway qarşısında zəmanət verib. Bu, həmin istifadəçiyə intranet vikisi, monitorinq panelli və ya build serveri üçün etimadnamə vermir. Həmin xidmətlər insanları öz federasiyaları ilə daxil edir və öz avtorizasiyalarını tətbiq edir, tunel isə yalnız hansı paketlərin onlara çata biləcəyini müəyyənləşdirir.

Üç sessiya, üç ayrı qərar

Vəziyyətləri ayrı saxlayın, çünki hər biri öz cədvəli ilə bitir. VPN sessiyası gatewayin kimliyi qəbul etməsi və verdiyi şəbəkə girişidir. Kimlik provayderinin brauzer sessiyası brauzerin həmin provayder üçün hələ saxladığı və siyasətinə uyğun təkrar istifadə edə biləcəyi şeydir. Tətbiq sessiyası isə özünə ünvanlanmış cavabı təsdiqləmiş bir xidmətə aiddir.

Bu vəziyyətləri qarışdırmaq yanlış sual doğurur, adətən tunelin istifadəçini niyə hər yerdə daxil etmədiyi kimi ifadə olunur. Sualı belə dəyişin: hansı tətbiqin federasiya qeydi yoxdur, hansı istifadəçini rədd edir və hansında marşrut çatışmır. İntranet tətbiqini açan tək giriş sorğusu yenə də provayderə qayıda bilər, çünki ikinci yönləndirmə fərqli auditoriya üçün yeni avtorizasiya sorğusudur.

Gatewayi öz tətbiqi kimi qoşun

VPN-i provayderdə təsdiqlənmiş tətbiq kimi qeydiyyata alın, öz identifikatoru, yönləndirmə URI-si və istifadəçi təyinatı ilə. Sonra həmin girişin hansı şəbəkə avtorizasiyalarını verdiyini müəyyənləşdirin, çünki bu, provayder funksiyası deyil, VPN siyasətidir. Yalnız monitorinq subşəbəkəsinə çatmalı olan istifadəçilər fərqli gateway siyasəti alır, fərqli parol deyil.

Tunelin autentifikasiya cavabı təkrar istifadə oluna bilən etimadnamə deyil. OIDC ID tokenləri hansı client üçün yaradıldıqlarını göstərən auditoriya iddiası daşıyır, SAML bearer təsdiqləri isə auditoriyanı qəbul edən xidmət provayderi ilə məhdudlaşdırır. Birinci xidmətin cavabını qəbul edən ikinci xidmət səhv konfiqurasiya edilib, tokeni başqa tətbiqə köçürmək isə inteqrasiya deyil.

Hər daxili tətbiqi qeydiyyata alın, sonra brauzer kontekstini qurun

Hər xidmətə dəstəklənən SAML və ya OIDC dəyərləri lazımdır: buraxan, client identifikatoru, geri çağırış və ya assertion-consumer URL-i, tələb olunan iddialar və təyinat. Əlçatanlıq bunun üstünə gəlir, çünki kimlik yoxlamaları heç vaxt marşrut və ya DNS cavabı vermir.

1. Tətbiq qeydini yaradın və entity və ya client ID-nin tətbiqin göndərdiyi ilə uyğun olduğunu təsdiqləyin.
2. Dəqiq geri çağırış URL-ini sxem və port daxil olmaqla qeyd edin; kiçik səhv istifadəçi autentifikasiya etdikdən sonra uğursuz olur.
3. İstifadəçiləri və ya qrupları təyin edin, sonra tələb olunan iddiaların buraxıldığını təsdiqləyin.
4. Şəxsi tətbiqlə yanaşı kimlik provayderinin son nöqtələrinə də icazə verin, əks halda yönləndirmə tamamlana bilməz.

Brauzer konteksti mövcud provayder sessiyasının təkrar istifadə olunub-olunmayacağını müəyyən edir. Sistem brauzerini açan yerli client bu vəziyyəti paylaşa bilər, öz cookie qabı olan daxili görünüş isə adətən paylaşa bilməz. Yeni brauzer, şəxsi pəncərələr və ikinci profil sıfırdan başlayır; bu, pozulmuş SSO konfiqurasiyası deyil, gözlənilən haldır.

Axını işə salın və harada dayandığını oxuyun

Brauzerin şəbəkə paneli ilə problemi təkrarlayın və yönləndirmə zəncirini izləyin. Faydalı keçid hər dəfə bir addımı izləyir: gatewaydən provayderə, provayderdən kod və ya assertion ilə tətbiqə, tətbiqdən provayderin token son nöqtəsinə, tətbiq sessiyası verilir. Zəncirin dayandığı addım düzəldilməli komponenti göstərir.

İki əmr sətri yoxlaması adi şübhələri həll edir və hər ikisi admin hostdan işə salınmaq üçün təhlükəsizdir:

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

Metadata heç vaxt qeydiyyata almadığınız son nöqtələri sadalayırsa, tətbiq başqa tenant və ya buraxana baxır. Tətbiqə ilk sorğu gözlənilməz hosta 302 cavabı verirsə, axtarılmalı yer VPN profili deyil, tətbiqin federasiya konfiqurasiyasıdır.

Sorğuları kimin soruşduğunu taparaq düzəldin

İkinci parol sorğusu avtomatik qüsur deyil. Tətbiq daha yüksək təminat səviyyəsi tələb edə bilər və ya provayder maksimum sessiya yaşı və yeni çağırış tətbiq edə bilər. Axını daha sakit etmək üçün bu tələbləri silmək qəsdən qoyulmuş nəzarəti zəiflədir, ona görə siyasəti dəyişməzdən əvvəl hansı komponentin soruşduğunu müəyyənləşdirin.

Sonra nəyin yaxşılaşdırılacağına qərar verin. Sorğu tətbiqdən gəlirsə, onun federasiya qeydini düzəldin. Siyasət üzrə provayderdən gəlirsə, tələbi sənədləşdirin. Uğurlu girişdən sonra tətbiq əlçatan deyilsə, şübhəli tunel marşrutlaşdırmasıdır, çünki kimlik və paket çatdırılması müxtəlif yerlərdə uğursuz olur və istifadəçi baxımından oxşar görünür.