Adakah SSO VPN mendaftar masuk pengguna ke aplikasi dalaman secara automatik?

Gerbang VPN yang mengesahkan melalui penyedia identiti membuktikan satu perkara: penyedia menjamin seorang pengguna di hadapan gerbang. Ia tidak memberikan pengguna itu kelayakan untuk wiki intranet, papan pemuka pemantauan atau pelayan build. Perkhidmatan itu mendaftar masuk orang melalui persekutuan mereka sendiri dan menggunakan kebenaran mereka sendiri, dan terowong hanya menentukan paket mana yang boleh mencapainya.

Tiga sesi, tiga keputusan berasingan

Asingkan keadaan itu, kerana setiap satu tamat mengikut jadualnya sendiri. Sesi VPN ialah penerimaan identiti oleh gerbang serta akses rangkaian yang diberikannya. Sesi pelayar di penyedia identiti ialah apa yang masih dipegang pelayar untuk penyedia itu dan boleh digunakan semula mengikut dasarnya. Sesi aplikasi milik satu perkhidmatan yang mengesahkan respons yang dialamatkan kepadanya.

Mencampurkan keadaan itu menghasilkan soalan yang salah, biasanya dirumuskan sebagai mengapa terowong tidak mendaftar masuk pengguna di mana-mana. Rumuskan semula: aplikasi mana yang tiada entri persekutuan, mana yang menolak pengguna, dan mana yang kekurangan laluan. Satu gesaan daftar masuk yang membuka aplikasi intranet masih boleh melantun kembali kepada penyedia, kerana ubah hala kedua ialah permintaan kebenaran baharu untuk khalayak berbeza.

Sambungkan gerbang sebagai aplikasinya sendiri

Daftarkan VPN sebagai aplikasi yang diluluskan di penyedia, dengan pengecam, URI ubah hala dan penetapan penggunanya sendiri. Kemudian tentukan kebenaran rangkaian yang diberikan oleh daftar masuk itu, kerana itu dasar VPN, bukan ciri penyedia. Pengguna yang sepatutnya hanya mencapai subrangkaian pemantauan mendapat dasar gerbang berbeza, bukan kata laluan berbeza.

Respons pengesahan terowong bukan kelayakan yang boleh digunakan semula. Token ID OIDC membawa dakwaan khalayak yang menamakan klien yang menjadi tujuannya, dan pernyataan pembawa SAML mengehadkan khalayak kepada penyedia perkhidmatan penerima. Perkhidmatan kedua yang menerima respons perkhidmatan pertama salah dikonfigurasikan, dan menyalin token ke aplikasi lain bukan integrasi.

Daftarkan setiap aplikasi dalaman, kemudian tetapkan konteks pelayar

Setiap perkhidmatan memerlukan nilai SAML atau OIDC yang disokong: pengeluar, pengecam klien, URL panggilan balik atau pengguna pernyataan, dakwaan yang diperlukan dan penetapan. Kebolehcapaian datang di atasnya, kerana pemeriksaan identiti tidak pernah menyediakan laluan atau jawapan DNS.

1. Cipta entri aplikasi dan sahkan bahawa ID entiti atau klien sepadan dengan apa yang dihantar oleh aplikasi.
2. Daftarkan URL panggilan balik yang tepat termasuk skema dan port; kesilapan kecil gagal selepas pengguna disahkan.
3. Tetapkan pengguna atau kumpulan, kemudian sahkan bahawa dakwaan yang diperlukan dikeluarkan.
4. Benarkan titik akhir penyedia identiti serta aplikasi peribadi, jika tidak ubah hala tidak dapat diselesaikan.

Konteks pelayar menentukan sama ada sesi penyedia sedia ada digunakan semula. Klien asli yang membuka pelayar sistem boleh berkongsi keadaan itu, manakala paparan terbenam dengan balang kuki sendiri biasanya tidak boleh. Pelayar baharu, tetingkap peribadi dan profil kedua semuanya bermula dari kosong, yang dijangka dan bukan konfigurasi SSO yang rosak.

Jalankan aliran dan baca di mana ia berhenti

Hasilkan semula dengan panel rangkaian pelayar dan perhatikan rantaian ubah hala. Laluan yang berguna mengikut satu lompatan pada satu masa: gerbang ke penyedia, penyedia kembali ke aplikasi dengan kod atau pernyataan, aplikasi ke titik akhir token penyedia, sesi aplikasi dikeluarkan. Lompatan tempat rantaian berhenti menamakan komponen yang perlu dibaiki.

Dua pemeriksaan baris arahan menyelesaikan keraguan biasa, dan kedua-duanya selamat dijalankan dari hos admin:

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

Apabila metadata menyenaraikan titik akhir yang tidak pernah anda daftarkan, aplikasi menunjuk kepada penyewa atau pengeluar lain. Apabila permintaan pertama ke aplikasi menjawab 302 ke hos yang tidak dijangka, konfigurasi persekutuan aplikasi ialah tempat untuk diperiksa, bukan profil VPN.

Betulkan gesaan dengan mencari siapa yang memintanya

Gesaan kata laluan kedua bukan automatik kecacatan. Aplikasi mungkin meminta tahap jaminan yang lebih tinggi, atau penyedia mungkin mengenakan umur sesi maksimum dan cabaran baharu. Mengalih keluar keperluan itu untuk menjadikan aliran lebih senyap melemahkan kawalan yang disengajakan, jadi tentukan komponen mana yang memintanya sebelum mengubah dasar.

Kemudian tentukan apa yang perlu diperbaiki. Jika gesaan datang dari aplikasi, betulkan entri persekutuannya. Jika ia datang dari penyedia mengikut dasar, dokumentasikan keperluan itu. Jika aplikasi tidak boleh dicapai selepas daftar masuk berjaya, penghalaan terowong ialah suspek, kerana identiti dan penghantaran paket gagal di tempat berbeza dan kelihatan serupa dari tempat duduk pengguna.