VPN SSO kullanıcıları dahili uygulamalara otomatik olarak giriş yapıyor mu?

Kimlik sağlayıcı üzerinden kimlik doğrulayan bir VPN ağ geçidi tek bir şeyi kanıtlar: sağlayıcı, ağ geçidinin önünde bir kullanıcı için kefil olmuştur. Bu kullanıcıya intranet wiki'si, izleme panosu veya derleme sunucusu için kimlik bilgisi vermez. Bu hizmetler kişileri kendi federasyonları üzerinden oturum açar ve kendi yetkilendirmelerini uygular; tünel ise yalnızca hangi paketlerin onlara ulaşabileceğine karar verir.

Üç oturum, üç ayrı karar

Durumları ayrı tutun, çünkü her biri kendi takvimine göre sona erer. VPN oturumu, ağ geçidinin bir kimliği kabul etmesi ve verdiği ağ erişimidir. Kimlik sağlayıcıdaki tarayıcı oturumu, tarayıcının o sağlayıcı için hâlâ tuttuğu ve politikasına göre yeniden kullanabileceği şeydir. Uygulama oturumu ise kendisine yöneltilmiş bir yanıtı doğrulayan tek bir hizmete aittir.

Bu durumları karıştırmak yanlış soruyu üretir; genellikle tünel neden kullanıcıyı her yerde oturum açmıyor diye sorulur. Soruyu yeniden kurun: hangi uygulamanın federasyon kaydı yok, hangisi kullanıcıyı reddediyor ve hangisinde yol eksik. İntranet uygulamasını açan tek bir oturum açma istemi bile sağlayıcıya geri dönebilir, çünkü ikinci yönlendirme farklı bir kitle için yeni bir yetkilendirme isteğidir.

Ağ geçidini kendi uygulaması olarak bağlayın

VPN'i sağlayıcıda onaylı bir uygulama olarak kaydedin; kendi tanımlayıcısı, yönlendirme URI'si ve kullanıcı atamasıyla. Sonra bu oturum açmanın hangi ağ yetkilendirmelerini verdiğine karar verin, çünkü bu bir VPN politikasıdır, sağlayıcı özelliği değildir. Yalnızca izleme alt ağına ulaşması gereken kullanıcılar farklı bir ağ geçidi politikası alır, farklı bir parola değil.

Tünelin kimlik doğrulama yanıtı yeniden kullanılabilir bir kimlik bilgisi değildir. OIDC ID belirteçleri, hangi istemci için üretildiklerini belirten bir kitle iddiası taşır ve SAML taşıyıcı beyanları kitleyi alıcı hizmet sağlayıcıyla sınırlar. İlk hizmetin yanıtını kabul eden ikinci hizmet yanlış yapılandırılmıştır ve bir belirteci başka bir uygulamaya kopyalamak entegrasyon değildir.

Her dahili uygulamayı kaydedin, sonra tarayıcı bağlamını ayarlayın

Her hizmet, desteklenen SAML veya OIDC değerlerine ihtiyaç duyar: veren, istemci tanımlayıcısı, geri çağırma veya beyan tüketicisi URL'si, gerekli iddialar ve atama. Erişilebilirlik bunun üzerine gelir, çünkü kimlik denetimleri hiçbir zaman bir yol veya DNS yanıtı sağlamaz.

1. Uygulama kaydını oluşturun ve varlık veya istemci kimliğinin uygulamanın gönderdiğiyle eşleştiğini doğrulayın.
2. Şema ve bağlantı noktası dahil tam geri çağırma URL'sini kaydedin; küçük bir hata kullanıcı kimlik doğruladıktan sonra başarısız olur.
3. Kullanıcıları veya grupları atayın, ardından gerekli iddiaların verildiğini doğrulayın.
4. Özel uygulamanın yanı sıra kimlik sağlayıcının uç noktalarına da izin verin, aksi halde yönlendirme tamamlanamaz.

Tarayıcı bağlamı, mevcut sağlayıcı oturumunun yeniden kullanılıp kullanılmayacağına karar verir. Sistem tarayıcısını açan yerel bir istemci bu durumu paylaşabilir, kendi çerez kavanozu olan gömülü bir görünüm ise genellikle paylaşamaz. Yeni tarayıcı, gizli pencereler ve ikinci profil sıfırdan başlar; bu beklenen bir durumdur, bozuk bir SSO yapılandırması değildir.

Akışı çalıştırın ve nerede durduğunu okuyun

Tarayıcının ağ paneliyle yeniden üretin ve yönlendirme zincirini izleyin. Yararlı bir geçiş her seferinde bir sıçramayı izler: ağ geçidinden sağlayıcıya, sağlayıcıdan kod veya beyanla uygulamaya, uygulamadan sağlayıcının belirteç uç noktasına, uygulama oturumu verilir. Zincirin durduğu sıçrama, düzeltilecek bileşeni adlandırır.

İki komut satırı denetimi olağan kuşkuları çözer ve ikisi de yönetici ana bilgisayarından çalıştırılmak için güvenlidir:

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

Meta veriler hiç kaydetmediğiniz uç noktaları listeliyorsa uygulama başka bir kiracıya veya verene işaret ediyor demektir. Uygulamaya giden ilk istek beklenmedik bir ana bilgisayara 302 yanıtı veriyorsa bakılacak yer VPN profili değil, uygulamanın federasyon yapılandırmasıdır.

İstemleri kimin istediğini bularak düzeltin

İkinci parola istemi otomatik olarak bir kusur değildir. Uygulama daha yüksek bir güvence düzeyi isteyebilir veya sağlayıcı azami oturum yaşını ve yeni bir meydan okumayı zorunlu kılabilir. Akışı daha sessiz yapmak için bu gereksinimleri kaldırmak bilinçli bir denetimi zayıflatır, bu yüzden politikayı değiştirmeden önce hangi bileşenin istediğini belirleyin.

Sonra neyin iyileştirileceğine karar verin. İstem uygulamadan geliyorsa federasyon kaydını düzeltin. Politikaya göre sağlayıcıdan geliyorsa gereksinimi belgeleyin. Başarılı bir oturum açmadan sonra uygulamaya ulaşılamıyorsa şüpheli olan tünel yönlendirmesidir, çünkü kimlik ve paket teslimi farklı yerlerde başarısız olur ve kullanıcının oturduğu yerden benzer görünür.