Tek oturum açma

Tek oturum açma, harici bir kimlik sağlayıcısının (IdP) Control Center sunucunuzda kimin oturum açabileceğine karar vermesini sağlar. İki protokol desteklenir — SAML 2.0 ve OpenID Connect — ve ikisi de aynı yere varır: sonraki tüm aşamalarda bir davetten veya QR eşleştirmesinden ayırt edilemeyen, yeni üretilmiş bir cihaz kimlik bilgisi.

Bir oturum açmanın biçimi

SAML oturum açmaları tarayıcı aracılığıyla gerçekleşir. IdP sunucunuza asla bir bağlantı açmaz; her şeyi kullanıcının tarayıcısı taşır:

browser ──> /saml/login ──> IdP ──POST SAMLResponse──> /saml/acs
                                                          │  verify
                                                          ▼
                                              provision user (maybe)
                                                          │
                                                          ▼
                                  browser handoff: device PSK in the URL
                                  fragment (never a query parameter)

Tarayıcı kurye olduğu için, oturum açmalarda NAT arkasındaki bir sunucu sorunsuz çalışır: localhost, LAN, Tailscale, VPN veya bir tünel — hepsi iş görür; yalnızca kullanıcının tarayıcısı ACS URL’ye ulaşabilmelidir. Telefon uzaktan kontrolünün kullandığı WebSocket relay’i HTTP gidiş-dönüşünü taşıyamaz; SSO giriş noktalarının her zaman sunucunun HTTP origin’ini hedeflemesinin nedeni budur.

OpenID Connect, authorization-code + PKCE gidiş-dönüşüyle aynı biçimi izler; claim’ler, issuer’ın token uç noktasından TLS üzerinden okunur; böylece tarayıcı, kimlik verisini hiçbir şekilde sağlamaz.

Adaptörler

Control Center sorumluluğu bilinçli olarak böler:

Bileşen	Konum	Üstlendiği
cc_saml native	packages/cc_natives/native/saml/	XML-DSig doğrulaması, kanonikleştirme, SAML profil doğrulaması — durumsuz bir C ABI arkasında sabitlenmiş saf Rust saml crate’ine devredilir
SamlService / OidcService	cc_server_core	oturum açma durumu (bekleyen istek takipçileri, yeniden oynatma tekilleştirmesi), doğrulama politikası ayarları, paylaşılan sağlama çağrısı
SsoProvisioner	cc_server_core	kullanıcıyı bul ya da oluştur, sağlayıcı subject’ini sabitle, otomatik üye politikası kapsamında üyelikleri ver
ScimService	cc_server_core	SCIM 2.0 push yüzeyi (sağlama/sağlamadan çıkarma yaşam döngüsü)
SsoSettingsService	cc_server_core	kaydedilmiş bağlantı satırları, canlı yeniden uygulama, SCIM token’ı

Kasıtlı olarak saf Dart bir SAML kripto yedeği yoktur: elle yazılmış XML-DSig/kanonikleştirme, imza sarma güvenlik açıklarının tam olarak yaşadığı yerdir; bu yüzden cc_saml kütüphanesi eksik olduğunda hem SAML oturum açma hem de sunucu önyüklemesi reddedilir. Native, tasarım gereği durumsuzdur — istekler arası durum, tek kullanımlık ve kısa ömürlü olarak Dart servislerinde yaşar.

Bir oturum açma neyi doğrular

Doğrulanan native’in ve servisin içinde, sırasıyla:

1. assertion’ın imzası (her zaman gereklidir; yanıt zarfınınki yapılandırmaya göre isteğe bağlıdır) — doğrulanan yük, doğrulanan öğeye bağlandığı için yapısal olarak imza sarmaya dirençlidir,
2. issuer, yapılandırılmış IdP ile eşleşir,
3. audience bu hizmet sağlayıcıyı adlandırır,
4. destination bizim ACS URL’imizdir,
5. InResponseTo, yayımladığımız bekleyen bir AuthnRequest ile eşleşir (istem dışı, IdP tarafından başlatılan yanıtlar varsayılan olarak kapalıdır),
6. geçerlilik pencereleri saat kayması (varsayılan 90 sn) içinde kalır ve
7. assertion id daha önce hiç görülmemiştir (yeniden oynatma önbelleği).

Hatalar tipli kodlar olarak döner — signature, expired, audience, destination, issuer, request-match — ve uç noktalar genel hatalarla yanıt verir; böylece bir saldırgan, sahteciliğin neden başarısız olduğuna dair hiçbir şey öğrenemez.

Hesaplar ve subject sabitleme

İlk SSO oturum açması, sağlayıcının değişmez subject’ini (issuer artı SAML NameID / OIDC sub ya da SCIM externalId) hesaba sabitler. O andan itibaren oturum açmayı tanımlayan şey e-posta değil, subject’tir. Başka biri daha sonra aynı ya da farklı bir IdP’den aynı e-postayı sunarsa, sabitlenmiş hesap onu reddeder. Bir sağlayıcıda geri dönüştürülen bir e-postanın hesap devralmaya dönüşmesini engelleyen şey budur.

Sağlama ve sağlamadan çıkarma

JIT sağlama, oturum açma sırasında gerçekleşir (SsoProvisioner). SCIM, kullanıcı satırında aynı subject’i sabitleyen ayrı bir push yüzeyidir (ScimService); çalışma alanı üyelikleri vermez. Sağlamadan çıkarma — SCIM active: false veya DELETE — hesap bir çalışma alanı sahibiyse reddeder (önce devredin). Aksi hâlde önce her cihaz kimlik bilgisini iptal eder (oturumlar, cihaz izleme sayesinde saniyeler içinde düşer), her çalışma alanı üyeliğini kaldırır ve hesabı devre dışı olarak damgalar. Kullanıcı satırı ayakta kalır: atıf kalıcıdır. Yeniden etkinleştirme oturum açmayı geri getirir ama üyelikleri asla yeniden vermez.

Neler dışarıda kalır

• Grup→rol eşlemesi oturum açma sırasında SAML özniteliklerinden / OIDC claim’lerinden yapılır — push edilen SCIM grupları saklanmaz.
• Sahip rolüne SSO’dan ulaşılamaz — ne varsayılan rol olarak ne de bir grup eşlemesi yoluyla.
• WebSocket relay’i asla bir SSO kanalı değildir; sunucuya yalnızca relay üzerinden ulaşan telefonlar, sunucuya karşı bir tarayıcı gidiş-dönüşünü tamamlayamaz.