Odoo thường lưu trữ những thông tin quan trọng trên toàn bộ tổ chức: hồ sơ khách hàng, hoạt động bán hàng, hóa đơn, thông tin nhân viên, dự án, tồn kho và các tài liệu vận hành. Việc truy cập những thông tin này xứng đáng được quan tâm như truy cập email, tệp tin và các hệ thống kinh doanh cốt lõi khác.
Tuy nhiên, Odoo có thể trở thành một ốc đảo danh tính. Nhân viên có thể dùng một mật khẩu cho Microsoft 365 và một mật khẩu khác cho Odoo. Quản trị viên có thể phải quản lý quyền truy cập ở những nơi riêng biệt. Khi ai đó đổi vai trò hoặc rời khỏi doanh nghiệp, quy trình có thể phụ thuộc vào việc một danh sách kiểm tra được hoàn thành đúng trong từng ứng dụng.
Microsoft single sign-on mang đến cho tổ chức thêm một lựa chọn. Bằng cách kết nối Odoo với Microsoft Entra ID, người dùng có thể xác thực qua tài khoản Microsoft của mình và doanh nghiệp có thể áp dụng các kiểm soát danh tính Microsoft đã thiết lập cho hành trình đăng nhập Odoo.
Nền tảng danh tính Microsoft của bạn có thể đã tồn tại
Nếu tổ chức của bạn dùng Microsoft 365, thì thông thường đã có sẵn một tenant lực lượng lao động Microsoft Entra. Microsoft giải thích rằng một workforce tenant được tạo cho nhân viên, ứng dụng nội bộ và tài nguyên của tổ chức khi một doanh nghiệp đăng ký dịch vụ đám mây Microsoft như Microsoft 365. Điều đó khiến Entra trở thành một nhà cung cấp danh tính tự nhiên để cân nhắc cho Odoo, thay vì đưa vào một hệ thống tài khoản độc lập khác. Xem giải thích của Microsoft về cấu hình tenant cho lực lượng lao động và bên ngoài.
Odoo cũng nhận diện trường hợp sử dụng này. Tài liệu chính thức về đăng nhập Microsoft Azure của Odoo 19 mô tả cách người dùng Odoo có thể đăng nhập bằng tài khoản Microsoft. Tài liệu cũng nêu rõ rằng cần cấu hình ở cả hai phía của tích hợp.
Lợi ích lớn hơn là Microsoft trở thành nơi tổ chức có thể áp dụng chính sách xác thực trước khi một phiên Odoo bắt đầu.
Bổ sung xác thực mạnh hơn cho đường dẫn đăng nhập Odoo
Xác thực đa yếu tố Microsoft Entra có thể yêu cầu hai hoặc nhiều hình thức xác minh. Các yếu tố này có thể bao gồm thứ người dùng biết, thứ họ sở hữu, hoặc thứ họ là. Microsoft mô tả cách thử thách được xử lý như một phần của quy trình đăng nhập Entra trong tổng quan MFA.
Khi Odoo ủy quyền đăng nhập cho Entra, tổ chức có thể yêu cầu một phương thức MFA đã được phê duyệt. Tổ chức cũng có thể chuyển một số người dùng sang các phương thức kháng lừa đảo như passkey, khóa bảo mật FIDO2, Windows Hello for Business hoặc xác thực dựa trên chứng chỉ. Microsoft khuyến nghị các phương thức này trong hướng dẫn xác thực.
Sự khác biệt này rất quan trọng. MFA truyền thống nói chung mạnh hơn quyền truy cập chỉ dùng mật khẩu, nhưng không phải mọi phương thức MFA đều kháng lừa đảo. NIST nêu rằng mật khẩu không có khả năng kháng lừa đảo và các mã một lần được nhập thủ công cũng không kháng lừa đảo vì kẻ tấn công có thể chuyển tiếp chúng. NIST xác định WebAuthn, được dùng bởi các trình xác thực FIDO2, là một ví dụ về khả năng kháng lừa đảo thông qua ràng buộc tên miền. Chi tiết có trong NIST SP 800-63B-4.
Tích hợp SSO mang đến cho doanh nghiệp một lộ trình để sử dụng các khả năng của Entra cho Odoo. Doanh nghiệp vẫn phải bật và thực thi các chính sách phù hợp.
Đưa ra quyết định truy cập với nhiều ngữ cảnh hơn
Microsoft Entra Conditional Access có thể đánh giá các tín hiệu như người dùng, nhóm, ứng dụng, vị trí, trạng thái thiết bị và rủi ro đăng nhập. Sau đó, nó có thể chặn quyền truy cập hoặc yêu cầu các biện pháp kiểm soát bao gồm MFA, một mức độ xác thực cụ thể hoặc một thiết bị tuân thủ. Microsoft gọi Conditional Access là công cụ chính sách Zero Trust của mình và ghi lại các tín hiệu cùng quyết định có sẵn trong tổng quan về Conditional Access.
Đối với một triển khai Odoo, điều này có thể hỗ trợ các chính sách như:
- Yêu cầu MFA cho quản trị viên Odoo và người dùng tài chính.
- Yêu cầu mức độ xác thực kháng lừa đảo cho các vai trò đặc quyền.
- Chặn đăng nhập Odoo từ các vị trí mà doanh nghiệp không phục vụ.
- Yêu cầu một thiết bị tuân thủ hoặc được quản lý cho quyền truy cập nội bộ nhạy cảm.
- Áp dụng chính sách nghiêm ngặt hơn cho các lần đăng nhập bên ngoài hoặc có rủi ro cao hơn.
Đây là các ví dụ, không phải cài đặt áp dụng chung cho mọi trường hợp. Một chính sách phù hợp với đội tài chính nội bộ có thể không phù hợp với cổng khách hàng. Hãy đọc cách Conditional Access tăng cường đăng nhập Odoo trước khi chọn biện pháp kiểm soát.
Conditional Access cũng có yêu cầu cấp phép. Microsoft Entra ID P1 được yêu cầu cho Conditional Access, trong khi các chính sách dựa trên rủi ro cần P2. Microsoft 365 Business Premium bao gồm các khả năng Conditional Access. Việc cấp phép và tình trạng sẵn có của các tính năng hiện tại nên được kiểm tra theo tài liệu chính thức của Microsoft.
Đưa danh tính và quyền truy cập Odoo lại gần nhau hơn
Xác thực trả lời câu hỏi người dùng là ai. Phân quyền trong Odoo vẫn quyết định người dùng đó có thể làm gì.
Một tích hợp được thiết kế tốt có thể ánh xạ một danh tính Microsoft đã được phê duyệt với một tài khoản Odoo hiện có, tạo tài khoản đã được phê duyệt ở lần đăng nhập đầu tiên, và ánh xạ các nhóm Entra hoặc vai trò ứng dụng được chọn sang các nhóm truy cập Odoo. Điều này có thể giảm việc quản trị trùng lặp và giúp việc rà soát quyết định truy cập dễ dàng hơn.
Điều quan trọng là phải giữ ranh giới giữa danh tính và phân quyền. Việc loại ai đó khỏi một nhóm Entra nên ảnh hưởng đến ánh xạ Odoo theo hành vi đồng bộ được tài liệu hóa của tích hợp, nhưng không nhất thiết chấm dứt ngay một phiên Odoo đang tồn tại. Nếu quyền truy cập được đồng bộ khi đăng nhập, thay đổi sẽ có hiệu lực khi người dùng đăng nhập lại, trừ khi một cơ chế kiểm soát phiên khác can thiệp.
Ghép khớp email cũng cần thận trọng. Microsoft cảnh báo rằng địa chỉ email và user principal name có thể thay đổi hoặc được dùng lại. Hướng dẫn về claim của ID token khuyến nghị dùng các định danh bất biến như sub hoặc oid, kèm ngữ cảnh tenant khi cần, để có danh tính bền vững. Email có thể hữu ích trong lần liên kết đầu tiên được kiểm soát, nhưng không nên là khóa danh tính lâu dài.
Để có thiết kế truy cập sâu hơn, hãy đọc tập trung hóa quyền truy cập Odoo với các nhóm và vai trò ứng dụng Entra.
Microsoft SSO không thay thế điều gì
Microsoft SSO không thay thế các bản cập nhật Odoo, vai trò đặc quyền tối thiểu, quy tắc bản ghi, lưu trữ an toàn, sao lưu, giám sát, kiểm soát phiên hay ứng phó sự cố. Tài liệu chính thức của Odoo cũng cảnh báo các cơ sở dữ liệu được lưu trữ trên Odoo.com không nên dùng luồng OAuth được tài liệu hóa của nó cho chủ sở hữu hoặc quản trị viên cơ sở dữ liệu vì việc quản lý cổng có thể bị ảnh hưởng. Hãy xác nhận chủ sở hữu và quyền quản trị khẩn cấp trước khi triển khai.
Một cách an toàn hơn để giới thiệu đăng nhập Microsoft
Bắt đầu với một nhóm thử nghiệm nhỏ. Xác thực metadata khám phá và các khóa ký của Microsoft, xác nhận URL callback, kiểm tra việc đối sánh tài khoản và xem kết quả cho người dùng mới và người dùng không được ủy quyền. Giữ một đường dẫn quản trị khẩn cấp cho đến khi quy trình được kiểm thử đầu cuối.
Sau đó, ghi lại các chính sách áp dụng cho Odoo, các giấy phép Entra mà họ cần, cách thay đổi nhóm hoặc vai trò được chuyển đến Odoo, và cách bộ phận hỗ trợ sẽ phản hồi nếu đăng nhập Microsoft không khả dụng. Nếu khách hàng và đối tác cần quyền truy cập, hãy cân nhắc một thiết kế danh tính khách hàng riêng thay vì xem họ là nhân viên. Hướng dẫn của chúng tôi về Microsoft Entra External ID for Odoo customers and partners giải thích sự khác biệt đó.
Đưa Microsoft SSO được hướng dẫn đến Odoo 19
Mô-đun Microsoft Entra SSO for Odoo module của chúng tôi cung cấp một kết nối có hướng dẫn cho Odoo 19, bao gồm đối tượng nhân viên và đối tượng bên ngoài, đăng nhập đầu tiên được kiểm soát, ánh xạ nhóm và vai trò ứng dụng, kiểm thử đăng nhập, và đăng nhập tương tác chỉ với Microsoft sau khi xác thực. Nó sử dụng luồng mã ủy quyền OpenID Connect với PKCE.
Mô-đun này không thay thế chính sách bảo mật của bạn. Tổ chức của bạn vẫn chịu trách nhiệm về cấu hình Entra, thiết kế quyền truy cập Odoo và triển khai.