Kimlik ve SSO

dtedge'in sizi nasıl tanıdığı, hangi org'lara üye olduğunuzu ve her birinde ne yapabileceğinizi nasıl bildiği konusundaki zihinsel model. SSO kurmadan önce okuyun; yapılandırma sayfaları bu modeli bildiğinizi varsayar.

Setup walkthrough'ları için Global SSO yapılandır ve Org bazlı SSO yapılandır'a bakın.

Üç kimlik doğrulama yolu

Yöntem	Ne zaman	Nerede saklanır
Local password + 2FA	İlk super-admin, dev cluster'ları, break-glass	dtedge DB'de bcrypt hash
OIDC SSO	IdP'nin kimlik otoritesi olduğu kurumsal kurulumlar	dtedge IdP kimliğini (provider, subject) ile user satırına bağlar
API key	Etkileşimsiz çağıranlar (CI, script'ler, custom dashboard'lar)	dtedge DB'de sha256 hash

Üçü de aynı user kaydına çözülür — SSO paralel bir user tablosu oluşturmaz; mevcuda bağlanır. Bir SSO kullanıcısı da API key'e sahip olabilir. Local kullanıcı sonradan SSO-link olabilir.

İki SSO yüzeyi

dtedge iki ayrı SSO yapılandırması destekler, birbirini dışlamazlar:

Org bazlı SSO

Her organizasyon kendi IdP'sini getirir; o IdP yalnızca kendi üyelerini doğrular. Organizations → <org> → SSO'dan org admin ayarlar. Her org'un IdP'si bağımsızdır — Acme Auth0 kullanırken BorTech Keycloak ve Foo Co. Azure AD kullanabilir.

Org bazlı SSO slug-first login üzerinde çalışır: kullanıcı login sayfasında "Sign in with SSO" seçer ve org slug'larını yazar (acme). dtedge backend slug'ı hangi IdP'ye eşlediğini bulur, kullanıcıyı redirect eder ve dönen token'ı o org'un yapılandırılmış client'ına karşı doğrular.

Global SSO

Tüm install için tek IdP. Super-admin tarafından Admin → Settings → Global SSO'dan ayarlanır. Kullanım:

• Tek müşterinin her şeye sahip olduğu ve her org'da tek IdP isteyen tek-kiracılı kurulumlar.
• Org bazlı SSO bozulduğunda super-admin break-glass.
• IdP gruplarıyla yönetilen cross-org üyelik (bkz. global org-rol atamaları).

Global SSO kullanıcısı login sayfasında "Sign in with SSO" seçer ve slug yazmadan giriş yapar — global'in realm'i yoktur.

Hangisi tetiklenir?

Kullanıcı "Sign in with SSO" tıklar
     │
     ▼
Org slug yazdı mı?
     │
     ├── Hayır → Global SSO (yapılandırılmışsa)
     │
     └── Evet  → Bu org'un org bazlı SSO'su var mı?
                  ├── Evet → Org bazlı SSO
                  └── Hayır → Global'e düş (varsa)
                              VEYA "no SSO for this realm" hatası

Org bazlı SSO, kapsadığı slug için önceliklidir. Global SSO fallback'tir.

Kimlik bağlama

İlk kez SSO ile girdiğinizde dtedge user_identities tablosunda (provider, subject) çiftini arar:

• Match: link bulundu → user çözülür, içerdesiniz.
• (provider, subject) ile match yok, ama email mevcut bir user ile eşleşiyor: dtedge kimlik link'ini o user'a oluşturur. Mevcut local hesap rolleriniz + üyelikleriniz kalır.
• Hiçbir match yok: dtedge taze user oluşturur — ama yalnızca bu SSO config için auto-provision açıksa. Aksi takdirde "not provisioned" sayfası görürsünüz; bir admin'in sizi davet etmesi gerekir.

Match anahtarı email değil (provider, subject):

• IdP sub claim'leri email değişikliklerinde sabit kalır
• Aynı kullanıcı farklı IdP'lerde aynı email ile var olabilir (collision değil farklı linked user istiyoruz)

