Mỗi lần đăng nhập riêng biệt là thêm một mật khẩu cần đặt lại và thêm một tài khoản cần đóng khi có người nghỉ việc. Đăng nhập một lần (SSO) SAML kết nối hệ thống quản lý học tập của bạn với nhà cung cấp danh tính, để mọi người đăng nhập vào đào tạo bằng tài khoản công việc và quyền truy cập đi theo danh bạ của bạn. Dưới đây là cách SAML hoạt động, việc thiết lập với Microsoft Entra ID, Okta hoặc Google Workspace diễn ra thế nào, và những điều cần kiểm tra trước khi đưa vào sử dụng.
Đăng nhập một lần SAML hoạt động như thế nào
SAML (Security Assertion Markup Language) 2.0 là một chuẩn mở để chuyển thông tin đăng nhập giữa hai hệ thống tin tưởng lẫn nhau. LMS không bao giờ thấy mật khẩu của người dùng: nó chuyển họ đến nhà cung cấp danh tính của bạn, nơi xác minh họ là ai, kèm theo mọi bước xác thực đa yếu tố mà bạn yêu cầu, rồi đưa họ trở lại cùng một tuyên bố có chữ ký.
| Thuật ngữ | Ý nghĩa |
|---|---|
| Nhà cung cấp danh tính (IdP) | Hệ thống xác thực nhân sự của bạn, chẳng hạn Entra ID, Okta hoặc Google Workspace. |
| Nhà cung cấp dịch vụ (SP) | Ứng dụng mà mọi người đăng nhập vào: LMS của bạn. |
| Assertion | Tuyên bố XML có chữ ký từ IdP: người đó là ai, họ đăng nhập lúc nào, cùng các thuộc tính như email và họ tên. |
| Entity ID | Tên duy nhất của mỗi bên, thường có dạng giống URL nhưng chỉ là một mã định danh. Hai bên phải khớp chính xác. |
| ACS URL | Assertion Consumer Service URL: địa chỉ của LMS nhận phản hồi từ IdP. |
| Chứng chỉ ký | IdP ký bằng khóa riêng; LMS xác minh bằng chứng chỉ công khai của IdP và từ chối các assertion bị giả mạo hoặc bị thay đổi. |
| Metadata | Một tệp XML gói gọn entity ID, các điểm cuối và chứng chỉ, sẵn sàng để nhập vào. |
Assertion có thời hạn ngắn và nêu rõ đối tượng nhận (entity ID của SP). SP sẽ từ chối mọi thứ đã hết hạn hoặc dành cho ứng dụng khác.
Vì sao SSO đáng giá với một LMS
- Không thêm mật khẩu nào. Mọi người dùng tài khoản hằng ngày của họ, và xác thực đa yếu tố (MFA) cùng chính sách truy cập của bạn áp dụng cho cả đào tạo.
- Nhân sự mới có quyền truy cập nhanh. Gán ứng dụng LMS cho một nhóm, và nhân viên mới trong nhóm đó có thể đăng nhập ngay từ ngày đầu.
- Nhân sự nghỉ việc mất quyền truy cập ngay từ nguồn. Vô hiệu hóa một người trong danh bạ của bạn thì họ không thể bắt đầu phiên LMS mới. SAML kiểm soát việc đăng nhập chứ không phải tài khoản, vì vậy hãy nhớ lưu trữ tài khoản LMS như một phần của quy trình nghỉ việc.
Tạo tài khoản just-in-time
Với cấp tài khoản just-in-time (JIT), LMS tạo tài khoản vào lần đầu tiên ai đó đăng nhập, dựa trên các thuộc tính trong assertion, nên không có danh sách người dùng nào phải nhập. Hãy đặt các rào chắn xung quanh tính năng này:
- Giới hạn trong các tên miền email của chính bạn, để một ứng dụng cấu hình sai hoặc một tài khoản khách không tạo ra những người dùng lạc lõng.
- Cấp cho tài khoản mới vai trò thấp nhất, và trao quyền quản trị viên một cách có chủ đích.
- Đối chiếu người dùng bằng một mã định danh ổn định khi IdP của bạn có thể gửi, vì địa chỉ email có thể thay đổi.
Đăng nhập khởi tạo từ SP và từ IdP
- Khởi tạo từ SP: người dùng mở LMS, LMS gửi yêu cầu xác thực đến IdP, và IdP gửi phản hồi đến ACS URL. Cách này hoạt động từ dấu trang và liên kết trong email, và thường được xem là luồng an toàn hơn vì phản hồi trả lời một yêu cầu do LMS gửi đi.
- Khởi tạo từ IdP: người dùng nhấp vào biểu tượng ứng dụng trong Microsoft My Apps, bảng điều khiển Okta hoặc menu ứng dụng Google, và IdP gửi một phản hồi không được yêu cầu đến ACS URL.
Bạn có thể cung cấp cả hai; hãy thử nghiệm từng cách.
Thiết lập SAML SSO từng bước
Trình tự gần như giống nhau ở mọi nơi:
- Lên kế hoạch phạm vi: ai dùng SSO, nhóm nào được gán ứng dụng, những tên miền email nào được phép, và thuộc tính nào dùng để nhận diện mỗi người.
- Tạo kết nối trong LMS và ghi lại entity ID cùng ACS URL của kết nối đó.
- Tạo một ứng dụng SAML tại IdP với các giá trị đó, chọn định dạng NameID, và thêm các thuộc tính email, tên và họ.
- Gán người dùng hoặc nhóm; những người chưa được gán thường bị từ chối.
- Cung cấp cho LMS thông tin của IdP: một URL metadata, một tệp metadata, hoặc entity ID, URL đăng nhập và chứng chỉ ký của IdP.
- Ánh xạ các thuộc tính sang những tên mà IdP của bạn thực sự gửi.
- Thử nghiệm, rồi bật lên, và thông báo cho mọi người biết những gì sắp thay đổi.
Lưu ý theo từng nhà cung cấp
Tài liệu của nhà cung cấp có các màn hình chính xác. Những điều đáng biết:
- Microsoft Entra ID: dùng một enterprise application không thuộc thư viện (non-gallery), không phải app registration vì loại này không hỗ trợ SAML. Tên claim là các URI dài, vì vậy hãy sao chép chính xác. Object ID là một mã định danh ổn định tốt. Với những người không có hộp thư, claim email có thể để trống; user principal name có thể thay thế nếu đó là một địa chỉ thật.
- Okta: tạo một app integration SAML 2.0. Bạn tự đặt tên cho các attribute statement, vì vậy chúng phải khớp chính xác với ánh xạ trong LMS, kể cả chữ hoa chữ thường. ID người dùng nội bộ của Okta là một mã định danh ổn định.
- Google Workspace: thêm một ứng dụng SAML tùy chỉnh và tải xuống tệp metadata của nó. Ứng dụng ban đầu ở trạng thái tắt, vì vậy hãy bật cho đúng các đơn vị tổ chức hoặc nhóm. Thiết lập thông thường nhận diện mọi người bằng email chính, vì vậy hãy lên kế hoạch cho các địa chỉ bị đổi tên và bị dùng lại.
Danh sách kiểm tra
Trước khi đưa vào sử dụng, hãy kiểm tra những mục này trong một cửa sổ trình duyệt riêng tư:
- Một người dùng hiện có đăng nhập bắt đầu từ LMS, và một lần nữa từ biểu tượng ứng dụng.
- Một người dùng mới thuộc tên miền của bạn được tạo tài khoản với vai trò đúng.
- Người không được gán vào ứng dụng bị từ chối.
- Người nằm ngoài các tên miền được phép của bạn bị từ chối.
- Email, tên và họ được chuyển đến chính xác.
- Quản trị viên vẫn vào được thông qua phương thức khôi phục.
Những cạm bẫy thường gặp
Lệch đồng hồ
Nếu đồng hồ của IdP và LMS lệch nhau nhiều hơn mức LMS chấp nhận, các assertion hợp lệ sẽ bị từ chối vì chưa có hiệu lực hoặc đã hết hạn. Lỗi này chủ yếu ảnh hưởng đến các máy chủ danh tính tự lưu trữ, vì vậy hãy giữ đồng hồ của chúng được đồng bộ.
Thay chứng chỉ
Chứng chỉ ký của IdP sẽ hết hạn, và nếu LMS không tin cậy chứng chỉ thay thế thì mọi lượt đăng nhập đều thất bại cùng một lúc. Hãy ghi ngày hết hạn vào lịch. Nếu LMS của bạn có thể tin cậy hai chứng chỉ, hãy thêm chứng chỉ mới vào đó trước, rồi mới kích hoạt nó tại IdP; nếu không, hãy chuyển cả hai bên cùng lúc vào thời điểm ít người dùng. Hãy thử nghiệm ngay sau đó.
Ánh xạ thuộc tính
Tên thuộc tính thường được so khớp chính xác: một LMS mong đợi email sẽ không chấp nhận Email. Hãy kiểm tra cả mã định danh. Một NameID dạng transient thay đổi theo từng phiên và địa chỉ email có thể thay đổi; NameID dạng persistent hoặc một thuộc tính ID bất biến thì ổn định. Nếu mọi người được đối chiếu bằng email, hãy lưu trữ tài khoản của người nghỉ việc trước khi địa chỉ của họ được cấp lại.
Không khớp tên miền email
Danh bạ thường có những người mà tên đăng nhập không phải là địa chỉ email, nhà thầu thuộc các tên miền khác, và nhân viên của các doanh nghiệp được mua lại vẫn dùng tên miền cũ. Nếu LMS giới hạn tài khoản theo một số tên miền nhất định, họ sẽ bị từ chối. Hãy liệt kê mọi tên miền trước khi đưa vào sử dụng.
Acadenix làm việc này như thế nào
SAML SSO có trên gói Gold, kèm hướng dẫn từng bước cho Entra ID, Okta và Google Workspace.
- Thử nghiệm, rồi kích hoạt. Bạn lưu thông tin IdP của mình dưới dạng bản nháp, chạy Test configuration (kiểm tra cấu hình) bằng cách đăng nhập tại nhà cung cấp của bạn, và chỉ sau đó mới kích hoạt. Nếu thiếu claim email, hệ thống sẽ báo cùng với tên các claim mà nhà cung cấp của bạn đã thực sự gửi.
- Thay đổi theo giai đoạn. Chứng chỉ hoặc tenant mới được đưa vào dưới dạng bản cập nhật cấu hình, và cấu hình hiện tại vẫn hoạt động cho đến khi bạn kích hoạt bản mới.
- JIT trong phạm vi tên miền của bạn. Người chưa có tài khoản sẽ được cấp tài khoản học viên ở lần đăng nhập đầu tiên, chỉ khi email của họ thuộc các tên miền đăng ký của tổ chức bạn, và bạn có thể tắt tính năng này. Khi một người đã có tài khoản Acadenix đăng nhập lần đầu qua IdP của bạn, Acadenix gửi email cho họ một mã dùng một lần để xác nhận liên kết. Việc này chỉ xảy ra một lần cho mỗi người.
- Cả hai cách vào. Mọi người có thể bắt đầu từ trang đăng nhập của bạn, trang này có thể đưa họ thẳng đến IdP hoặc hiển thị một nút, hoặc từ biểu tượng trong My Apps, Okta hay Google.
- Một kết nối, một tổ chức. Một kết nối SAML không được truyền xuống các tổ chức nằm dưới tổ chức sở hữu nó, điều này quan trọng với các tập đoàn có nhiều địa điểm.
- Một phương thức khôi phục. Nếu IdP của bạn ngừng hoạt động, quản trị viên vẫn có thể đăng nhập bằng mã dùng một lần gửi qua email, và phương thức này không thể bị tắt.
Bên cạnh SAML, mọi người có thể đăng nhập bằng mã gửi qua email hoặc tài khoản Google, Microsoft hay LinkedIn. Xem thêm tại trang bảo mật của chúng tôi.
Những điểm chính cần nhớ
- Trao đổi entity ID, ACS URL và metadata, rồi ánh xạ một mã định danh ổn định và email đã xác minh.
- Giới hạn tài khoản just-in-time trong các tên miền của bạn và ở vai trò thấp nhất.
- Thử cả hai luồng đăng nhập, các trường hợp bị từ chối và phương thức khôi phục trước khi đưa vào sử dụng.
- Ghi ngày hết hạn chứng chỉ vào lịch và lưu trữ tài khoản LMS của người nghỉ việc.
Muốn kết nối Acadenix với nhà cung cấp danh tính của bạn? Hãy so sánh các gói trên trang bảng giá, hoặc trao đổi với chúng tôi về thiết lập của bạn.
