Đăng nhập một lần

Đăng nhập một lần cho phép một nhà cung cấp danh tính (IdP) bên ngoài quyết định ai được phép đăng nhập vào máy chủ Control Center của bạn. Có hai giao thức được hỗ trợ — SAML 2.0 và OpenID Connect — và cả hai đều dẫn tới cùng một đích: một thông tin xác thực thiết bị vừa mới được tạo, không thể phân biệt với một lời mời hay một lần ghép nối bằng mã QR ở mọi bước phía sau.

Hình dạng của một lần đăng nhập

Đăng nhập SAML diễn ra qua trình duyệt. IdP không bao giờ mở một kết nối tới máy chủ của bạn; trình duyệt của người dùng mang theo mọi thứ:

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

Vì trình duyệt đóng vai người đưa thư, một máy chủ nằm sau NAT vẫn hoạt động tốt cho việc đăng nhập: localhost, LAN, Tailscale, VPN hay một tunnel đều dùng được — chỉ trình duyệt của người dùng mới cần tiếp cận được URL ACS. Relay WebSocket mà tính năng điều khiển từ xa trên điện thoại dùng không thể chuyên chở vòng khứ hồi HTTP, và đó là lý do các điểm vào SSO luôn nhắm tới origin HTTP của máy chủ.

OpenID Connect theo cùng hình dạng đó với một vòng authorization-code + PKCE; các claim được đọc từ endpoint token của bên phát hành qua TLS, nên trình duyệt không bao giờ cung cấp dữ liệu danh tính.

Các adapter

Control Center phân chia trách nhiệm một cách có chủ đích:

Thành phần	Vị trí	Phụ trách
cc_saml native	packages/cc_natives/native/saml/	Xác minh XML-DSig, chuẩn hóa, kiểm tra hồ sơ SAML — được giao cho crate saml thuần Rust đã ghim phiên bản, nằm sau một ABI C không trạng thái
SamlService / OidcService	cc_server_core	trạng thái đăng nhập (bộ theo dõi yêu cầu đang chờ, khử trùng lặp khi phát lại), các tham số điều chỉnh chính sách xác minh, lời gọi cấp phát dùng chung
SsoProvisioner	cc_server_core	tìm hoặc tạo người dùng, ghim chủ thể của nhà cung cấp, cấp tư cách thành viên theo chính sách tự động kết nạp thành viên
ScimService	cc_server_core	bề mặt đẩy SCIM 2.0 (vòng đời cấp phát/hủy cấp phát)
SsoSettingsService	cc_server_core	các dòng kết nối đã lưu, việc áp dụng lại trực tiếp, token SCIM

Cố ý không có phương án dự phòng mã hóa SAML thuần Dart: việc tự tay viết XML-DSig/chuẩn hóa chính là nơi các lỗ hổng bọc chữ ký trú ngụ, nên khi thiếu thư viện cc_saml, cả đăng nhập SAML lẫn quá trình khởi động máy chủ đều bị từ chối. Native này không trạng thái theo thiết kế — trạng thái xuyên yêu cầu nằm trong các service Dart, dùng một lần và tồn tại trong thời gian ngắn.

Một lần đăng nhập xác minh những gì

Bên trong native đã được xác minh và service, theo thứ tự:

1. chữ ký của khẳng định (luôn bắt buộc; chữ ký của phong bì phản hồi là tùy chọn theo cấu hình) — có khả năng chống bọc chữ ký về mặt cấu trúc vì dữ liệu đã được kiểm tra hợp lệ được gắn với phần tử đã xác minh,
2. bên phát hành khớp với IdP đã cấu hình,
3. đối tượng nêu tên nhà cung cấp dịch vụ này,
4. đích đến là URL ACS của chúng ta,
5. InResponseTo khớp với một AuthnRequest đang chờ mà chúng ta đã phát đi (các phản hồi không được yêu cầu, do IdP khởi tạo, mặc định bị tắt),
6. các cửa sổ thời hạn hiệu lực nằm trong độ lệch đồng hồ (mặc định 90 giây) và
7. id khẳng định chưa từng xuất hiện trước đó (bộ nhớ đệm chống phát lại).

Các lỗi trả về dưới dạng mã có kiểu — signature, expired, audience, destination, issuer, request-match — và các endpoint trả lời bằng lỗi chung chung, nên kẻ tấn công không biết được vì sao một bản giả mạo thất bại.

Tài khoản và việc ghim chủ thể

Lần đăng nhập SSO đầu tiên ghim chủ thể bất biến của nhà cung cấp (issuer cùng với SAML NameID / OIDC sub, hoặc externalId của SCIM) vào tài khoản. Từ đó trở đi, chủ thể — chứ không phải email — là thứ nhận diện lần đăng nhập. Nếu sau này người khác trình ra cùng email đó từ chính IdP ấy hoặc một IdP khác, tài khoản đã ghim sẽ từ chối họ. Đây là điều ngăn một email được tái sử dụng tại nhà cung cấp biến thành việc chiếm đoạt tài khoản.

Cấp phát và hủy cấp phát

Việc cấp phát JIT diễn ra ngay lúc đăng nhập (SsoProvisioner). SCIM là một bề mặt đẩy riêng (ScimService), ghim cùng chủ thể đó lên dòng người dùng; nó không cấp tư cách thành viên không gian làm việc. Việc hủy cấp phát — SCIM active: false hoặc DELETE — bị từ chối nếu tài khoản là chủ sở hữu không gian làm việc (hãy chuyển giao trước). Nếu không, trước tiên nó thu hồi mọi thông tin xác thực thiết bị (các phiên biến mất trong vài giây nhờ cơ chế theo dõi thiết bị), gỡ bỏ mọi tư cách thành viên không gian làm việc và đánh dấu tài khoản là đã vô hiệu hóa. Dòng người dùng vẫn tồn tại: quy kết là vĩnh viễn. Việc kích hoạt lại khôi phục đăng nhập nhưng không bao giờ cấp lại tư cách thành viên.

Những gì nằm ngoài

• Việc ánh xạ nhóm→vai trò diễn ra lúc đăng nhập từ các thuộc tính SAML / claim OIDC — các nhóm đẩy qua SCIM không được lưu lại.
• Không thể chạm tới vai trò chủ sở hữu từ SSO — dù là vai trò mặc định hay thông qua một ánh xạ nhóm.
• Relay WebSocket không bao giờ là một kênh SSO; những chiếc điện thoại chỉ tiếp cận được máy chủ qua relay thì không thể hoàn tất một vòng khứ hồi trình duyệt với nó.