Grup → rol reconcile

IdP groups claim'i gönderdiğinde ve SSO config'in group→role mapping'i (org bazlı SSO) veya org-rol atamaları (global SSO) varsa, dtedge her girişte rolleri reconcile eder:

Kullanıcının IdP grupları : [engineers, finance-viewers]
Mapping satırları         : engineers       → editor
                            finance-viewers → viewer
                            sales           → viewer

Olması gereken            : editor, viewer (org X için org bazlıda;
                            org X ve finance için global'de)
Casbin'deki mevcut        : editor, sales-viewer (eskimiş!)

Diff:
  ekle    : viewer
  revoke  : sales-viewer (mapping artık `sales`'te değil diyor)
  koru    : editor (hâlâ `engineers`'da, hâlâ eşleşiyor)

İki önemli garanti:

1. Yalnızca mapping universe'ündeki roller dokunulur. Mapping dışında manuel olarak "admin" verdiyseniz kalır. Reconcile yalnızca mapping universe'ünde olan ama should-have'de olmayan rolleri kaldırır.

2. Absent groups claim "sinyal yok" sayılır. IdP groups claim'ini sessizce göndermeyi keserse (bozuk Action, yanlış yapılandırılmış scope) reconcile tamamen atlanır. Bu güvenlik ağı olmadan her kullanıcı operator fark edene kadar her login'de her mapping-driven rolünü kaybederdi. Backend'in verify adımındaki HasGroupsClaim bayrağı bunu uygular.

Super-admin izolasyonu

Super-admin flag'i SSO grup mapping tarafından asla dokunulmaz. Admin → Users → Toggle super-admin'den manuel ayarlanır. Her IdP grubundan düşen super-admin platform-wide flag'i korur.

Bu kasıtlı: sistemdeki en yüksek-yetkili flag sistemin dışından atanamamalı. IdP yanlış yapılandırması yanlışlıkla super-admin veremez; IdP compromise escalate edemez.

Require SSO

Her iki SSO yüzeyi de Require SSO toggle taşır:

• Org bazlı Require SSO: bu org'un üyeleri local password kullanamaz. Yalnızca bu org'a aitlerse /login'e email+password ile gittiklerinde SSO_REQUIRED döner.
• Global Require SSO: install genelinde. Her super-admin olmayan kullanıcı SSO ile giriş yapmak zorunda. Super-admin'ler local'i break-glass olarak korur — onları SSO'ya zorlamak IdP outage'ının tüm platform admin yolunu da düşürmesi anlamına gelirdi.

Login gate şuna bakar:

Kullanıcı super-admin mi?            → local her zaman çalışır
Global require_sso = true mu?        → local reddedilir
Tüm üyelikleri SSO gerektiriyor mu?  → local reddedilir
Aksi takdirde                        → local çalışır

Session ömrü

Login olduğunuzda (local veya SSO) iat (issued at) içeren bir JWT alırsınız. JWT şu ikisinden birine kadar yaşar:

• exp (default 24s, configurable) gelir
• Bir session invalidation event users.sessions_invalidated_at'i token'ınızın iat'inden daha geç bir zamana damgalar

Session-invalidation event'leri:

Event	Tetikleyici
Şifrenizi değiştirirsiniz	/auth/password
Admin şifrenizi sıfırlar	Admin → Users → Set password
Admin hesabınızı pasifleştirir	Admin → Users → Toggle active off
Super-admin'e/dan toggle	Admin → Users → Toggle super-admin
Admin 2FA'nızı sıfırlar	Admin → Users → Reset 2FA
Kendi 2FA'nızı kapatırsınız	Settings → 2FA → Disable
Logout	/auth/logout
IdP back-channel logout	IdP → POST /auth/sso/backchannel-logout

Herhangi birinden sonra sonraki request'inizde token'larınız reddedilir.

Bkz.

• Global SSO yapılandır
• Org bazlı SSO yapılandır
• Global org-rol atamaları
• Üye ve rol yönetimi
• DT Edge Platform nedir
• Tenancy