Single Sign-On(SSO)

Một nhân viên ngân hàng buổi sáng phải mở: hệ thống nội bộ, phần mềm chấm công, cổng đào tạo, công cụ báo cáo. Bốn mật khẩu, bốn quy tắc đổi mật khẩu khác nhau. Kết quả quen thuộc là một tờ giấy nhớ dán dưới bàn phím. SSO gom việc hỏi mật khẩu về một chỗ. Bốn ứng dụng kia thôi tự kiểm tra; chúng quay sang hỏi cái chỗ đó xem bạn là ai.

Với SSO, các ứng dụng thôi tự hỏi mật khẩu và chuyển việc đó cho nhà cung cấp danh tính của tổ chức.

Luồng nhìn từ phía người dùng

1. Bạn mở ứng dụng nhân sự. Ứng dụng thấy bạn chưa đăng nhập nên đẩy sang trang đăng nhập chung của công ty.
2. Bạn nhập tài khoản công ty, có thể thêm một lớp xác thực nữa qua ứng dụng trên điện thoại.
3. Trang chung xác minh xong, trả về một vé điện tử cho ứng dụng nhân sự.
4. Ứng dụng đọc vé, biết bạn là ai và thuộc nhóm quyền nào, rồi cho vào.
5. Mở tiếp cổng đào tạo trong cùng phiên làm việc — không phải nhập lại gì cả.

Từ vựng tối thiểu

• IdP (Identity Provider) — nơi giữ danh tính. Doanh nghiệp VN hay gặp Microsoft Entra ID, Google Workspace, Keycloak. Ngân hàng thì vẫn còn LDAP đời cũ, và đó là nơi rắc rối bắt đầu.
• SP (Service Provider) — ứng dụng tin vào IdP.
• SAML 2.0 là chuẩn cũ hơn, chạy bằng XML. Đừng nghĩ cũ là sắp chết: ngân hàng và bảo hiểm vẫn dùng đầy.
• OAuth 2.0 là chuẩn về cấp quyền truy cập tài nguyên. Bản thân nó không phải chuẩn đăng nhập.
• OIDC (OpenID Connect) là lớp đăng nhập xây trên OAuth 2.0, phổ biến với ứng dụng web và di động mới.
• JIT provisioning: lần đầu ai đó đăng nhập thành công thì ứng dụng tự tạo tài khoản cho họ.

Chỗ hay nhầm nhất là gộp OAuth 2.0 với đăng nhập. OAuth trả lời câu hỏi ứng dụng này được phép chạm vào dữ liệu gì. OIDC trả lời câu người dùng này là ai. Hai câu khác nhau, và trong hồ sơ mời thầu người ta viết lẫn suốt.

Yêu cầu BA phải chốt

• Nguồn sự thật về nhân sự: ai vào công ty, ai nghỉ việc thì hệ thống nào biết trước. Thường là HRM, và nó phải đẩy được sang IdP.
• Thu hồi quyền: nhân viên nghỉ việc lúc 17h, tới mấy giờ thì hết vào được mọi hệ thống. Đây là câu hỏi kiểm toán rất hay hỏi.
• Ánh xạ quyền: nhóm trong IdP tương ứng với vai trò nào trong ứng dụng. Viết thành bảng, đừng để dev tự suy.
• Bấm thoát ở một ứng dụng thì thoát luôn mọi ứng dụng, hay chỉ ứng dụng đó. Hai lựa chọn cho ra hai trải nghiệm rất khác nhau.
• IdP sập thì có tài khoản khẩn cấp không, ai giữ.
• Nhà thầu, cộng tác viên, khách hàng — dùng chung IdP hay đi lối riêng.

Ví dụ thực tế

Tháng ba năm đó, helpdesk của một chuỗi bán lẻ đếm được 317 yêu cầu cấp lại mật khẩu. Chuỗi có 2.380 nhân viên và 11 ứng dụng nội bộ, mỗi yêu cầu ngốn khoảng 10 phút của một bạn trực. Sau khi gom về một IdP và bật SSO cho 8 trong 11 ứng dụng, con số của tháng ba năm sau là 74.

Ba ứng dụng còn lại thì chịu. Một trong đó là phần mềm kế toán đời cũ, chỉ hỗ trợ tài khoản cục bộ, và vendor đã ngừng phát triển từ lâu. Giải pháp tạm là quy trình thủ công có kiểm soát, mỗi quý rà soát danh sách người dùng một lần. Trong tài liệu, BA ghi đây là ngoại lệ có thời hạn, kèm ngày hết hiệu lực. Chỉ một dòng. Hai năm sau công ty đổi phần mềm kế toán, và yêu cầu SSO nằm sẵn trong hồ sơ mời thầu nhờ đúng dòng đó.