Masuk tunggal

Masuk tunggal memungkinkan penyedia identitas (IdP) eksternal menentukan siapa yang boleh masuk ke server Control Center Anda. Dua protokol didukung — SAML 2.0 dan OpenID Connect — dan keduanya berakhir di tempat yang sama: kredensial perangkat yang baru dibuat yang tidak dapat dibedakan dari undangan atau pemasangan QR di seluruh bagian hilir.

Bentuk sebuah login

Login SAML dimediasi browser. IdP tidak pernah membuka koneksi ke server Anda; browser pengguna membawa semuanya:

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

Karena browser adalah kurirnya, server di balik NAT tetap berfungsi untuk login: localhost, LAN, Tailscale, VPN, atau tunnel semuanya melayani — hanya browser pengguna yang harus menjangkau ACS URL. Relay WebSocket yang dipakai oleh kontrol jarak jauh ponsel tidak dapat membawa perjalanan bolak-balik HTTP, dan itulah sebabnya titik masuk SSO selalu menargetkan origin HTTP server.

OpenID Connect mengikuti bentuk yang sama dengan perjalanan bolak-balik kode otorisasi + PKCE; klaim dibaca dari endpoint token penerbit melalui TLS, sehingga browser sama sekali tidak memasok data identitas.

Adapter

Control Center membagi tanggung jawabnya dengan sengaja:

Bagian	Lokasi	Tanggung jawab
cc_saml native	packages/cc_natives/native/saml/	Verifikasi XML-DSig, kanonikalisasi, validasi profil SAML — didelegasikan ke crate saml Rust murni yang dipatok di balik C ABI yang stateless
SamlService / OidcService	cc_server_core	status login (pelacak permintaan tertunda, deduplikasi replay), kenop kebijakan validasi, panggilan provisioning bersama
SsoProvisioner	cc_server_core	temukan-atau-buat pengguna, sematkan subjek penyedia, berikan keanggotaan di bawah kebijakan auto-member
ScimService	cc_server_core	permukaan push SCIM 2.0 (siklus hidup provision/deprovision)
SsoSettingsService	cc_server_core	baris koneksi yang tersimpan, penerapan ulang langsung, token SCIM

Secara sengaja tidak ada fallback kripto SAML Dart murni: XML-DSig/ kanonikalisasi buatan tangan justru tempat kerentanan pembungkusan tanda tangan berada, sehingga pustaka cc_saml yang hilang menolak baik login SAML maupun boot server. Native ini stateless secara desain — status lintas-permintaan berada di layanan Dart, sekali pakai dan berumur pendek.

Apa yang diverifikasi oleh login

Di dalam native yang terverifikasi dan layanannya, secara berurutan:

1. tanda tangan asertion (selalu wajib; tanda tangan amplop respons opsional sesuai konfigurasi) — secara struktural tahan terhadap pembungkusan tanda tangan karena payload yang divalidasi terikat pada elemen yang terverifikasi,
2. penerbit cocok dengan IdP yang dikonfigurasi,
3. audiens menamai penyedia layanan ini,
4. tujuan adalah ACS URL kami,
5. InResponseTo cocok dengan AuthnRequest tertunda yang kami terbitkan (respons yang tidak diminta dan diprakarsai IdP nonaktif secara default),
6. jendela masa berlaku berada dalam toleransi pergeseran jam (default 90s) dan
7. id asertion belum pernah terlihat sebelumnya (cache anti-replay).

Kegagalan dikembalikan sebagai kode bertipe — signature, expired, audience, destination, issuer, request-match — dan endpoint menjawab dengan error generik, sehingga penyerang tidak mempelajari apa pun tentang mengapa suatu pemalsuan gagal.

Akun dan penyematan subjek

Login SSO pertama menyematkan subjek penyedia yang tidak dapat diubah (issuer plus SAML NameID / OIDC sub, atau SCIM externalId) ke akun tersebut. Sejak saat itu, subjek — bukan email — yang mengidentifikasi login. Jika orang lain kemudian menyajikan email yang sama dari IdP yang sama atau IdP lain, akun yang disematkan akan menolaknya. Inilah yang menghentikan email yang didaur ulang di penyedia berubah menjadi pengambilalihan akun.

Provisioning dan deprovisioning

Provisioning JIT terjadi saat login (SsoProvisioner). SCIM adalah permukaan push terpisah (ScimService) yang menyematkan subjek yang sama pada baris pengguna; ia tidak memberikan keanggotaan ruang kerja. Deprovisioning — SCIM active: false atau DELETE — menolak jika akun tersebut adalah pemilik ruang kerja (alihkan dulu). Jika tidak, ia mencabut setiap kredensial perangkat terlebih dahulu (sesi berhenti dalam hitungan detik melalui pemantauan perangkat), menghapus setiap keanggotaan ruang kerja, dan menandai akun dinonaktifkan. Baris pengguna tetap ada: atribusi bersifat permanen. Aktivasi ulang memulihkan login tetapi tidak pernah memberikan kembali keanggotaan.

Apa yang tidak termasuk

• Pemetaan grup→peran terjadi saat login dari atribut SAML / klaim OIDC — grup SCIM yang dikirim tidak disimpan.
• Peran pemilik tidak dapat dijangkau dari SSO — baik sebagai peran default maupun melalui pemetaan grup.
• Relay WebSocket tidak pernah menjadi saluran SSO; ponsel yang hanya menjangkau server melalui relay tidak dapat menyelesaikan perjalanan bolak-balik browser terhadapnya.