Daftar masuk tunggal

Daftar masuk tunggal membolehkan pembekal identiti (IdP) luaran menentukan siapa yang boleh log masuk ke pelayan Control Center anda. Dua protokol disokong — SAML 2.0 dan OpenID Connect — dan kedua-duanya berakhir di tempat yang sama: kelayakan peranti yang baru dijana yang tidak dapat dibezakan daripada jemputan atau pasangan kod QR di semua bahagian hiliran.

Bentuk satu log masuk

Log masuk SAML diperantarakan penyemak imbas. IdP tidak pernah membuka sambungan ke pelayan anda; penyemak imbas pengguna membawa segala-galanya:

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

Oleh sebab penyemak imbas ialah penghantar, pelayan di belakang NAT berfungsi dengan baik untuk log masuk: localhost, LAN, Tailscale, VPN atau terowong semuanya berfungsi — hanya penyemak imbas pengguna perlu mencapai URL ACS. Geganti WebSocket yang digunakan oleh kawalan jauh telefon tidak dapat membawa perjalanan pergi-balik HTTP, itulah sebabnya titik masuk SSO sentiasa menyasarkan asalan HTTP pelayan.

OpenID Connect mengikut bentuk yang sama dengan perjalanan pergi-balik kod kebenaran + PKCE; tuntutan dibaca daripada titik akhir token penerbit melalui TLS, jadi penyemak imbas tidak pernah membekalkan data identiti sama sekali.

Penyesuai

Control Center membahagikan tanggungjawab itu dengan sengaja:

Komponen	Di mana	Memiliki
cc_saml natif	packages/cc_natives/native/saml/	Pengesahan XML-DSig, kanonikalisasi, pengesahan profil SAML — diwakilkan kepada crate saml Rust tulen yang dipin di sebalik C ABI tanpa keadaan
SamlService / OidcService	cc_server_core	keadaan log masuk (penjejak permintaan yang belum selesai, deduplikasi main semula), tombol polisi pengesahan, panggilan peruntukan yang dikongsi
SsoProvisioner	cc_server_core	cari-atau-cipta pengguna, sematkan subjek penyedia, berikan keahlian di bawah polisi ahli automatik
ScimService	cc_server_core	permukaan tolak SCIM 2.0 (kitaran hayat peruntukan/nyahperuntukan)
SsoSettingsService	cc_server_core	baris sambungan yang disimpan, penggunaan semula secara langsung, token SCIM

Sengaja tiada sandaran kripto SAML Dart tulen: XML-DSig/kanonikalisasi yang ditulis sendiri ialah tepat tempat tinggal kerentanan pembalutan tandatangan, jadi ketiadaan pustaka cc_saml menolak kedua-dua log masuk SAML dan but pelayan. Natif itu tanpa keadaan mengikut reka bentuk — keadaan merentas permintaan hidup dalam perkhidmatan Dart, sekali guna dan berjangka pendek.

Apa yang disahkan oleh log masuk

Di dalam natif yang disahkan dan perkhidmatan itu, mengikut urutan:

1. tandatangan penegasan itu (sentiasa diperlukan; tandatangan sampul jawapan adalah pilihan mengikut konfigurasi) — tahan secara struktur terhadap pembalutan tandatangan kerana muatan yang disahkan terikat pada elemen yang disahkan,
2. penerbit sepadan dengan IdP yang dikonfigurasikan,
3. audiens menamakan penyedia perkhidmatan ini,
4. destinasi ialah URL ACS kami,
5. InResponseTo sepadan dengan AuthnRequest belum selesai yang kami keluarkan (jawapan tidak diminta yang dimulakan IdP dimatikan secara lalai),
6. tetingkap jangka hayat bertahan dalam sisihan jam (lalai 90s), dan
7. id penegasan tidak pernah dilihat sebelum ini (cache main semula).

Kegagalan dikembalikan sebagai kod bertaip — tandatangan, luput, audiens, destinasi, penerbit, padanan permintaan — dan titik akhir menjawab dengan ralat generik, jadi penyerang tidak mempelajari apa-apa tentang sebab satu pemalsuan gagal.

Akaun dan penyematan subjek

Log masuk SSO yang pertama menyematkan subjek tak boleh ubah penyedia (issuer serta SAML NameID / sub OIDC, atau SCIM externalId) pada akaun itu. Selepas itu, subjek — bukan e-mel — mengenal pasti log masuk. Jika orang lain kemudiannya mengemukakan e-mel yang sama daripada IdP yang sama atau yang lain, akaun yang disematkan itu menolak mereka. Inilah yang menghalang e-mel yang dikitar semula di penyedia daripada menjadi pengambilalihan akaun.

Peruntukan dan nyahperuntukan

Peruntukan JIT berlaku semasa log masuk (SsoProvisioner). SCIM ialah permukaan tolak yang berasingan (ScimService) yang menyematkan subjek yang sama pada baris pengguna; ia tidak memberikan keahlian ruang kerja. Nyahperuntukan — SCIM active: false atau DELETE — menolak jika akaun itu ialah pemilik ruang kerja (pindahkan dahulu). Jika tidak, ia menarik balik setiap kelayakan peranti terlebih dahulu (sesi digugurkan dalam beberapa saat melalui pemantauan peranti), membuang setiap keahlian ruang kerja dan menetapkan akaun sebagai dinyahaktifkan. Baris pengguna kekal: atribusi adalah kekal. Pengaktifan semula memulihkan log masuk tetapi tidak pernah memberikan semula keahlian.

Apa yang kekal di luar

• Pemetaan kumpulan→peranan berlaku semasa log masuk daripada atribut SAML / tuntutan OIDC — kumpulan SCIM yang ditolak tidak disimpan.
• Peranan pemilik tidak boleh dicapai daripada SSO — sama ada sebagai peranan lalai mahupun melalui pemetaan kumpulan.
• Geganti WebSocket tidak pernah menjadi saluran SSO; telefon yang hanya mencapai pelayan melalui geganti itu tidak dapat melengkapkan perjalanan pergi-balik penyemak imbas terhadapnya.