SAML 2.0 özellikle kurumsal uygulamalarda kullanıcının her sisteme ayrı parola girmeden merkezi Identity Provider üzerinden oturum açmasını mümkün hâle getirir. Ancak yanlış yapılandırılmış bir SAML entegrasyonu; sahte assertion kabulü, replay saldırıları, XML Signature doğrulama problemleri, yanlış audience kontrolü ve güvensiz sertifika yönetimi gibi ciddi güvenlik sorunlarına neden olabilir.
Bu nedenle güvenli SAML kullanımı yalnızca Identity Provider ile Service Provider arasında bağlantı kurmaktan ibaret değildir. SAML Response içindeki dijital imzanın doğrulanması, assertion’ın gerçekten beklenen kullanıcı ve uygulama için üretildiğinin kontrol edilmesi, süre sınırlarının uygulanması ve aynı assertion’ın tekrar kullanılmasının engellenmesi gerekir.
Bu rehberde SAML 2.0 güvenliği nedir sorusunu SSO sistemlerinde uygulanabilecek 12 kritik güvenlik önlemi üzerinden detaylı biçimde ele alacağız.
SAML 2.0 Güvenliği Nedir? Hızlı Bakış
| Kontrol | Temel Amaç |
|---|---|
| XML Signature | SAML Response veya Assertion’ın güvenilir Identity Provider tarafından üretildiğini doğrular. |
| Issuer | SAML mesajının beklenen IdP tarafından gönderildiğini kontrol eder. |
| Audience | Assertion’ın doğru Service Provider için üretildiğini doğrular. |
| Destination | SAML Response’un doğru ACS endpoint’ine gönderildiğini kontrol eder. |
| InResponseTo | Gelen Response ile istemcinin başlattığı authentication isteğini eşleştirir. |
| NotBefore / NotOnOrAfter | Assertion’ın yalnızca geçerli zaman aralığında kullanılmasını sağlar. |
| Replay Detection | Aynı Assertion veya Response’un tekrar kullanılmasını engeller. |
| X.509 Certificate | IdP ile SP arasındaki imza güven ilişkisinin temelini oluşturur. |
SAML 2.0 Güvenliği Nedir ve Nasıl Çalışır?
SAML 2.0 güvenliği nedir konusunu anlayabilmek için SAML SSO akışındaki temel tarafları bilmek gerekir.
Tipik bir SAML mimarisinde üç temel bileşen bulunur:
- Kullanıcı: Kurumsal uygulamaya erişmek isteyen kişi.
- Identity Provider (IdP): Kullanıcının kimliğini doğrulayan sistem.
- Service Provider (SP): Kullanıcının erişmek istediği uygulama veya servis.
Kullanıcı Service Provider’a erişmek istediğinde uygulama kullanıcıyı Identity Provider’a yönlendirebilir. Kullanıcı burada kimlik doğrulamasını tamamlar.
Identity Provider başarılı doğrulama sonrasında SAML Response oluşturur. Bu Response içerisinde kullanıcıya ilişkin bir veya daha fazla SAML Assertion bulunabilir.
Service Provider bu mesajı kabul etmeden önce imza, issuer, audience, süre ve diğer güvenlik kontrollerini doğrulamalıdır.
Ancak bu kontrollerden herhangi biri eksik bırakılırsa saldırgan geçersiz veya başka sisteme ait bir SAML Assertion’ı kullanarak yetkisiz oturum oluşturmayı deneyebilir.
SAML 2.0 Güvenliği Nedir? SSO İçin 12 Kritik Güvenlik Önlemi
1. SAML Response ve Assertion İmzasını Doğrulayın
SAML güvenliğinin en kritik bileşenlerinden biri XML Digital Signature doğrulamasıdır.
Service Provider, Identity Provider’dan aldığı SAML Response veya Assertion içerisindeki dijital imzanın güvenilir sertifika kullanılarak oluşturulduğunu doğrulamalıdır.
Yalnızca XML içerisindeki kullanıcı adı, e-posta veya rol değerlerini okumak güvenli değildir.
İmza doğrulaması yapılmadan kabul edilen SAML mesajında saldırgan:
- kullanıcı kimliğini değiştirebilir,
- yönetici rolü ekleyebilir,
- başka kullanıcı gibi davranabilir,
- yetkilendirme bilgilerini değiştirebilir.
Bu nedenle SAML 2.0 güvenliği nedir yaklaşımının ilk şartı güvenilir XML Signature doğrulamasıdır.
2. Yalnızca Güvenilir Signing Certificate Kullanın
SAML SSO entegrasyonlarında Identity Provider’ın X.509 sertifikası Service Provider tarafından güvenilir olarak tanımlanır.
Service Provider yalnızca önceden yapılandırılmış veya güvenilir metadata üzerinden alınmış IdP sertifikalarını kabul etmelidir.
SAML mesajı içerisinde saldırgan tarafından sağlanan rastgele sertifikaya güvenilmemelidir.
OWASP SAML güvenlik rehberi, IdP ve SP arasındaki güven ilişkisinin nasıl kurulduğunun güvenlik açısından kritik olduğunu vurgular.
Sertifika değişimleri ve rotasyonları kontrollü biçimde yapılmalı, eski veya geçersiz sertifikalar süresiz biçimde kabul edilmemelidir.
3. XML Signature Wrapping Saldırılarına Karşı Korunun
SAML XML tabanlı olduğu için güvenlik doğrulamasında XML Signature Wrapping gibi saldırılar özel önem taşır.
Bu tür saldırılarda saldırgan geçerli şekilde imzalanmış XML elementini dokümanın başka bölümüne taşıyabilir ve uygulamanın farklı, saldırgan tarafından değiştirilmiş elementi işlemesini sağlamaya çalışabilir.
Bu nedenle uygulama yalnızca “dokümanda geçerli bir imza var mı?” diye kontrol etmemelidir.
İmzanın gerçekten uygulamanın işlem yaptığı Assertion veya Response elementini kapsadığı doğrulanmalıdır.
SAML 2.0 güvenliği nedir uygulamasında güvenilir ve güncel SAML/XML Signature kütüphaneleri kullanmak bu nedenle kritik öneme sahiptir.
4. XML Schema Validation Uygulayın
SAML mesajları XML formatında olduğundan gelen veri beklenen SAML schema yapısına uygun olmalıdır.
Service Provider güvenlik açısından mesajı yalnızca parse etmekle yetinmemeli, beklenen XML yapısına uygun olduğunu doğrulamalıdır.
Schema validation:
- beklenmeyen elementlerin,
- hatalı XML yapısının,
- bazı signature wrapping tekniklerinin,
- protokol dışı mesajların
daha erken aşamada reddedilmesine yardımcı olur.
Schema doğrulamasının güvenlik kontrolü olarak kullanılabilmesi için doğru ve güvenilir SAML schema dosyaları kullanılmalıdır.
5. Issuer Değerini Doğrulayın
SAML Assertion veya Response içindeki Issuer alanı mesajın hangi Identity Provider tarafından üretildiğini gösterir.
Service Provider yalnızca önceden güvenilen Identity Provider issuer değerlerini kabul etmelidir.
Örneğin uygulama:
https://idp.example.com
issuer değerini bekliyorsa başka Identity Provider tarafından üretilen geçerli bir assertion otomatik olarak kabul edilmemelidir.
SAML 2.0 güvenliği nedir açısından imzanın geçerli olması tek başına yeterli değildir. Mesajın doğru güven alanından geldiği de doğrulanmalıdır.
6. AudienceRestriction Kontrolü Yapın
SAML Assertion içerisinde bulunan AudienceRestriction, assertion’ın hangi Service Provider veya sistem tarafından kullanılabileceğini sınırlamaya yardımcı olur.
Bir uygulama kendisi için oluşturulmamış assertion’ı kabul ederse saldırgan başka Service Provider için aldığı geçerli SAML assertion’ı farklı uygulamada kullanmayı deneyebilir.
Bu nedenle Service Provider, assertion içerisindeki Audience değerinin kendi Entity ID değeriyle uyumlu olduğunu doğrulamalıdır.
Örneğin:
https://app.example.com/saml/metadata
SP Entity ID ise assertion içerisindeki audience değeri bu güven ilişkisiyle eşleşmelidir.
7. Destination ve Recipient Değerlerini Kontrol Edin
SAML Response’un yalnızca doğru Assertion Consumer Service yani ACS endpoint’i tarafından kabul edilmesi gerekir.
Destination alanı SAML Response’un hedefini gösterebilir. SubjectConfirmationData içerisindeki Recipient alanı da assertion’ın hangi endpoint için oluşturulduğunun doğrulanmasında kullanılabilir.
Service Provider gelen HTTP isteğinin gerçek URL’siyle SAML mesajındaki hedef değerleri karşılaştırmalıdır.
Başka uygulama veya endpoint için hazırlanmış Response’un kabul edilmesi engellenmelidir.
Bu kontrol SAML 2.0 güvenliği nedir zincirinde token’ın yanlış Service Provider üzerinde kullanılmasını azaltır.
8. NotBefore ve NotOnOrAfter Sürelerini Doğrulayın
SAML Assertion sınırsız süre boyunca geçerli olmamalıdır.
Assertion içerisinde geçerlilik süresini belirleyen zaman koşulları bulunabilir.
NotBefore, assertion’ın hangi zamandan önce kabul edilmemesi gerektiğini belirtir.
NotOnOrAfter ise assertion’ın hangi zamandan itibaren artık kabul edilmemesi gerektiğini gösterir.
Service Provider bu değerleri mutlaka kontrol etmelidir.
Sunucular arasında küçük saat farklılıkları olabileceğinden sınırlı clock skew toleransı kullanılabilir. Ancak gereksiz geniş tolerans süresi replay saldırılarının kullanılabilir zaman penceresini artırabilir.
9. InResponseTo ile Authentication İsteğini Eşleştirin
SP-Initiated SSO modelinde Service Provider genellikle Identity Provider’a AuthnRequest gönderir.
Bu request benzersiz bir ID taşır.
Identity Provider tarafından dönen SAML Response içerisindeki:
InResponseTo
değeri, başlangıçta gönderilen AuthnRequest ID ile eşleştirilebilir.
Service Provider yalnızca gerçekten kendisinin oluşturduğu ve hâlâ beklediği authentication isteğine verilen Response’u kabul etmelidir.
Böylece saldırganın bağlam dışı veya eski SAML Response’u kullanıcı oturumuna enjekte etmesi zorlaştırılabilir.
10. SAML Assertion Replay Saldırılarını Engelleyin
SAML 2.0 güvenliği nedir denildiğinde replay detection kritik kontrollerden biridir.
Saldırgan geçerli bir SAML Assertion’ı ele geçirip token henüz geçerli olduğu sırada tekrar göndermeyi deneyebilir.
Service Provider kabul ettiği Assertion veya Response ID değerlerini kısa süreli cache içerisinde izleyebilir.
Aynı benzersiz ID ikinci kez görülürse istek reddedilebilir.
Replay koruması için:
- kısa assertion yaşam süresi,
- benzersiz ID,
- InResponseTo kontrolü,
- replay cache,
- TLS
birlikte kullanılabilir.
11. RelayState Değerini Güvenli Yönetin
SAML akışlarında RelayState, kullanıcı authentication işlemi tamamlandıktan sonra hangi uygulama sayfasına yönlendirileceği gibi bağlam bilgisini taşımak için kullanılabilir.
Ancak saldırgan tarafından kontrol edilen herhangi bir URL doğrudan RelayState olarak kabul edilirse open redirect problemi ortaya çıkabilir.
Örneğin:
RelayState=https://attacker.example
gibi dış domainlerin kontrolsüz kabul edilmesi kullanıcıyı kimlik doğrulama sonrasında saldırgan sitesine yönlendirebilir.
RelayState:
- sunucu tarafında üretilmeli,
- oturumla ilişkilendirilmeli,
- mümkün olduğunda referans değer olarak kullanılmalı,
- yönlendirme hedefleri allowlist ile sınırlandırılmalıdır.
12. IdP ve SP Güvenlik Olaylarını Merkezi Olarak İzleyin
Güvenli SAML mimarisi yalnızca protokol doğrulamasıyla tamamlanmaz.
Identity Provider ve Service Provider tarafında oluşan önemli güvenlik olayları izlenmelidir.
Örneğin:
- geçersiz SAML Signature,
- bilinmeyen issuer,
- yanlış audience,
- süresi dolmuş assertion,
- tekrarlanan assertion ID,
- InResponseTo uyuşmazlığı,
- geçersiz Destination,
- sertifika doğrulama hatası
SIEM veya merkezi log platformuna aktarılabilir.
Ancak loglarda gereksiz kişisel bilgi veya tam SAML Assertion içeriği tutulmamalıdır.
Bu yaklaşım SAML 2.0 güvenliği nedir konusunu yalnızca login ekranından çıkararak sürekli izlenen kimlik güvenliği sürecine dönüştürür.
SAML 2.0 Güvenliği Nedir? Assertion İçinde Neler Bulunabilir?
SAML Assertion, Identity Provider tarafından oluşturulan ve kullanıcı veya authentication olayı hakkında bilgiler taşıyan XML tabanlı güvenlik nesnesidir.
Bir Assertion genel olarak aşağıdaki veri türlerini taşıyabilir:
| Alan | Görevi |
|---|---|
| Issuer | Assertion’ı oluşturan Identity Provider’ı belirtir. |
| Subject | Assertion’ın hangi kullanıcı veya varlıkla ilgili olduğunu gösterir. |
| Conditions | Assertion’ın kullanım şartlarını ve zaman sınırlarını belirtir. |
| AudienceRestriction | Assertion’ın hangi Service Provider tarafından kullanılabileceğini sınırlar. |
| AuthnStatement | Kullanıcının kimlik doğrulama olayıyla ilgili bilgi taşıyabilir. |
| AttributeStatement | Kullanıcıyla ilgili e-posta, bölüm, grup veya rol gibi özellikleri taşıyabilir. |
| Signature | Assertion bütünlüğünü ve kaynağını doğrulamaya yardımcı olur. |
SAML 2.0 Güvenliği Nedir? IdP ve SP Arasındaki Fark
| Identity Provider | Service Provider |
|---|---|
| Kullanıcı kimliğini doğrular. | Uygulama veya hizmeti kullanıcıya sunar. |
| SAML Assertion oluşturabilir. | SAML Assertion doğrular. |
| Signing private key kullanabilir. | IdP public certificate ile imzayı doğrular. |
| Kullanıcı oturumunu merkezi olarak yönetebilir. | Doğrulanan assertion sonrasında lokal uygulama oturumu oluşturabilir. |
SAML Signature Wrapping Nedir?
SAML Signature Wrapping saldırısı, XML Digital Signature mekanizmasının uygulama tarafından yanlış yorumlanmasından yararlanmayı hedefleyen saldırı sınıflarından biridir.
Örneğin uygulama XML içindeki bir elementi kriptografik olarak doğrularken authentication mantığı başka elementi okuyorsa saldırgan imzasız veya değiştirilmiş kullanıcı bilgisinin işlenmesini sağlamaya çalışabilir.
Bu nedenle SAML 2.0 güvenliği nedir uygulamalarında:
- schema validation,
- güvenilir XML parser,
- güncel SAML kütüphanesi,
- doğru element ID kontrolü,
- imzalanan element ile kullanılan elementin aynı olduğunun doğrulanması
önemlidir.
SAML 2.0 Güvenliği Nedir? 12 Maddelik Kontrol Listesi
- SAML Response veya Assertion imzasını doğrulayın.
- Yalnızca güvenilir IdP X.509 sertifikasını kabul edin.
- XML Signature Wrapping koruması uygulayın.
- SAML XML schema validation yapın.
- Issuer değerini doğrulayın.
- AudienceRestriction kontrolü uygulayın.
- Destination ve Recipient değerlerini kontrol edin.
- NotBefore ve NotOnOrAfter zaman koşullarını doğrulayın.
- SP-Initiated akışta InResponseTo kontrolü yapın.
- Assertion ve Response replay detection uygulayın.
- RelayState değerini güvenli biçimde yönetin.
- SAML güvenlik hatalarını merkezi olarak izleyin.
SAML 2.0 Güvenliği Nedir? En Sık Yapılan 12 Hata
- SAML Assertion’ı yalnızca parse edip imzayı doğrulamamak
- Mesaj içerisindeki herhangi bir X.509 sertifikasına güvenmek
- Issuer kontrolünü atlamak
- AudienceRestriction doğrulaması yapmamak
- Destination kontrolünü yapmamak
- Assertion süresini kontrol etmemek
- Aynı Assertion’ın tekrar kullanılmasına izin vermek
- InResponseTo değerini doğrulamamak
- RelayState içerisinde her URL’yi kabul etmek
- Eski SAML/XML kütüphanesi kullanmak
- Signing private key’i normal dosya sisteminde korumasız bırakmak
- SAML doğrulama hatalarını izlememek
SAML 2.0 Güvenliği Nedir? X.509 Sertifika Yönetimi
SAML sistemlerinde signing certificate güven zincirinin temel parçalarından biridir.
Identity Provider SAML mesajlarını private key kullanarak imzalayabilir. Service Provider ise ilişkili public certificate üzerinden bu imzayı doğrular.
Burada önemli olan yalnızca sertifikanın mevcut olması değildir.
Aşağıdaki konular da yönetilmelidir:
- sertifika sahipliği,
- private key koruması,
- sertifika değişim süreci,
- sertifika rotasyonu,
- eski sertifikaların kaldırılması,
- IdP metadata güncellemeleri,
- beklenmeyen sertifika değişikliklerinin izlenmesi.
Signing private key ele geçirilirse saldırgan güvenilir IdP tarafından üretilmiş gibi görünen SAML mesajları oluşturmayı deneyebilir.
Bu nedenle yüksek güvenlik gerektiren Identity Provider sistemlerinde private signing key için HSM veya güçlü anahtar yönetim çözümleri değerlendirilebilir.
SAML 2.0 Güvenliği Nedir? SAML ile OpenID Connect Arasındaki Fark
| Özellik | SAML 2.0 | OpenID Connect |
|---|---|---|
| Temel format | XML | OAuth 2.0 üzerinde JSON/JWT ağırlıklı yapı |
| Yaygın kullanım | Kurumsal SSO ve enterprise uygulamalar | Modern web, mobil ve API odaklı kimlik sistemleri |
| Kimlik verisi | SAML Assertion | ID Token |
| İmza teknolojisi | XML Digital Signature | JOSE / JWT Signature |
| Tarayıcı SSO | Destekler | Destekler |
SAML ve OpenID Connect birbirinin doğrudan sürümleri değildir. İkisi farklı protokol aileleridir ve hangi teknolojinin uygun olduğu sistem mimarisine, istemci türüne ve mevcut kurumsal altyapıya göre değişebilir.
SAML 2.0 Güvenliği Nedir? Sık Sorulan Sorular
SAML 2.0 güvenliği nedir?
SAML 2.0 güvenliği nedir sorusuna; Identity Provider ile Service Provider arasında aktarılan SAML Response ve Assertion bilgilerinin imza, issuer, audience, zaman, hedef, sertifika ve replay kontrolleriyle doğrulanması şeklinde cevap verilebilir.
SAML neyin kısaltmasıdır?
Security Assertion Markup Language ifadesinin kısaltmasıdır.
SAML 2.0 ne işe yarar?
Kimlik doğrulama ve yetkilendirme bilgilerinin farklı güven alanları ve uygulamalar arasında standart biçimde aktarılmasını sağlar. Kurumsal Single Sign-On sistemlerinde yaygın olarak kullanılır.
SAML ile SSO aynı şey midir?
Hayır. SSO kullanıcı deneyimi ve kimlik mimarisi yaklaşımıdır. SAML ise SSO gerçekleştirmek için kullanılabilecek protokol teknolojilerinden biridir.
SAML Assertion nedir?
Identity Provider tarafından oluşturulan ve kullanıcı kimliği, authentication olayı veya attribute bilgileri gibi verileri taşıyabilen XML tabanlı güvenlik nesnesidir.
SAML Assertion şifreli olmak zorunda mı?
Her SAML Assertion’ın şifrelenmesi zorunlu değildir. İmza ve şifreleme farklı güvenlik amaçlarına hizmet eder. Hassasiyet ve mimari gereksinimlere göre encryption kullanılabilir.
SAML imzası neden önemlidir?
İmza, mesajın bütünlüğünün korunmasına ve beklenen güvenilir taraf tarafından üretildiğinin doğrulanmasına yardımcı olur.
SAML replay saldırısı nedir?
Daha önce geçerli olan SAML Assertion veya Response’un saldırgan tarafından yeniden kullanılması girişimidir. Benzersiz ID, kısa süre, InResponseTo ve replay cache gibi kontroller riski azaltabilir.
SAML ile OpenID Connect aynı mı?
Hayır. SAML XML tabanlı ayrı bir federasyon standardıdır. OpenID Connect ise OAuth 2.0 üzerine kurulan modern kimlik doğrulama katmanıdır.
İlgili İçerikler
OpenID Connect Güvenliği Nedir? 12 Kritik Önlem
OAuth 2.0 Güvenliği Nedir? 10 Kritik Önlem
JWT Güvenliği Nedir? 12 Kritik Önlem
DPoP Nedir? OAuth Token Güvenliği İçin 12 Güçlü Önlem
Resmî ve Güvenilir Kaynaklar
OASIS — SAML V2.0 Security and Privacy Considerations
OWASP — SAML Security Cheat Sheet
Sonuç: SAML 2.0 Güvenliği Nedir?
SAML 2.0 güvenliği nedir sorusunun cevabı yalnızca “SSO ile kullanıcı girişi yapmak” değildir. SAML tabanlı güven modeli, Identity Provider tarafından üretilen kimlik bilgisinin Service Provider tarafından eksiksiz ve doğru biçimde doğrulanmasına dayanır.
XML Signature kontrolü, güvenilir X.509 sertifikası, schema validation, issuer ve audience doğrulaması, Destination ve Recipient kontrolleri, zaman sınırları, InResponseTo doğrulaması ve replay detection güvenli SAML mimarisinin temel katmanlarıdır.
Özellikle yalnızca XML içerisinde geçerli bir imza bulunduğunu kontrol etmek yerine, uygulamanın gerçekten kullandığı Assertion’ın doğru şekilde imzalandığını doğrulamak gerekir. Güvenilir metadata ve signing key yönetimi de bu güven zincirinin ayrılmaz parçasıdır.
Bu önlemler birlikte uygulandığında SAML 2.0 güvenliği nedir yaklaşımı, basit kurumsal SSO bağlantısından çıkarak kimlik sahteciliği, assertion replay ve XML tabanlı saldırılara karşı çok katmanlı bir federasyon güvenliği modeline dönüşür.
