Apakah SSO VPN memasukkan pengguna ke aplikasi internal secara otomatis?

Gateway VPN yang mengautentikasi melalui penyedia identitas membuktikan satu hal: penyedia menjamin seorang pengguna di hadapan gateway. Gateway itu tidak memberikan kredensial kepada pengguna tersebut untuk wiki intranet, dasbor pemantauan, atau server build. Layanan-layanan itu memasukkan orang melalui federasi mereka sendiri dan menerapkan otorisasi mereka sendiri, dan terowongan hanya menentukan paket mana yang dapat mencapainya.

Tiga sesi, tiga keputusan terpisah

Pisahkan statusnya, karena masing-masing kedaluwarsa sesuai jadwalnya sendiri. Sesi VPN adalah penerimaan identitas oleh gateway ditambah akses jaringan yang diberikannya. Sesi peramban di penyedia identitas adalah apa yang masih dipegang peramban untuk penyedia itu dan dapat digunakan kembali sesuai kebijakannya. Sesi aplikasi milik satu layanan yang memvalidasi respons yang dialamatkan kepadanya.

Mencampurkan status-status itu menghasilkan pertanyaan yang salah, biasanya dirumuskan sebagai mengapa terowongan tidak memasukkan pengguna di mana-mana. Rumuskan ulang: aplikasi mana yang tidak punya entri federasi, mana yang menolak pengguna, dan mana yang kehilangan rute. Satu permintaan masuk yang membuka aplikasi intranet masih bisa memantul ke penyedia, karena pengalihan kedua adalah permintaan otorisasi baru untuk audiens yang berbeda.

Hubungkan gateway sebagai aplikasinya sendiri

Daftarkan VPN sebagai aplikasi yang disetujui di penyedia, dengan pengenal, URI pengalihan, dan penetapan pengguna miliknya sendiri. Lalu tentukan otorisasi jaringan apa yang diberikan oleh proses masuk itu, karena itu kebijakan VPN, bukan fitur penyedia. Pengguna yang seharusnya hanya menjangkau subnet pemantauan mendapat kebijakan gateway yang berbeda, bukan kata sandi yang berbeda.

Respons autentikasi terowongan bukan kredensial yang dapat digunakan ulang. Token ID OIDC membawa klaim audiens yang menyebut klien tempat token itu diterbitkan, dan asersi pembawa SAML membatasi audiens ke penyedia layanan penerima. Layanan kedua yang menerima respons layanan pertama salah dikonfigurasi, dan menyalin token ke aplikasi lain bukanlah integrasi.

Daftarkan setiap aplikasi internal, lalu atur konteks peramban

Setiap layanan memerlukan nilai SAML atau OIDC yang didukung: penerbit, pengenal klien, URL callback atau konsumen asersi, klaim yang diperlukan, dan penetapan. Keterjangkauan datang di atasnya, karena pemeriksaan identitas tidak pernah menyediakan rute atau jawaban DNS.

1. Buat entri aplikasi dan pastikan ID entitas atau klien cocok dengan yang dikirim aplikasi.
2. Daftarkan URL callback yang persis, termasuk skema dan port; kesalahan kecil gagal setelah pengguna terautentikasi.
3. Tetapkan pengguna atau grup, lalu pastikan klaim yang diperlukan dilepaskan.
4. Izinkan titik akhir penyedia identitas serta aplikasi privat, atau pengalihan tidak dapat selesai.

Konteks peramban menentukan apakah sesi penyedia yang ada digunakan kembali. Klien native yang membuka peramban sistem dapat berbagi status itu, sedangkan tampilan tersemat dengan toples cookie sendiri biasanya tidak bisa. Peramban baru, jendela privat, dan profil kedua semuanya mulai dari nol, yang memang diharapkan dan bukan konfigurasi SSO yang rusak.

Jalankan alur dan baca di mana ia berhenti

Reproduksi dengan panel jaringan peramban dan perhatikan rantai pengalihan. Lintasan yang berguna mengikuti satu lompatan setiap kali: gateway ke penyedia, penyedia kembali ke aplikasi dengan kode atau asersi, aplikasi ke titik akhir token penyedia, sesi aplikasi diterbitkan. Lompatan tempat rantai berhenti menyebutkan komponen yang harus diperbaiki.

Dua pemeriksaan baris perintah menyelesaikan keraguan yang biasa, dan keduanya aman dijalankan dari host 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:)'

Ketika metadata mencantumkan titik akhir yang tidak pernah Anda daftarkan, aplikasi menunjuk ke penyewa atau penerbit yang berbeda. Ketika permintaan pertama ke aplikasi menjawab 302 ke host yang tak terduga, konfigurasi federasi aplikasi adalah tempat untuk diperiksa, bukan profil VPN.

Perbaiki permintaan dengan menemukan siapa yang meminta

Permintaan kata sandi kedua bukan otomatis cacat. Aplikasi mungkin meminta tingkat jaminan yang lebih tinggi, atau penyedia mungkin memberlakukan usia sesi maksimum dan tantangan baru. Menghapus persyaratan itu agar alur lebih sunyi melemahkan kontrol yang disengaja, jadi pastikan komponen mana yang meminta sebelum mengubah kebijakan.

Lalu tentukan apa yang harus diperbaiki. Jika permintaan datang dari aplikasi, perbaiki entri federasinya. Jika datang dari penyedia berdasarkan kebijakan, dokumentasikan persyaratannya. Jika aplikasi tidak terjangkau setelah proses masuk berhasil, perutean terowongan adalah tersangkanya, karena identitas dan pengiriman paket gagal di tempat yang berbeda dan terlihat serupa dari kursi pengguna.