Kurumsal ortamlarda çalışan birçok uygulama, SAML veya OIDC gibi modern kimlik standartları yaygınlaşmadan önce geliştirildi. İç portallar, faturalama sistemleri, operasyon panelleri, üretici yönetim konsolları ve eski iş uygulamaları çoğu zaman kullanıcıyı modern token'larla değil; bir HTTP header, Basic Auth bilgisi veya tanıdığı bir oturum çereziyle tanır.
Bu uygulamaları modern SSO'ya taşımak teoride basit görünür: arka uç kimlik doğrulama kodu yeniden yazılır, uygulama SAML/OIDC destekler hâle getirilir ve merkezi kimlik sağlayıcısına bağlanır. Pratikte ise bu çoğu zaman mümkün değildir. Kaynak kodu eski olabilir, uygulama üçüncü taraf sağlayıcıya ait olabilir, değişiklik regülasyon kapsamındaki bir iş akışını bozabilir veya çalışan bir iç araç için bu yatırımın maliyeti haklı çıkmayabilir.
Bu yüzden kurumlar sık sık iki kötü seçenek arasında kalır: Ya eski uygulamaları modern kimlik mimarisinin dışında bırakırlar ya da her uygulama için ayrı, kırılgan ve zor yönetilen geçici entegrasyonlar kurarlar. Sonuçta kullanıcı deneyimi parçalanır, erişim kontrolü merkezi olmaktan çıkar ve kimlik doğrulama her arka ucun kendi eski yöntemine dağılır.
Doğru yaklaşım, modern erişim katmanını uygulamanın önünde konumlandırmaktır. Kullanıcı önce merkezi kimlik, MFA, koşullu erişim ve cihaz güveni kontrollerinden geçer; ardından doğrulanmış kimlik, arka ucun zaten anlayabildiği formata çevrilir. Böylece uygulamanın koduna dokunmadan modern SSO deneyimi sağlanır.
Ancak bu dönüşüm dikkatli yapılmalıdır. Kullanıcıdan gelen sahte kimlik başlıkları temizlenmeden arka uca iletilirse, herhangi biri kendi isteğine X-Auth-User gibi bir başlık ekleyerek başka bir kullanıcı gibi görünebilir. Bu nedenle gateway, gelen güvenilmeyen değerleri ayıklamalı, yalnızca kendi ürettiği güvenilir kimlik bilgisini enjekte etmeli ve bu işlemi rota bazında sıkı şekilde sınırlandırmalıdır.
Logout, oturum kaybı ve arka uçtan gelen kimlik durumu da aynı akış içinde yönetilmelidir. Aksi hâlde kullanıcı portaldan çıkmış görünürken arka uçta oturum açık kalabilir veya arka uç oturumu düşmüşken erişim katmanı bunu fark etmeyebilir.
Backend SSO'nun amacı eski uygulamaları zorla yeniden yazmak değil; modern kimlik kontrolünü uygulamanın önüne alıp, doğrulanmış kullanıcı kimliğini arka ucun zaten kabul ettiği dile güvenli şekilde çevirmektir.
Arka uç başına tek bir yapılandırma nesnesi, beş enjeksiyon şekli, erişim motorunun geri kalanıyla koordineli.
Her enjeksiyon kuralı önce gelen istekteki hedef başlık, çerez veya Authorization değerinin kopyasını ayıklar; sonra kimlik doğrulanmış oturumdan türetilen sürümü enjekte eder. Kendi "X-Auth-User" başlığını gönderen bir kullanıcı başkasının kimliğine bürünemez — kendi başlığı, ağ geçidi güvenilir olanı eklemeden önce kaldırılır.
Özel başlıklar (X-Auth-User, X-Forwarded-User veya arka ucun beklediği herhangi bir şey), kullanıcı adı:parola çifti isteyen uygulamalar için Authorization Basic, token uyumlu arka uçlar için Authorization Bearer, adlandırılmış çerez okuyan uygulamalar için Cookie değeri birleşimi ve imzalı SAML iddiası bekleyen arka uçlar için SAML-SP. Her enjeksiyonun kendi yapılandırması vardır; tek bir arka uç birden çok şekli aynı anda kullanabilir.
Her enjeksiyon kuralı kendi koşul ifadesini taşır — yalnızca yönetici yolunda uygula, yalnızca belirli bir oturum özniteliği varken uygula, yalnızca bir tenant için uygula. Aynı arka uç, ayrıcalıklı rotalarda daha zengin kimlik, açık rotalarda asgari altküme alabilir.
Arka uç "kullanıcının oturumu yok" derse (servis başına bilinen yanıt şekli) ya da arka uç kullanıcının kendisini logout ederse, AAM sinyali algılar, ağ geçidi tarafındaki oturumu temizler ve yapılandırılmış politikaya göre yönlendirme yapar. Logout-wins önceliği, temizliğin her zaman başka bir enjeksiyondan önce çalışmasını garanti eder.
Üretimdeki beş enjeksiyon şekli, bunları güvenli kılan giriş-ayıklama disiplini ve daha üst protokol enjeksiyonları için yol haritası.
En basit ve en yaygın şekil. Bir başlık adı yapılandırılır (X-Auth-User, X-Forwarded-User, REMOTE_USER — arka uç ne okuyorsa) ve değeri üreten akıllı değişken seçilir (kullanıcı adı, e-posta, grup listesi, görüntü adı). Başlık gelen isteklerden ayıklanır, ardından kimlik doğrulanmış oturumdan yeniden eklenir — istek arka uca ulaşmadan önce.
HTTP Basic ile kimlik doğrulayan eski uygulamalar için ağ geçidi, bir kullanıcı adı akıllı değişkeninden ve saklanan bir kimlikten türetilen Authorization: Basic
Zaten Bearer token konuşan arka uçlar için (iç API'ler, mikroservisler, modern intranet uygulamaları) AAM Authorization: Bearer
Kimliği adlandırılmış bir çerezden okuyan uygulamalar çerez-değeri enjeksiyonu ile karşılanır. Ağ geçidi, enjekte edilen name=value çiftini isteğin Cookie başlığına diğer çerezleri ezmeden birleştirir — dört şekil arasında en hata yatkın olanı; saf üzerine yazma yerine açık birleştirme mantığıyla işlenir.
Her istekte imzalı bir SAML iddiası bekleyen arka uçlar için ağ geçidi, kimlik doğrulanmış oturumdan SAML 2.0 iddiası üretir, AAM'in SAML imzalama anahtarı ile imzalar ve yapılandırılmış başlıkta arka uca iletir. Kamu Kimlik Federasyonu entegrasyonları ve kurumsal SaaS arka uçları için tipik. Kullanıcı modern bir IdP ile oturum açar; arka uç her istekte taze, kapsam belirtilmiş bir SAML iddiası alır.
Her enjeksiyon, aynı hedefin gelen tarafında ayıklanmasıyla eşleştirilir. Kendi isteğinde X-Auth-User ayarlayan bir kullanıcı, sahte kimlik değeri taşıyan bir Cookie gönderen veya başka yerden Authorization başlığı tekrarlayan biri, değerin ağ geçidini geçmesini sağlayamaz. Enjeksiyon, ancak ayıklama yuvayı temizledikten sonra çalışır.
Her enjeksiyon kuralı bir koşul ekleyebilir — koşullu erişim politikası ile aynı ifade dili. Yalnızca yönetici yolunda enjekte et; yalnızca kullanıcı belirli bir grupta ise enjekte et; yalnızca belirli bir öznitelik varken ayrıcalıklı varyantı enjekte et. Koşullar ACL-öncelik güvenli şekilde derlenir; aynı arka uçtaki birden çok kural doğru sırada birleşir.
Tüm enjeksiyonlar kimlik doğrulanmış durumun arkasında çalışır — yalnızca istek geçerli bir AAM oturumu taşıyorsa devreye girer. Yanlış yapılandırılmış bir rotadan kimlik doğrulamayı atlayan bir kullanıcı yanlışlıkla enjekte edilmiş arka uç kimlik bilgileri alamaz; anonim bir istek arka uca her zaman enjeksiyonsuz ulaşır.
Daha üst protokol enjeksiyon şekilleri — servis bileti isteyen arka uçlar için Kerberos sınırlı yetki devri, eski Windows ortamları için NTLM — yol haritasındadır. Yapılandırma nesnesi ve koşullu altyapı bunları zaten karşılar; eksik olan protokol-spesifik runtime'dır.
Başlık seviyesinde enjeksiyonu erişim kenarında güvenli kılan mekanikler.
Enjeksiyon başına koşullar, ağ geçidinin diğer ACL-tabanlı kararlarıyla (kimlik doğrulama durumu, erişim politikası, arka uç seçimi) birlikte derlenir. Koşul derleyici extra-entries deseni kullanır; enjeksiyon koşulları her zaman kimlik doğrulama ve politikadan sonra değerlendirilir — bir enjeksiyon kuralı yanlışlıkla daha yüksek öncelikli bir politika kararını çevirebilemez.
Bir enjeksiyon, oturum çantasında olmayan bir değere ihtiyaç duyduğunda — istek başına çekimden türeyen bir değer (grup genişletme, öznitelik araması) — dispatcher yalnızca enjeksiyonun koşulu eşleştiğinde çalışan koşullu bir çekim yayar. Hiçbir enjeksiyon görmeyen arka uçlar değeri çekme maliyetini ödemez.
Her servis "oturumum yok" anlamına gelen yanıt imzasını bildirebilir — belirli bir durum kodu, belirli bir yanıt başlığı, bir gövde işaretçisi. Ağ geçidi o imzayı gördüğünde oturum-kaybı bayrağını koyar, ağ geçidi tarafındaki oturumu temizler ve yapılandırılmış politikaya göre yönlendirir.
Arka ucun kendisi kullanıcıyı çıkış yaptığında — tipik olarak bilinen bir çıkış imzasıyla yanıt vererek — ağ geçidi üç adımlı bir temizlik yapar: ağ geçidi tarafındaki çerezleri sil, oturum kaydını sil ve yapılandırılmış hedef üzerinden yönlendir. Logout-wins önceliği bu yolun uçuş halindeki herhangi bir enjeksiyondan önce gelmesini sağlar.
Enjeksiyonlarda kullanılan kimlik bilgileri ve token'lar yapılandırma deposunda şifreli saklanır ve erişim loglarına asla açık metin yazılmaz. Denetim girdileri bir enjeksiyonun bir istekte çalıştığını kaydeder; hangi değeri taşıdığını değil. Operatör politikayı görür; hat üzerindeki yük hat üzerinde kalır.
Arka uç oturumunu kullanıcıyı login sayfasına geri göndermeden yeniden kurmak için AAM daemon'una 302 ile sessiz yeniden kimlik doğrulama akışı yol haritasındadır. AAM tarafından başlatılan çıkış yayılımı — enjekte edilmiş kimlik alan her arka uca çıkış sinyalini iletmek — de yol haritasındadır.
On yıldır X-Remote-User'a güvenen bir iç portal X-Remote-User okumaya devam eder. Ağ geçidi kenarda modern SAML/OIDC çalıştırır, sonra portalın her zaman gördüğü aynı başlığı enjekte eder. Arka uç dağıtımı yok, geçiş kesintisi yok.
İç mikroservis kümesi Bearer token kimlik doğrulaması ister ama servis başına bir kimlik akışı çalıştırmak istemez. Ağ geçidi istek başına imzalı bir token üretip enjekte eder; her servis token'ı ağ geçidinin anahtarlarına karşı doğrular.
Çok-uygulama bir dağıtımda bir uygulama Basic Auth ister, biri özel başlık ister, biri çerez ister. Bir AAM ağ geçidi login'i bir kez halleder; her arka uç beklediği şekli — eş zamanlı, rota başına koşullarla — alır.
Net bir kimlik zinciri isteyen uyumluluk düzenlemeleri — "bu istek arka uca düştüğünde kim kimlik doğrulamış durumdaydı" — bu zinciri ağ geçidinin denetim akışından alır. Başlık değerleri, enjeksiyon koşulları ve kimlik doğrulanmış kullanıcı birlikte kaydedilir.
Backend SSO'yu gerçek uygulamalarınız üzerinde konuşlandıralım — mevcut güven modellerini koruyarak, kimlik bilgisini kullanıcının elinden alarak ve her istek için denetim kalitesinde bir kimlik zinciri üreterek.