การลงชื่อเข้าใช้ครั้งเดียว

การลงชื่อเข้าใช้ครั้งเดียวช่วยให้ผู้ให้บริการข้อมูลระบุตัวตนภายนอก (IdP) เป็นผู้ตัดสินว่าใครสามารถลงชื่อเข้าใช้เซิร์ฟเวอร์ Control Center ของคุณได้ รองรับสองโปรโตคอล — SAML 2.0 และ OpenID Connect — และทั้งคู่ลงเอยที่จุดเดียวกัน คือข้อมูลรับรองอุปกรณ์ที่เพิ่งออกใหม่ ซึ่งแยกไม่ออกจากคำเชิญหรือการจับคู่ด้วย QR ในทุกส่วนปลายน้ำ

รูปแบบของการลงชื่อเข้าใช้

การลงชื่อเข้าใช้ด้วย SAML เป็นการดำเนินการผ่านเบราว์เซอร์ IdP ไม่เคยเปิดการเชื่อมต่อไปยังเซิร์ฟเวอร์ของคุณ เบราว์เซอร์ของผู้ใช้เป็นตัวนำพาทุกสิ่งไปเอง:

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

เพราะเบราว์เซอร์เป็นผู้ส่งสาร เซิร์ฟเวอร์ที่อยู่หลัง NAT จึงใช้งานได้ตามปกติ สำหรับการลงชื่อเข้าใช้: localhost, LAN, Tailscale, VPN หรือทันเนลก็ใช้ได้ทั้งนั้น — มีเพียงเบราว์เซอร์ของผู้ใช้เท่านั้นที่ต้องเข้าถึง ACS URL ได้ รีเลย์ WebSocket ที่ใช้ในการควบคุมระยะไกลผ่านโทรศัพท์ไม่สามารถรับส่งการไปกลับของ HTTP ได้ จึงเป็นเหตุให้จุดเริ่มต้นของ SSO กำหนดเป้าหมายเป็น HTTP origin ของเซิร์ฟเวอร์เสมอ

OpenID Connect มีรูปแบบเดียวกัน โดยใช้การไปกลับแบบ authorization-code + PKCE ส่วน claims ถูกอ่านจาก token endpoint ของผู้ออกโทเคนผ่าน TLS เบราว์เซอร์จึงไม่ต้องส่งข้อมูลระบุตัวตนเลย

อะแดปเตอร์

Control Center แบ่งความรับผิดชอบอย่างจงใจ:

ส่วนประกอบ	อยู่ที่ใด	รับผิดชอบ
cc_saml เนทีฟ	packages/cc_natives/native/saml/	การตรวจสอบ XML-DSig, การทำ canonicalization, การตรวจสอบความถูกต้องของโปรไฟล์ SAML — มอบหมายให้ crate saml แบบ pure-Rust ที่ปักหมุดเวอร์ชันไว้ ซึ่งอยู่เบื้องหลัง C ABI ที่ไม่มีสถานะ
SamlService / OidcService	cc_server_core	สถานะการลงชื่อเข้าใช้ (ตัวติดตามคำขอที่ค้างอยู่, การตัดรายการซ้ำของการเล่นซ้ำ), ปุ่มปรับนโยบายการตรวจสอบความถูกต้อง, การเรียกจัดสรรผู้ใช้ที่ใช้ร่วมกัน
SsoProvisioner	cc_server_core	ค้นหาหรือสร้างผู้ใช้, ปักหมุด subject ของผู้ให้บริการ, ให้สิทธิ์สมาชิกภายใต้นโยบายสมาชิกอัตโนมัติ
ScimService	cc_server_core	พื้นผิวแบบ push ของ SCIM 2.0 (วงจรชีวิตการจัดสรร/ถอนการจัดสรร)
SsoSettingsService	cc_server_core	แถวการเชื่อมต่อที่บันทึกไว้, การนำไปใช้ใหม่แบบสด, โทเคน SCIM

จงใจแล้วว่าไม่มีทางถอยกลับไปใช้การเข้ารหัส SAML แบบ pure-Dart: การเขียน XML-DSig/canonicalization ขึ้นเองด้วยมือคือที่อยู่ของช่องโหว่ signature-wrapping พอดี ดังนั้นหากไลบรารี cc_saml หายไป ระบบจะปฏิเสธทั้งการลงชื่อเข้าใช้ด้วย SAML และการบูตเซิร์ฟเวอร์ เนทีฟนี้ไม่มีสถานะโดยออกแบบไว้ — สถานะข้ามคำขออยู่ในเซอร์วิส Dart ใช้ครั้งเดียวและมีอายุสั้น

การลงชื่อเข้าใช้ตรวจสอบอะไรบ้าง

