Kurumsal ortamlarda SSO genelde “tek bir giriş ekranı” diye başlar; birkaç ay sonra gerçek ihtiyaç ortaya çıkar: SAML konuşan legacy uygulamalar, OIDC bekleyen modern servisler, bir yandan da farklı IdP’ler, MFA politikaları, rol/grup eşlemesi ve audit zorunlulukları.
Bu yazıda, SSO’yu tek tek uygulamalara “entegrasyon işi” olarak değil; kritik bir platform bileşeni olarak ele alan bir yaklaşımı anlatıyorum: SAML/OIDC geçidi (SSO broker / federation gateway).
SSO’da gerçek problem: Protokol değil “politikayı taşıma” işi
SSO’nun zor kısmı çoğu zaman SAML assertion’ı veya OIDC token’ı üretmek değildir. Zor olan:
- “Kim, ne zaman, hangi koşulla erişebilir?” politikasını tek yerde taşımak
- Uygulama sayısı arttıkça rol/grup/claim eşlemelerini sürdürülebilir kılmak
- MFA, conditional access, cihaz uyumluluğu gibi kararları uygulama bazında değil merkezi yönetmek
- Audit ve incident sırasında tek bir “truth source” üzerinden iz sürebilmek
SSO broker bu nedenle “konfor” değil, operasyonel zorunluluk haline gelir.
Mimari: Federasyon geçidi ne yapar?
Geçidin iki tarafı vardır:
- Upstream (kimlik kaynağı): Entra ID, Okta, Keycloak, AD FS vb. (kuruma göre 1+ tane olabilir)
- Downstream (uygulamalar): SAML SP’ler, OIDC Relying Party’ler, reverse-proxy arkasındaki servisler
Geçit şu fonksiyonları üstlenir:
- Protocol translation: SAML ⇄ OIDC (veya ikisini de aynı anda)
- Policy enforcement: MFA, IP/cihaz koşulları, risk tabanlı kural setleri
- Claim normalization:
groups,roles,department,tenant,envgibi alanları standartlaştırma - Session & token lifecycle: süre, yenileme, revocation, logout
- Audit surface: kim giriş yaptı, hangi kararlarla erişti, hangi uygulamaya gitti
Tavsiye edilen kurulum: “İki kapı” modeli
Kurumsal ölçekte pratik bir model:
1) Public / External SSO edge
İnternete açık kullanıcı akışları (VPN/VDI yoksa) ve SaaS entegrasyonları için.
- WAF/rate-limit/CDN arkasında
- Bot ve brute force koruması
- DDoS dayanımı
2) Internal / Admin SSO control plane
Kritik yönetim arayüzleri ve admin uygulamalar için ayrı risk profili.
- Daha kısa token ömrü
- Zorunlu MFA + cihaz uyumu
- Break-glass erişimi ayrı politika
Bu ayrım, incident sırasında blast radius’ü ciddi azaltır.
Claim/rol tasarımı: “Grup adı” değil “kontrat” yönet
En çok kırılan yer burasıdır: uygulamalar gruplara gömülür, grup isimleri değişir, departmanlar birleşir ve bir sabah prod erişimi kayar.
Benim tercih ettiğim yaklaşım:
- Uygulama yetkisini
rolegibi soyut bir kontrata bağla (app:billing:admin,app:erp:read-only) - Grupları/ekipleri bu role’lara mapping ile bağla
- Role’ları versiyonla ve “kim sahip” bilgisini tut
Bu sayede org değişimi uygulamaları kırmaz; sadece mapping güncellenir.
Token/oturum ömrü: Güvenlik ve operasyon aynı anda düşünülür
SSO’da süre kararları sadece güvenlik kararı değildir; aynı zamanda operasyonel bir karardır.
Örnek pratik set:
- Normal kullanıcı: erişim token 10–15 dk, refresh token 8–12 saat (cihaz uyumuna bağlı)
- Admin/privileged: erişim token 5 dk, refresh yok veya çok kısa, step-up MFA
- Servis hesapları: kullanıcı token’ı ile değil, workload identity / mTLS / OIDC federation
Operasyonel gerçeklik: SSO broker’ı nasıl işletirsiniz?
1) Yük ve kapasite
En sık hata: SSO’yu “az trafik” sanmak. Trafik anlık patlar:
- Mesai başlangıcı (peak)
- Global incident sırasında yeniden login dalgası
- Uygulama cache invalidation (session storm)
Bu yüzden:
- Stateless tasarım + yatay ölçek
- Session store (kullanıyorsanız) için HA + latency bütçesi
- JWK / metadata cache (IdP bağımlılığını azaltmak için)
2) İzleme (minimum)
auth_success_rate,auth_failure_rate- MFA step-up oranı
token_issue_latency(p95/p99)- Upstream IdP erişilebilirliği
- SAML signature / cert hataları (trend)
3) Runbook: “İnsanlar login olamıyor” incident’i
Hızlı triage için olayları sınıflandırın:
- Upstream IdP outage mı?
- Zaman drift / sertifika süresi dolması mı?
- DNS / network yolu mu?
- Policy değişikliği sonrası block mı?
- Bir app’in yanlış metadata/redirect URI deploy’u mu?
İlk 10 dakikada amaç “root cause” değil; erişimi güvenli şekilde geri getirmek olmalı:
- Canary app ile doğrulama
- Değişiklik geri alma (policy rollback)
- Break-glass akışını kontrollü açma (audit + süreli)
Migrasyon stratejisi: Uygulama bazlı değil “dalga” bazlı
SSO migrasyonu; tek tek entegrasyon değil, işletim modeli değişimidir.
- Dalga 1: düşük risk internal app’ler (read-only)
- Dalga 2: kurumsal kritik ama düşük yetkili akışlar
- Dalga 3: admin ve yüksek riskli uygulamalar
Her dalgada “geri dönüş” planı ve smoke test seti olmalı:
- Login + logout
- Grup/rol eşlemesi
- MFA step-up
- Audit log doğrulama
Son söz
Kurumsal SSO’yu başarılı yapan şey “hangi ürün” değil; SSO’yu bir platform bileşeni olarak ele almak ve kimlik politikasını protokollerden bağımsız şekilde taşıyabilmektir. SAML/OIDC geçidi kurduğunuzda; entegrasyon maliyeti düşer, audit kalitesi artar ve en önemlisi incident anında kontrol sizde kalır.