SAML SSO Akış Diyagramı: SP Başlatmalı ve IdP Başlatmalı Giriş

Sözleşme imzalayan ilk büyük müşteri, kendi kimlik sağlayıcısıyla tek oturum açma (SSO) isteyecektir ve bu çoğu zaman SAML 2.0 demektir. Standart 2005'ten kalmadır, XML'i tarayıcı yönlendirmeleri ve form gönderimleriyle taşır ve hata mesajları belirsizden sessize kadar uzanır. Ciddi güvenlik açıkları dahil SAML hatalarının çoğu, hangi mesajın tam olarak nereye gittiğini ve hizmet sağlayıcının neleri kontrol etmesi gerektiğini bilmemekten kaynaklanır.

Bu yazı SP başlatmalı akışı bir sekans diyagramıyla mesaj mesaj ele alıyor; ardından IdP başlatmalı varyantı ve risklerini, bir SAML yanıtının anatomisini, uygulamanız için doğrulama kontrol listesini, metadata ve sertifika yenilemeyi ve SAML'in OpenID Connect ile karşılaştırmasını anlatıyor.

Üç taraf

Yaygın Web Browser SSO profilinde SP ve IdP birbiriyle hiçbir zaman doğrudan konuşmaz. Her mesaj tarayıcı üzerinden, bir yönlendirme ya da otomatik gönderilen bir form olarak gider. Paylaştıkları şey, metadata olarak bir kez değiş tokuş edilen yapılandırmadır: her iki tarafın entity ID'si, IdP'nin giriş URL'si, SP'nin Assertion Consumer Service (ACS) URL'si ve IdP'nin imzalama sertifikası.

Adım adım SP başlatmalı akış

Kullanıcı işe uygulamanızda başlar:

1. Kullanıcı oturumu olmadan https://app.example.com/dashboard adresini açar.
2. Uygulamanız benzersiz bir ID, kendi entity ID'si ve ACS URL'siyle bir AuthnRequest oluşturur, ID'yi bekleyen giriş durumunda saklar ve tarayıcıyı IdP'ye yönlendirir. HTTP-Redirect binding ile istek, query string'de SAMLRequest olarak (deflate edilmiş, base64 kodlanmış) gider; yanında kullanıcının nereye gitmek istediğini hatırlayan bir RelayState değeri bulunur.
3. IdP kullanıcının kimliğini doğrular: parola ve MFA ya da var olan bir IdP oturumu; ikinci durumda kullanıcı hiçbir şey görmez.
4. IdP, imzalı bir SAMLResponse'u ve aynı RelayState'i ACS URL'nize POST eden bir form içeren bir HTML sayfası döndürür. Bu HTTP-POST binding'dir ve küçük bir betik formu otomatik olarak gönderir.
5. Uygulamanız yanıtı doğrular, kendi oturum çerezini oluşturur ve kullanıcıyı RelayState içinde saklanan sayfaya yönlendirir.

Bundan sonra kullanıcının kim olduğuna uygulamanızın kendi oturumu karar verir. SAML ancak bu oturum sona erdiğinde yeniden devreye girer.

Binding spesifikasyonu RelayState'i 80 baytla sınırlar; bu yüzden gerçek dönüş URL'sini sunucu tarafında saklayın ve kısa bir anahtar gönderin.

Bir SAML yanıtı neler içerir

Uygulamanızın okuduğu kısımlara indirildiğinde bir yanıt şöyle görünür:

<samlp:Response ID="_r81c" InResponseTo="_req42" Destination="https://app.example.com/saml/acs">
  <saml:Assertion ID="_a77e">
    <saml:Issuer>https://idp.customer.com/entity</saml:Issuer>
    <ds:Signature>…</ds:Signature>
    <saml:Subject>
      <saml:NameID>ana@customer.com</saml:NameID>
      <saml:SubjectConfirmationData InResponseTo="_req42"
        Recipient="https://app.example.com/saml/acs" NotOnOrAfter="2026-11-02T09:05:00Z"/>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-11-02T08:59:30Z" NotOnOrAfter="2026-11-02T09:05:00Z">
      <saml:AudienceRestriction><saml:Audience>https://app.example.com</saml:Audience></saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AttributeStatement>…email, name, groups…</saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Assertion imzalı beyandır: kullanıcının kim olduğu (NameID), bunu kimin söylediği (Issuer), kimin için (Audience), ne kadar süreyle ve hangi isteğe cevap olarak (InResponseTo).

Doğrulama kontrol listesi