ภายในเนทีฟที่ผ่านการตรวจสอบและเซอร์วิส เรียงตามลำดับ:

1. ลายเซ็นของ assertion (บังคับเสมอ ส่วนลายเซ็นของซอง response เป็นทางเลือกตามการกำหนดค่า) — ต้านทาน signature-wrapping เชิงโครงสร้าง เพราะเพย์โหลดที่ผ่านการตรวจสอบผูกติดกับอิลิเมนต์ที่ตรวจสอบแล้ว,
2. ผู้ออกตรงกับ IdP ที่กำหนดค่าไว้,
3. ผู้รับระบุชื่อ service provider รายนี้,
4. ปลายทางคือ ACS URL ของเรา,
5. InResponseTo ตรงกับ AuthnRequest ที่ค้างอยู่ซึ่งเราออกไป (response ที่ไม่ได้ร้องขอและที่ IdP เป็นผู้เริ่ม ปิดไว้เป็นค่าเริ่มต้น),
6. หน้าต่าง ช่วงอายุ ยังอยู่ในเกณฑ์ความคลาดเคลื่อนของนาฬิกา (ค่าเริ่มต้น 90s) และ
7. รหัส assertion ไม่เคยปรากฏมาก่อน (แคชกันการเล่นซ้ำ)

ความล้มเหลวจะส่งกลับมาเป็นรหัสที่มีชนิด — signature, expired, audience, destination, issuer, request-match — และปลายทางจะตอบด้วยข้อผิดพลาดแบบกว้าง ๆ ผู้โจมตีจึงไม่รู้อะไรเลยว่าการปลอมแปลงล้มเหลวเพราะเหตุใด

บัญชีและการปักหมุด subject

การลงชื่อเข้าใช้ด้วย SSO ครั้งแรกจะปักหมุด subject ที่เปลี่ยนแปลงไม่ได้ของผู้ให้บริการ (issuer รวมกับ SAML NameID / OIDC sub หรือ SCIM externalId) ไว้กับบัญชี ตั้งแต่นั้นเป็นต้นไป subject — ไม่ใช่อีเมล — เป็นสิ่งที่ระบุตัวตนของการลงชื่อเข้าใช้ หากภายหลังมีคนอื่นนำอีเมลเดียวกันมาจาก IdP เดียวกันหรือ IdP อื่น บัญชีที่ปักหมุดไว้จะปฏิเสธผู้นั้น นี่คือสิ่งที่หยุดไม่ให้อีเมลที่ถูกนำกลับมาใช้ใหม่ที่ผู้ให้บริการรายหนึ่งกลายเป็นการยึดบัญชี

การจัดสรรและการถอนการจัดสรร

การจัดสรรแบบ JIT เกิดขึ้นตอนลงชื่อเข้าใช้ (SsoProvisioner) ส่วน SCIM เป็นพื้นผิวแบบ push แยกต่างหาก (ScimService) ที่ปักหมุด subject เดียวกันไว้บนแถวผู้ใช้ แต่ไม่ได้ให้สิทธิ์สมาชิกเวิร์กสเปซ การถอนการจัดสรร — SCIM active: false หรือ DELETE — จะปฏิเสธหากบัญชีเป็นเจ้าของเวิร์กสเปซ (ต้องโอนก่อน) มิฉะนั้นจะเพิกถอนข้อมูลรับรองของอุปกรณ์ทุกชิ้นก่อน (เซสชันจะหลุดภายในไม่กี่วินาทีผ่านการเฝ้าดูอุปกรณ์) ลบสิทธิ์สมาชิกเวิร์กสเปซทุกแห่ง และประทับว่าบัญชีถูกปิดใช้งาน แถวผู้ใช้ยังคงอยู่: การระบุที่มาเป็นสิ่งที่ถาวร การเปิดใช้งานอีกครั้งจะคืนการลงชื่อเข้าใช้ แต่ไม่เคยให้สิทธิ์สมาชิกกลับคืน

สิ่งที่ถูกกันออกไป

• การแมปกลุ่ม→บทบาทเกิดขึ้นตอนลงชื่อเข้าใช้ จากแอตทริบิวต์ SAML / claims ของ OIDC — กลุ่มที่ push ผ่าน SCIM จะไม่ถูกจัดเก็บ
• บทบาทเจ้าของเอื้อมไม่ถึงจาก SSO — ทั้งในฐานะบทบาทเริ่มต้นและผ่านการแมปกลุ่ม
• รีเลย์ WebSocket ไม่เคยเป็นช่องทางของ SSO โทรศัพท์ที่เข้าถึงเซิร์ฟเวอร์ได้ทางรีเลย์เท่านั้นไม่สามารถทำการไปกลับผ่านเบราว์เซอร์กับเซิร์ฟเวอร์ได้