Đăng nhập một lần trả lời câu hỏi xác thực: Microsoft đã xác minh người dùng này theo chính sách của tổ chức chưa? Nó không trả lời mọi câu hỏi phân quyền bên trong Odoo.
Một người dùng đã được xác thực có thể cần quyền truy cập vào bán hàng nhưng không phải kế toán, dự án nhưng không phải bảng lương, hoặc cổng khách hàng nhưng không phải giao diện nội bộ. Những quyết định đó vẫn là trách nhiệm của Odoo. Nhóm Microsoft Entra và vai trò ứng dụng có thể cung cấp đầu vào tin cậy để đưa ra các quyết định nhất quán hơn.
Nhóm và vai trò ứng dụng phục vụ các mục đích khác nhau
Nhóm Microsoft Entra thuộc về tenant. Chúng có thể đại diện cho phòng ban, chức năng công việc, dự án hoặc ranh giới bảo mật. Vai trò ứng dụng thuộc về một app registration cụ thể và mô tả các vai trò có ý nghĩa đối với ứng dụng đó.
Tài liệu về vai trò ứng dụng của Microsoft giải thích rằng vai trò ứng dụng có thể được gán cho người dùng hoặc nhóm. Khi người dùng được gán đăng nhập, Entra có thể đưa các vai trò được cấp vào một roles claim. Microsoft cũng cho biết vai trò ứng dụng và nhóm không loại trừ lẫn nhau.
Điều này mang lại hai mẫu chính cho thiết kế truy cập Odoo:
- Ánh xạ trực tiếp Object ID của nhóm bảo mật Entra ổn định tới các nhóm Odoo đã chọn.
- Định nghĩa các vai trò ứng dụng tập trung vào Odoo trong ứng dụng Entra, gán người dùng hoặc nhóm vào các vai trò đó, rồi ánh xạ các giá trị vai trò kết quả vào nhóm Odoo.
Ánh xạ trực tiếp phù hợp với các nhóm bảo mật đã được quản trị. Vai trò ứng dụng có thể cung cấp một ranh giới ứng dụng rõ ràng hơn vì ý định của chúng đi cùng app registration thay vì phụ thuộc vào tên riêng của tenant.
Bắt đầu từ mô hình truy cập thực tế của Odoo
Đừng bắt đầu bằng cách sao chép mọi nhóm Microsoft vào Odoo. Hãy bắt đầu từ các quyền Odoo mà doanh nghiệp thực sự cần.
Liệt kê các nhóm Odoo cấp quyền năng lực quan trọng. Với mỗi nhóm, ghi lại:
- Mục đích kinh doanh của quyền truy cập.
- Người chịu trách nhiệm phê duyệt.
- Nhóm Entra hoặc vai trò ứng dụng đại diện cho việc phê duyệt.
- Thay đổi nên đến Odoo nhanh đến mức nào và điều gì xảy ra với phiên đang hoạt động sau khi bị gỡ bỏ.
Hãy áp dụng nguyên tắc đặc quyền tối thiểu. Một nhóm phòng ban rộng có thể tiện, nhưng có thể cấp nhiều quyền truy cập Odoo hơn mức từng thành viên cần. Một nhóm bảo mật hoặc vai trò ứng dụng nhỏ hơn, chuyên cho Odoo, thường dễ kiểm toán hơn.
Coi việc ràng buộc danh tính là một kiểm soát bảo mật
Nhiều hệ thống ban đầu đối sánh tài khoản hiện có bằng địa chỉ email. Cách này tiện lợi, đặc biệt khi Odoo và Microsoft đã dùng cùng email công ty. Nhưng đây không phải là khóa danh tính bền vững.
Microsoft cảnh báo trong tham chiếu về claim của ID token rằng địa chỉ email, số điện thoại và user principal name có thể thay đổi và có thể được tái sử dụng. Microsoft khuyến nghị các claim bất biến như sub hoặc oid, cùng tid khi cần ngữ cảnh tenant, để nhận dạng đáng tin cậy.
Một mẫu an toàn hơn là:
- Chỉ chấp nhận tenant mong đợi và audience đã được phê duyệt.
- Dùng email cho lần đối sánh đầu tiên có kiểm soát khi phù hợp.
- Từ chối các kết quả đối sánh mơ hồ hoặc trùng lặp.
- Lưu Microsoft identity và tenant identifiers bất biến sau khi liên kết.
- Dùng các giá trị bất biến đó cho các lần đăng nhập sau.
Với truy cập đa tenant, ngữ cảnh tenant là thiết yếu. Cùng một người có thể có các object identifier khác nhau ở các tenant khác nhau, và quyền truy cập từ một tenant không nên tự động kế thừa các quyền gắn với tenant khác.
Hiểu trường hợp vượt ngưỡng của group claim
Group claim rất tiện, nhưng không phải vô hạn. Microsoft ghi nhận giới hạn 200 Object ID nhóm trong một JWT. Khi số thành viên của người dùng vượt giới hạn, Entra sẽ bỏ danh sách nhóm thông thường và trả về chỉ báo overage, chỉ ứng dụng tới Microsoft Graph. Xem hướng dẫn về group overage.
Điều này quan trọng nếu một tích hợp quảng bá ánh xạ nhóm mà không có quyền Microsoft Graph API nâng cao. Người dùng có quá nhiều nhóm có thể không nhận được bộ group claim như mong đợi.
Trước khi dựa vào ánh xạ nhóm trực tiếp, hãy xác nhận cách xử lý overage. Các lựa chọn gồm nhóm nhỏ theo ứng dụng, vai trò ứng dụng, lọc claim, hoặc tra cứu qua Graph với sự đồng ý ở mức đặc quyền tối thiểu.
Đồng bộ tại thời điểm đăng nhập không phải là cấp phát thời gian thực
Một mô-đun SSO có thể so sánh các claim Entra hiện tại với các ánh xạ Odoo đã cấu hình khi người dùng đăng nhập. Điều đó hữu ích vì quyền truy cập có thể được điều chỉnh trong một sự kiện xác thực bình thường.
Điều đó không giống với cấp phát liên tục. Nếu một nhân viên bị xóa khỏi nhóm Entra trong khi phiên Odoo vẫn đang hoạt động, phiên đó có thể tiếp tục cho đến khi đăng xuất, hết hạn hoặc một cơ chế thu hồi khác được áp dụng. Nếu một cựu nhân viên không bao giờ đăng nhập lại, quy trình đồng bộ khi đăng nhập không tự động lưu trữ tài khoản Odoo.
Microsoft Entra ID Governance cung cấp Lifecycle Workflows cho quy trình joiner, mover và leaver, bao gồm vô hiệu hóa tài khoản và gỡ bỏ các gán truy cập. Xem hướng dẫn về Lifecycle Workflows. Các khả năng này yêu cầu giấy phép Microsoft Entra ID Governance hoặc Microsoft Entra Suite.
Tự động hóa vòng đời có thể cải thiện trạng thái danh tính nguồn, nhưng vẫn không cập nhật Odoo nếu không có tích hợp tiêu thụ thay đổi đó. Quy trình offboarding của bạn nên nêu rõ việc thu hồi phiên Odoo và trạng thái tài khoản.
Xây dựng mô hình ánh xạ có thể kiểm toán
Giữ số lượng ánh xạ ở mức dễ hiểu. Với mỗi nhóm hoặc vai trò, hãy dùng một định danh ổn định và một mô tả dễ đọc. Ghi lại vì sao quyền truy cập Odoo liên quan tồn tại, ai phê duyệt và lần cuối được rà soát khi nào.
Hãy kiểm thử ít nhất các trường hợp sau:
- Người dùng hiện có với một ánh xạ được mong đợi.
- Người dùng không có ánh xạ được phê duyệt hoặc thuộc tenant không được phép.
- Người dùng mới được chấp nhận cho lần đăng nhập đầu tiên.
- Người dùng bị gỡ khỏi một nhóm đã ánh xạ hoặc có nhiều tư cách thành viên nhóm.
- Người dùng đã đổi tên nhưng danh tính bất biến của họ không thay đổi.
- Tài khoản Microsoft đã bị vô hiệu hóa với phiên Odoo hiện có.
Các sự kiện đăng nhập nên giúp quản trị viên chẩn đoán kết quả claim và ánh xạ mà không tiết lộ token, thông tin xác thực hoặc bí mật. Nhật ký nên xác định kết nối và kết quả, nhưng các giá trị nhạy cảm phải được che đi.
Kết hợp ánh xạ với chính sách xác thực
Các điều khiển ánh xạ nhóm và vai trò quản lý phân quyền Odoo. Microsoft Entra Conditional Access kiểm soát việc Microsoft có hoàn tất xác thực trong các điều kiện hiện tại hay không. Hai lớp này bổ trợ cho nhau.
Ví dụ, một vai trò ứng dụng Entra có thể ánh xạ vào nhóm tài chính Odoo, trong khi Conditional Access yêu cầu mức xác thực chống lừa đảo cho những người dùng được gán vai trò đó. Đọc cách Microsoft Entra Conditional Access tăng cường đăng nhập Odoo về phía chính sách xác thực.
Đối với khách hàng và đối tác, đừng tự động dùng lại các ánh xạ nhân viên. Một thiết kế riêng cho đối tượng và hướng cổng thông tin có thể an toàn hơn. Xem Microsoft Entra External ID cho khách hàng và đối tác Odoo.
Ánh xạ quyền truy cập Microsoft đã được phê duyệt vào Odoo 19
Mô-đun Microsoft Entra SSO for Odoo module của chúng tôi hỗ trợ ánh xạ các Object ID nhóm bảo mật Entra hoặc vai trò ứng dụng đã cấu hình sang các nhóm truy cập Odoo được chọn. Mô-đun có thể đồng bộ các ánh xạ đó khi đăng nhập, liên kết một tài khoản hiện có đã được kiểm soát, và tạo người dùng lực lượng lao động hoặc cổng thông tin đã được phê duyệt theo loại kết nối.
Mô-đun này không thay thế quản trị truy cập, thu hồi phiên hoặc chiến lược overage đã được lập tài liệu. Hãy xem xét quy mô nhóm, yêu cầu liên kết danh tính và mô hình quyền Odoo của bạn trước khi bật ánh xạ. Nếu những nền tảng đó đã rõ ràng, mô-đun sẽ cung cấp một cách thức có hướng dẫn để kết nối chúng.