Modern uygulamalarda OIDC giderek daha fazla kullanılsa da, SAML 2.0 kurumsal ve kamu kimlik entegrasyonlarında hâlâ kritik bir standarttır. Birçok kurum AD FS, Entra ID, Okta, Ping, Auth0 veya federasyon gateway'i arkasındaki mevcut dizinlerini SAML üzerinden çalıştırır. Kamu tarafında da ulusal kimlik federasyonları ve bunlara bağlı SaaS hizmetleri çoğu zaman SAML 2.0 üzerine kuruludur.
Bu yüzden yeni veya modernleştirilen bir uygulama için doğru yaklaşım, ayrı bir kullanıcı veritabanı oluşturmak değildir. Uygulama, kurumun zaten güvendiği kimlik sağlayıcısına bağlanmalıdır. Bunun için erişim katmanının SAML 2.0 servis sağlayıcısı olarak davranması gerekir: kullanıcıyı doğru IdP'ye yönlendirmeli, gelen SAML yanıtını doğrulamalı, kimliği güvenli şekilde çıkarmalı ve uygulamanın kullanabileceği bir oturuma çevirmelidir.
Ancak SAML entegrasyonu yalnızca "XML'i al, kullanıcıyı oku, oturum aç" işi değildir. Yanlış uygulandığında ciddi güvenlik açıkları üretir. SAML yanıtındaki imzanın doğru doğrulanması, hangi alanın gerçekten imzalandığının kontrol edilmesi, imza kaldırma veya sahte assertion ekleme gibi saldırıların engellenmesi gerekir. Geçerlilik süresi, audience kısıtlaması, issuer bilgisi, NameID formatı ve öznitelik eşlemeleri yalnızca okunmamalı; sıkı şekilde uygulanmalıdır.
Operasyonel taraf da aynı derecede önemlidir. IdP metadata'sının güncellenmesi, sertifika ve imzalama anahtarı rotasyonu, tenant başına farklı IdP yönlendirmesi, farklı uygulamalar için farklı eşleme kuralları ve Single Logout akışları sonradan eklenen küçük detaylar değildir. Bunlar SAML federasyonunun güvenli ve sürdürülebilir çalışması için temel parçalardır.
En yaygın hatalardan biri, her uygulamaya ayrı ayrı SAML kütüphanesi gömmektir. Bu yaklaşım kimlik sorumluluğunu her arka uca dağıtır. Bir IdP değişikliği çok sayıda uygulamada ayrı ayrı güncelleme gerektirir. MFA, koşullu erişim, cihaz güveni, logout davranışı ve denetim kayıtları her uygulama için yeniden çözülmeye çalışılır. Sonuç merkezi kimlik değil, dağıtılmış kimlik karmaşasıdır.
Doğru yer erişim kenarıdır. SAML tek noktada sonlandırılmalı; kimlik doğrulama, MFA, koşullu erişim, cihaz güveni ve Backend SSO ile aynı katmanda yönetilmelidir. Böylece uygulamalar federasyon protokolünün karmaşıklığını taşımaz; yalnızca doğrulanmış, temiz ve güvenilir bir kimlik alır.
SAML'i doğru yönetmek, sadece bir IdP'ye bağlanmak değildir. Kurumun kimlik güvenini tek noktada doğrulamak, denetlemek ve uygulamalara güvenli şekilde taşımaktır.
Tek bir AAM ağ geçidi SAML'i kenarda doğru biçimde sonlandırır; erişim motorunun geri kalanı bunun üzerine biner.
Çıkışta imzalı AuthnRequest, gelişte tam iddia doğrulaması — imza, audience, geçerlilik penceresi, AudienceRestriction, NameID formatı. HTTP-Redirect ve HTTP-POST binding'lerinin ikisi de desteklenir. İmza işleme, bilinen SAML saldırılarını alt etmek için var olan SAML 2.0 uyumluluk kurallarını takip eder.
Tek bir AAM ağ geçidi farklı uygulamaları farklı IdP'lere ve aynı uygulamanın farklı tenant'larını farklı IdP'lere aynı anda yönlendirebilir. IdP seçimi, uygulama bağlamından istek başına yapılır — IdP başına ayrı ağ geçidi yok, kullanıcı için manuel login-sayfası seçici yok.
IdP başına eşleme kuralları, SAML iddiasının NameID'sini ve öznitelik beyanlarını AAM'in geri kalanının kullandığı kanonik alanlara çevirir — kullanıcı adı, e-posta, gruplar, görüntü adı, özel öznitelikler. Aynı eşleme MFA gating'i, koşullu erişim ifadelerini, denetim loglarını ve Backend SSO enjeksiyonlarını besler.
Bir SAML kimlik doğrulaması tek başına çalışmaz — kenardaki MFA (IdP step-up uygulamadıysa), koşullu erişim ifadeleri, sürekli güven değerlendirmesi ve arka uca doğru Backend SSO enjeksiyonu ile birlikte bestelenir. SAML iddiası AAM oturumuna bir girdi olur; tüm oturum olmaz.
Standartlara uygun SAML 2.0 SP artı federasyonu ölçekte güvenli ve yönetilebilir kılan operasyonel özellikler.
Kullanıcı uygulamaya gelir, AAM yapılandırılmış IdP'ye imzalı bir SAML AuthnRequest ile yönlendirir, kullanıcı IdP'de giriş yapar ve IdP imzalı iddiayı AAM'in Assertion Consumer Service uç noktasına döndürür. Giden istek için HTTP-Redirect ve gelen iddia için HTTP-POST binding'lerinin ikisi de desteklenir.
Kullanıcının başlangıç noktasının IdP olduğu konuşlandırmalar için — IdP'deki bir portal fırlatma rampası, uygulama kataloğu, kamu kimlik portalı — IdP-başlatmalı SSO kabul edilir. RelayState hedeflenen uygulama varış noktasını taşır; böylece kullanıcı iddia tüketildikten sonra doğru sayfada açılır.
İddianın imzası yapılandırılmış IdP imzalama sertifikasına karşı doğrulanır; audience yapılandırılmış AAM SP tanımlayıcısıyla eşleşir; NotBefore ve NotOnOrAfter geçerlilik penceresini belirler; AudienceRestriction uygulanır. Bilinen SAML saldırıları (signature wrapping, signature stripping, NotBefore drift) sessizce tolere edilmek yerine açıkça alt edilir.
IdP iddiayı şifrelediğinde (xmlenc), AAM iddiayı yapılandırılmış SP özel anahtarıyla doğrulama öncesinde çözer. Şifrelenmiş iddialar Kamu Kimlik Federasyonu için ve iddia içeriğinin binding katmanında okunabilir olmasını istemeyen IdP'ler için yaygındır. Şifreleme anahtarları yapılandırma deposunda şifreli saklanır ve asla loglanmaz.
Her IdP, tercih edilen bir NameID formatı (persistent, transient, email-address, unspecified) ve SAML öznitelik adlarından AAM oturum alanlarına bir eşleme ile yapılandırılabilir. Farklı IdP'ler kimliği farklı sunabilir — bir T.C. kimlik talebi, bir e-posta, benzersiz opak bir tanımlayıcı — ve yine de aynı kanonik AAM oturum biçimini üretebilir.
Birçok tenant'ı önünde tutan tek bir AAM ağ geçidi her tenant'ı kendi IdP'sine yönlendirebilir. Seçim, istek anında uygulama veya tenant bağlamından yapılır — IdP başına ayrı ağ geçidi yok, kullanıcı başına seçici yok. Aynı ağ geçidi bir tenant için Kamu Kimlik Federasyonu'nu, başka bir tenant için özel kurumsal IdP'yi aynı anda taşıyabilir.
IdP bir çıkış başlattığında, AAM SAML LogoutRequest'ini kabul eder, AAM oturumunu sonlandırır ve Backend SSO enjeksiyonu alan arka uçlara sinyal verir. Uygulama çıkışı başlattığında, AAM IdP'ye doğru imzalı bir LogoutRequest gönderir ve oturumun gittiğini ilan etmeden önce LogoutResponse'u bekler. Ön kanal SLO desteklenir.
Arka kanal SOAP tabanlı Single Logout, tarayıcı olmayan istemciler için SAML ECP (Enhanced Client/Proxy) profili ve yüksek güvenlikli entegrasyonlar için holder-of-key subject confirmation yol haritasındadır. Yapılandırma nesnesi ve SP boru hattının geri kalanı bunları zaten karşılar; eksik olan protokol-spesifik koddur.
Bir SAML federasyonunu güvenli, güncel ve gözlemlenebilir tutan mekanikler.
IdP metadata'sı, IdP'nin sağladığı metadata XML'i yüklenerek, AAM'in çekip önbelleğe aldığı bir metadata URL'si yapılandırılarak veya uç noktalar ile sertifikalar manuel girilerek yüklenebilir. Manuel yapılandırma, standartlara uygun metadata yayınlamayan IdP'ler için gerçekçi seçenektir; çalıştığı yerlerde diğer iki yöntem tercih edilir.
AAM kendi SP metadata belgesini kararlı bir URL'de yayınlar; böylece IdP operatörü uç noktaları ve sertifikaları elle aktarmak yerine bunu IdP'nin güven deposuna alabilir. Metadata canlı SP yapılandırmasını yansıtır — mevcut ACS URL'si, mevcut imzalama sertifikası, mevcut SLO uç noktası.
SP imzalama anahtarları ve sertifikaları ömür sınırlıdır. AAM örtüşme ile anahtar rotasyonunu destekler — rollover penceresi boyunca hem eski hem yeni anahtar IdP'nin önbelleğe alınmış metadata'sına karşı doğrulanır. Operatörler rotasyonu önceden planlar; runtime örtüşme süresince ikisini de kabul eder ve rotasyon temiz şekilde devreye girer.
İddialar NotBefore ve NotOnOrAfter zaman damgaları taşır. Gerçek saatler kayar; AAM yapılandırılabilir bir tolerans penceresi uygular; böylece küçük sapma geçerli iddiaları reddetmez, büyük sapmalar (yanlış yapılandırma veya replay göstergesi) ise yine reddedilir. Tolerans IdP başınadır; iyi senkronize bir IdP dar bir pencere, sorunlu bir IdP belgelenmiş bir izin alır.
Her SAML olayı — giden AuthnRequest, gelen iddia, imza doğrulama sonucu, SLO LogoutRequest, LogoutResponse — AAM oturumuna, ardındaki arka uç(lar)a ve kullanıcı kimliğine geri bağlanan bir korelasyon ID'siyle kaydedilir. "Kim hangi IdP üzerinden ne zaman oturum açtı" sorusu tek bir sorguyla yanıtlanır.
Yapılandırılmış URL'den IdP metadata'sının periyodik otomatik yenilenmesi, fark tespiti ve imzalama sertifikası değişikliklerinde operatöre uyarı yol haritasındadır. Rotasyon telemetrisi — anahtar yaşı metrikleri, son kullanım tarihine kalan gün uyarısı, otomatik rollover zamanlaması — da planlanmıştır.
Bir ulusal kimlik federasyonu IdP'sini kabul etmesi gereken uygulamalar — kamu konuşlandırmaları, düzenlemeye tabi sektörler ve kamu alıcılarına sözleşmeli SaaS hizmetleri için tipik. AAM SAML federasyonunu kenarda sonlandırır ve arkasındaki uygulamaya temiz, doğrulanmış bir kimlik sunar.
İş gücü için zaten yetkili olan mevcut kurumsal IdP'ler. AAM, IdP ekibinden bir şey değiştirmesini istemeden bir SAML SP olarak takılır. Yeni uygulamalar her kod tabanına yeni bir SAML kütüphanesi ekleyerek değil; AAM'e bir kayıt ekleyerek federasyona katılır.
Her müşterinin kendi IdP'sini getirdiği SaaS uygulamaları. Tek bir AAM ağ geçidi tüm tenant'ları önde tutar; her tenant'ın trafiği o tenant'ın IdP'sine yönlenir. Tenant eklemek, bir dağıtım değil; yapılandırma deposuna bir IdP kaydı eklemek demektir.
Bazı IdP'ler kimlik doğrular ama step-up MFA ya da koşullu erişim uygulamaz — özellikle eski federasyon ağ geçitleri. AAM IdP'nin kimlik doğrulamasını kabul eder, sonra uygulamaya erişim vermeden önce kendi MFA'sını, koşullu erişim ifadelerini ve sürekli güven değerlendirmesini bunun üzerine biner.
AAM'i IdP'nize bağlayalım — kurumsal veya Kamu Kimlik Federasyonu — ve erişim motorunun geri kalanını MFA, koşullu erişim, cihaz güveni ve Backend SSO ile iddianın üzerine bindirelim.