SAML güvenliğinin başarılı olduğu ya da başarısız olduğu yer ACS uç noktanızdır. Bu uç nokta şunları yapmalıdır:

1. İmzayı IdP'nin metadata'sındaki sertifikayla doğrulayın, asla mesajın içine gömülü bir sertifikayla değil.
2. Yalnızca imzanın kapsadığı şeyi okuyun. XML imza sarmalama (signature wrapping) saldırıları ikinci, imzasız bir assertion ekler ve kodun bir öğeyi doğrulayıp başka bir öğeyi okumasını umar. Araştırmacılar 2012'de 14 büyük SAML çatısının 11'inde bu açığı buldu ve açık geri dönmeye devam ediyor: ruby-saml 2024'te CVSS 10.0 puanlı bir imza atlatmayı (CVE-2024-45409), 2025'te de iki ayrıştırıcı farkı (parser differential) kaynaklı atlatmayı (CVE-2025-25291 ve CVE-2025-25292) düzeltti.
3. Issuer değerini bu müşterinin IdP entity ID'siyle karşılaştırın.
4. Audience değerini kendi entity ID'nizle karşılaştırın.
5. Destination ve Recipient değerlerini ACS URL'nizle karşılaştırın.
6. NotBefore ve NotOnOrAfter değerlerini saat kayması için bir iki dakikalık toleransla kontrol edin.
7. InResponseTo değerini, bu tarayıcı için verdiğiniz ve henüz kullanılmamış bir AuthnRequest ID'siyle eşleştirin.
8. Assertion ID'lerini süreleri dolana kadar hatırlayarak tekrar oynatmaları reddedin.
9. RelayState değerine güvenmeyin. Yalnızca göreli yollara ya da bir izin listesine yönlendirin; yoksa elinizde bir açık yönlendirme (open redirect) olur.

On yıllık SAML açıklarından çıkan ders: Bakımı yapılan bir kütüphane kullanın, sürümünü sabitleyin, yamalarını hızla uygulayın ve XML imza doğrulamasını asla kendiniz yazmayın.

IdP başlatmalı SSO ve neden daha riskli olduğu

IdP başlatmalı akışta kullanıcı işe IdP'de başlar; genellikle Okta ya da Microsoft My Apps portalı gibi bir panoda uygulamanızın kutucuğuna tıklayarak. IdP, ACS URL'nize istenmemiş bir yanıt POST eder. Hiç AuthnRequest olmadığı için eşleştirilecek bir InResponseTo da yoktur.

InResponseTo olmadan, geçerli bir yanıt ele geçiren ya da kurbanın tarayıcısına bir yanıt POST ettiren bir saldırgan, kurbanı saldırganın hesabına sokabilir ya da çalınmış bir yanıtı geçerlilik süresi içinde tekrar oynatabilir. Müşterilerin pano kutucuklarına ihtiyacı varsa, daha güvenli desen uygulamanızın giriş URL'sini açan ve ardından normal bir SP başlatmalı akış başlatan bir kutucuktur. İstenmemiş yanıtları kabul etmek zorundaysanız geçerlilik süresini kısa tutun, assertion ID'lerini tek kullanımlık yapın ve buna genel olarak değil, müşteri bazında izin verin.

Metadata, sertifikalar ve çok kiracılı kurulumlar

Her müşterinin IdP'si ayrı bir güven ilişkisidir. Kiracı başına şunları saklayın: IdP entity ID'si, giriş URL'si, imzalama sertifikaları ve öznitelik eşlemesi. Çok kiracılı SaaS mimari diyagramı bu kiracı bazlı yapılandırmanın genellikle nerede durduğunu gösteriyor.

İmzalama sertifikalarının süresi dolar ve süresi dolmuş ya da yenilenmiş bir sertifika, bir müşterinin tamamının birden giriş yapamamasının en yaygın nedenidir. Geçiş sırasında IdP başına iki sertifika kabul edin, IdP bir metadata URL'si yayımlıyorsa onu düzenli aralıklarla okuyun ve süre dolmadan haftalar önce alarm verin.

SAML kimlik doğrular; kullanıcı listenizi senkronize tutmaz. İlk girişte hesap oluşturmak kolaydır, ancak biri ayrıldığında erişimi kaldırmak sağlama (provisioning) gerektirir; genellikle SCIM 2.0 (RFC 7644). O olmadan, devre dışı bırakılan bir çalışan uygulamanızın zaten verdiği oturumu korur.

SAML mı, OpenID Connect mi?

