SAML

SAML (Security Assertion Markup Language), OASIS tarafından 2005 yılında yayımlanan XML tabanlı bir tek oturum açma (SSO) standardıdır. Kurumsal B2B entegrasyonlarında yoğun biçimde kullanılır — Okta, Ping Identity, Microsoft AD FS, Google Workspace ve büyük şirketlere satan her SaaS.

Model: bir Kimlik Sağlayıcı (IdP, ör. Okta) kullanıcının kimliğini doğrular. Kullanıcı, kim olduğunu kanıtlayan imzalı bir SAML iddiasıyla bir Hizmet Sağlayıcıya (SP, ör. Salesforce) ulaşır. SP, iddiayı IdP’nin genel anahtarına göre doğrular ve talebi güvenilir kabul eder.

SAML ve OAuth2/OIDC karşılaştırması: SAML daha eski, XML tabanlı ve kurumsal SSO için tasarlanmıştır. OAuth/OIDC JSON tabanlıdır ve başlangıçta yetkili erişim (“bu uygulamanın Gmail’imi okumasına izin ver”) için tasarlanmış, daha sonra kimlik doğrulamaya (OIDC) genişletilmiştir. Yeni kurumsal entegrasyonlar giderek daha fazla OIDC kullanmaktadır; mevcut kurumsal SaaS çoğunlukla hâlâ SAML gerektirmektedir, çünkü müşterilerin IdP’leri bunu zorunlu kılmaktadır.

SAML’ın kullandığı XML imza spesifikasyonu son derece hata yapmaya açıktır — birçok uygulamada XML imza sarmalama saldırıları mevcuttur. Modern kütüphaneler (örn. python-saml, OneLogin’ın kütüphaneleri) bunu varsayılan olarak doğru şekilde ele alır; kendi uygulamanızı yazmak kötü bir fikirdir.

SAML bağlamaları — iddialar nasıl iletilir: SAML birçok taşıma bağlaması tanımlar. HTTP Redirect, isteği bir URL sorgu dizisinde sıkıştırır ve base64 ile kodlar (tarayıcı URL uzunluğuyla sınırlıdır); HTTP POST, JavaScript aracılığıyla otomatik gönderilen bir formda base64 kodlu bir blob gönderir (2026’da en yaygın olanı); HTTP Artifact ise SP’nin tam iddia için bant dışında değiştirdiği kısa bir referans token iletir. POST, URL sınırlarını rahatlıkla aşan iddia boyutlarını işlediği ve iddiayı proxy günlüklerine sızdırmaktan kaçındığı için modern varsayılandır. İddianın kendisi base64 ile sarılır ve SHA-256 ile imzalanır.

Kurumsal SAML dağıtımlarındaki operasyonel tuzaklar: IdP ile SP arasındaki saat kayması (iddialar varsayılan olarak 5 dakikalık geçerlilik penceresine sahiptir — yanlış yapılandırılmış bir sunucu saati herkese oturumu bozar), sertifika rotasyonu (IdP’nin imzalama sertifikası her 1-3 yılda bir süresini doldurur ve bu tarihten önce rotasyona girilmelidir; aksi hâlde tüm SSO aynı anda başarısız olur) ve NameID biçimi uyumsuzluğu (IdP emailAddress yayımlıyor ama SP kalıcı opak ID’ler bekliyor). Klasik kurumsal savaş hikâyesi, IdP sertifikasının Pazar gecesi sessizce sona ermesiyle Pazartesi sabahı yaşanan SSO kesintisidir ve kimse yenilemeyi sahiplenmemiştir. Kaynak: OASIS SAML 2.0 Temel spesifikasyonu.

Çalışma örneği

Bir çalışan app.example.com’da “Şirket SSO ile giriş yap” düğmesine tıklar. SP (Hizmet Sağlayıcı) bir SAML <AuthnRequest> XML belgesi oluşturur ve bunu sso.acme.com/saml adresindeki IdP’ye POST eder. IdP kullanıcının kimliğini doğrular (muhtemelen parola + WebAuthn aracılığıyla) ve şunları içeren bir <Assertion> barındıran SAML <Response> döndürür: kullanıcının e-postası (NameID), grup üyelikleri (AttributeStatement), geçerlilik penceresi (NotBefore / NotOnOrAfter yaklaşık 5 dakika) ve kitle kısıtlaması (tam olarak app.example.com olmalıdır). XML, SHA-256 kullanılarak IdP’nin RSA-2048 anahtarıyla imzalanır. Tarayıcı bu base64 kodlu blobu otomatik olarak app.example.com/saml/acs adresine POST eder. SP, imzayı IdP’nin önceden paylaşılan genel sertifikasına göre doğrular, geçerlilik penceresini ve kitleyi kontrol eder, e-postayı çıkarır ve yerel bir oturum oluşturur. Tüm alışveriş iki HTTP yönlendirmesinden oluşur ve IdP’nin giriş ekranının ötesinde kullanıcıya görünmez.

Ne zaman ve neden önemlidir

B2B SaaS satıyorsanız, SAML desteği kurumsal satış için belirleyici özelliktir — 500’den fazla çalışanı olan çoğu şirket, tüm SaaS erişiminin işten ayrılma denetimi için kendi IdP’lerinden geçmesini şart koşar (bir çalışan ayrıldığında, IdP oturumunu iptal eder ve çalışan bağlı tüm SaaS erişimini aynı anda yitirir). SaaS satıcılarındaki modern güvenlik olayları (Okta 2022, Cloudflare 2023), özellikle SSO’nun kayıt kimlik bilgisi olması nedeniyle parolalar yerine SAML veya oturum token katmanına kadar izlenir. Herhangi bir SAML uygulaması için savunma kontrol listesi: her iddiada imzayı doğrulayın (yalnızca yanıt sarmalayıcısında değil), tekrar oynatmayı önlemek için InResponseTo’yu doğrulayın, kitleyi ve alıcıyı doğrulayın, zaman penceresini sıkı biçimde uygulayın ve IdP sertifikası parmak izini bant dışında saklayın; böylece ele geçirilmiş bir metadata URL’si güvenilen anahtarı sessizce değiştiremez. Kaynak: OWASP SAML Güvenlik Hızlı Başvurusu.