Yeni uygulamalar OpenID Connect ile başlayabilir, ama kurumsal alıcılar SAML istemeye devam edecek; bu yüzden çoğu B2B ürün ikisini de destekler. OAuth 2.0 akış diyagramı OpenID Connect'in üzerine kurulduğu protokolü ele alıyor.

SAML SSO diyagramı

Nasıl okunur:

• Dört katılımcı. Kullanıcı, tarayıcı, hizmet sağlayıcı olarak uygulamanız ve kimlik sağlayıcı. Zaman aşağı doğru akar.
• Yönlendirme, AuthnRequest ve RelayState değerlerini uygulamanızdan IdP'ye, tarayıcı üzerinden taşır.
• İsteğe bağlı parça giriş adımıdır. Var olan bir IdP oturumu varsa atlanır ve kullanıcı yalnızca hızlı bir yönlendirme görür.
• Form gönderimi imzalı SAMLResponse'u ACS URL'sine ulaştırır. Uygulamanız onu doğrular ve kendi oturum çerezini ayarlar.
• Markdown bloğu ACS uç noktasının yapması gereken kontrolleri listeler.

Hata ayıklamaya yardım eden SSO akışları çizmek

• Tarayıcıyı ayrı bir katılımcı olarak çizin. SAML bir ön kanal protokolüdür; tarayıcıyı gizlemek, mesajların nerede yakalanabileceğini ya da tekrar oynatılabileceğini gizler.
• Her okun üzerine binding'i yazın: yönlendirme mi POST mu ve parametre adı. Yapılandırma hatalarının çoğu yanlış bir URL ya da binding'dir.
• Mesajlara ID'leri yazın. InResponseTo değerinin istek ID'sini yansıttığını göstermek, neden kontrol edildiğini açıklar.
• IdP başlatmalı akışı ana diyagramın bir dalı olarak değil, riski belirtilmiş şekilde ayrı çizin.

Sekans diyagramı örneği katılımcıları, parçaları ve etiketleri daha ayrıntılı ele alıyor; sıfır güven mimari diyagramı ise kimlik sağlayıcının daha geniş bir erişim modelinde nerede durduğunu gösteriyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Kullanıcı için Sekans paketinden bir Aktör, ardından üç Yaşam çizgisi düğümü ekleyin: Browser, Service provider ve Identity provider.
3. Mesajları yukarıdan aşağıya yaşam çizgileri arasındaki kenarlar olarak çizin: ilk istek, SAMLRequest ve RelayState ile yönlendirme, IdP'ye istek, SAMLResponse içeren form, ACS URL'sine POST ve oturum çereziyle son yönlendirme.
4. Giriş ve MFA adımının etrafına, işleci opt olan bir Sekans paketi Parça düğümü ekleyin.
5. Doğrulama kontrol listesiyle Temel paketinden bir Markdown bloğu ekleyin.

Örnek 6 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

SP başlatmalı ve IdP başlatmalı SSO arasındaki fark nedir? SP başlatmalı giriş, IdP'ye bir AuthnRequest gönderen uygulamanızda başlar. IdP başlatmalı giriş ise uygulamanıza istenmemiş bir yanıt POST eden IdP portalında başlar. İkincisinde eşleştirilecek bir istek yoktur; bu da tekrar oynatmaya ve giriş CSRF'sine karşı korumayı zayıflatır.

ACS URL'si nedir? Assertion Consumer Service URL'si, SAML yanıtını HTTP POST ile alan uygulamanızdaki uç noktadır. IdP'de yapılandırılır ve her yanıttaki Destination ve Recipient değerleriyle eşleşmelidir.

RelayState ne için kullanılır? Kullanıcının ulaşmak istediği yeri taşır; böylece uygulamanız giriş sonrasında onu oraya gönderebilir. 80 baytla sınırlıdır ve güvenilmeyen bir girdidir; bu yüzden onu sunucu tarafındaki duruma işaret eden bir anahtar olarak kullanın ya da bir izin listesine göre doğrulayın.

SAML eskidi mi? OpenID Connect'ten daha eskidir ve güvenli uygulanması daha zordur, ancak pek çok kurumsal kimlik sağlayıcının ve alıcının beklediği standart olmayı sürdürüyor. Çoğu B2B ürün ikisini de destekler.

SAML, şirketten ayrılan kullanıcıları kaldırır mı? Hayır. SAML yalnızca giriş anında kimlik doğrular. Erişimin kaldırılması SCIM ya da başka bir sağlama entegrasyonu ve uygulamanızda makul oturum süreleri gerektirir.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.