Các portal Odoo cho phép khách hàng và đối tác truy cập vào tài liệu, giao dịch và dịch vụ liên quan. Điều đó đặt ra một câu hỏi về thiết kế danh tính: người dùng bên ngoài có nên dùng chung thư mục nhân viên và mô hình truy cập không?
Đôi khi tài khoản khách doanh nghiệp trong một workforce tenant là phù hợp. Ở quy mô lớn hơn, hoặc khi cần đăng nhập khách hàng có thương hiệu và đăng ký tự phục vụ, Microsoft Entra External ID cung cấp một mô hình quản lý danh tính và truy cập dành riêng cho khách hàng.
Kết nối mô hình đó với Odoo có thể hỗ trợ một ranh giới rõ ràng hơn giữa người dùng nội bộ và người dùng portal. Ranh giới này vẫn cần điều kiện tiếp nhận rõ ràng, tạo tài khoản và các quy tắc phân quyền Odoo cụ thể.
Workforce tenant và external tenant được thiết kế cho các nhóm đối tượng khác nhau
Microsoft định nghĩa workforce tenant là môi trường dành cho nhân viên, ứng dụng nội bộ và tài nguyên của tổ chức. Môi trường này cũng có thể chứa các đối tác kinh doanh và khách mời được mời. External tenant là một cấu hình riêng cho các ứng dụng phục vụ người tiêu dùng và khách hàng doanh nghiệp. Microsoft mô tả sự khác biệt này trong hướng dẫn cấu hình tenant.
Một external tenant có thư mục khách hàng và các đăng ký ứng dụng riêng. External ID bổ sung đăng ký tự phục vụ, đăng nhập, đặt lại mật khẩu, quản lý tài khoản và liên kết nhà cung cấp danh tính. Tổng quan về External ID giải thích mô hình chuyên biệt này.
Sự tách biệt này có thể giúp tổ chức tránh việc coi khách hàng như nhân viên chỉ vì cả hai đều cần truy cập vào một dịch vụ Odoo.
Chọn đối tượng trước khi cấu hình đăng nhập
Có ít nhất ba nhóm đối tượng Odoo riêng biệt cần cân nhắc:
Nhân viên và người dùng nội bộ
Những người dùng này thường thuộc workforce tenant của tổ chức. Nếu được cấp quyền vào Odoo, họ thường cần tài khoản người dùng Odoo nội bộ với các nhóm truy cập được ánh xạ cẩn thận.
Người từ các tổ chức đối tác được phê duyệt
Một số doanh nghiệp muốn người dùng từ danh sách xác định của tenant khách hàng hoặc đối tác Entra. Kết nối workforce đa tenant với danh sách cho phép tenant chính xác có thể phù hợp khi mọi tổ chức đều đã biết và quyền truy cập được chấp thuận theo hợp đồng.
Xác thực tenant là rất quan trọng. Khớp chỉ theo miền email là không đủ vì miền và địa chỉ email có thể thay đổi. Hãy xác thực tenant của token và các định danh subject hoặc object không thay đổi theo thiết kế kết nối.
Khách hàng và người dùng bên ngoài
Đối với các ứng dụng hướng tới khách hàng, một external ID tenant có thể cung cấp thư mục và trải nghiệm đăng nhập riêng. Tài khoản Odoo được tạo cho nhóm này thường nên là portal user, không phải internal user.
Các mô hình này nên được cấu hình thành các kết nối riêng biệt khi quy tắc tiếp nhận và quy tắc tài khoản Odoo của chúng khác nhau. Một kết nối chung quá rộng sẽ khó hiểu hơn và dễ cấu hình sai hơn.
External ID hỗ trợ hành trình đăng nhập cho khách hàng
Các user flow của External ID xác định phương thức xác thực khách hàng và thông tin được thu thập trong quá trình đăng ký. Một flow được liên kết với các ứng dụng đã đăng ký để kích hoạt đăng ký và đăng nhập. Microsoft ghi nhận điều này trong thêm ứng dụng vào user flow của External ID.
External ID có thể hỗ trợ tài khoản cục bộ và liên kết với các nhà cung cấp danh tính, bao gồm Microsoft Entra ID và các nhà cung cấp OpenID Connect tùy chỉnh. Các thuộc tính sẵn có và tùy chỉnh có thể được thu thập trong quá trình đăng ký, như được mô tả trong hướng dẫn về thuộc tính khách hàng của Microsoft.
Chỉ thu thập những thông tin Odoo thực sự cần, và ghi rõ mục đích, thời gian lưu giữ và cách xử lý quyền riêng tư của từng thuộc tính.
Quyền mặc định giúp duy trì sự tách biệt
Microsoft cho biết người dùng external tenant bắt đầu với quyền mặc định bị giới hạn. Họ thường có thể truy cập ứng dụng và tự quản lý hồ sơ của mình, nhưng không nhận quyền quản trị thư mục rộng. Xem quyền mặc định trong external tenant.
Ranh giới thư mục đó không tự động cấu hình quyền portal Odoo. Odoo vẫn kiểm soát những bản ghi mà portal user có thể xem thông qua quyền truy cập và record rules riêng. Hãy kiểm thử trải nghiệm portal với các bản ghi khách hàng đại diện và với hơn một công ty hoặc tài khoản để đảm bảo dữ liệu được cô lập đúng.
Không nâng một external user mới tạo thành internal Odoo user trừ khi có quy trình kinh doanh riêng đã được phê duyệt.
Sử dụng luồng OpenID Connect hiện đại và đã được xác thực
Microsoft hỗ trợ luồng cấp quyền ủy quyền OAuth 2.0 với Proof Key for Code Exchange và OpenID Connect cho các ứng dụng web phía máy chủ. tài liệu về authorization code flow của hãng mô tả tổ hợp được hỗ trợ này.
OIDC mở rộng OAuth 2.0 cho xác thực. Microsoft công bố metadata khám phá, chi tiết endpoint và public signing keys. Hãng cũng khuyến nghị xác thực token trả về và kiểm tra nonce để giảm rủi ro phát lại. Xem OpenID Connect trên Microsoft identity platform.
Một tích hợp an toàn nên xác thực issuer, audience, chữ ký, ngữ cảnh tenant và nonce dự kiến. PKCE không thay thế việc xác thực token, cấu hình callback chính xác, TLS hoặc bảo vệ client secret.
Đăng nhập cơ bản có thể yêu cầu các phạm vi OIDC tiêu chuẩn như openid, profile và email. Microsoft lưu ý rằng các phạm vi này được lưu trữ trên Microsoft Graph và khuyến nghị chỉ yêu cầu những quyền mà ứng dụng cần. Xem phạm vi Microsoft identity platform. Vì vậy, một tuyên bố sản phẩm chính xác là "không có quyền Microsoft Graph API đặc quyền cao cho đăng nhập tiêu chuẩn", thay vì khẳng định chung rằng Graph không liên quan.
Quyết định cách người dùng bên ngoài truy cập Odoo
Trước khi bật lần đăng nhập đầu tiên, hãy xác định:
- Có cho phép tự đăng ký hay yêu cầu phê duyệt.
- Những tenant hoặc nhà cung cấp danh tính nào được chấp nhận.
- Có thể liên kết với tài khoản portal Odoo hiện có hay không.
- Mã định danh Microsoft bất biến nào được lưu sau khi liên kết.
- Công ty Odoo nào và bản ghi đối tác nào mà người dùng thuộc về.
- Những nhóm portal và quy tắc bản ghi nào được áp dụng.
- Điều gì xảy ra khi quyền truy cập bị thu hồi.
- Một phiên Odoo đang hoạt động bị thu hồi như thế nào.
Tạo tài khoản tự động có thể giảm bớt công việc quản trị, nhưng chỉ nên thực hiện sau khi danh tính đáp ứng các quy tắc chấp nhận của kết nối. Xác thực Microsoft thành công chứng minh quyền kiểm soát danh tính được chấp nhận. Nó không tự nó chứng minh rằng người đó nên xem các bản ghi Odoo của một khách hàng cụ thể.
Lập kế hoạch cho hỗ trợ khách hàng và khôi phục
Người dùng bên ngoài có thể không có bộ phận hỗ trợ nội bộ. Hãy công bố một kênh hỗ trợ và xác định ai quản lý danh tính. Kiểm tra các tình huống đặt lại mật khẩu, khôi phục, xóa tenant và thay đổi email. Giữ các sự kiện chẩn đoán hữu ích nhưng đã được che bớt thông tin nhạy cảm.
Nếu nhu cầu trước mắt của bạn là quyền truy cập của nhân viên, hãy đọc vì sao bạn nên bảo vệ phiên bản Odoo của mình bằng Microsoft SSO. Đối với quyền nội bộ, xem tập trung quyền truy cập Odoo với nhóm Entra và vai trò ứng dụng.
Kết nối đối tượng bên ngoài với Odoo 19
Mô-đun Microsoft Entra SSO for Odoo module của chúng tôi hỗ trợ các kết nối riêng biệt cho nhân viên, tổ chức được phê duyệt và các đối tượng khách hàng Microsoft Entra External ID. Các kết nối External ID sẽ tạo người dùng portal theo mặc định, trong khi các kết nối lực lượng lao động sẽ tạo người dùng nội bộ. Thiết lập có hướng dẫn xác thực thông tin khám phá và khóa ký, sau đó yêu cầu một lần kiểm tra tương tác trước khi đăng nhập Microsoft được bật.
Mô-đun không quyết định ai nên được chấp nhận hoặc họ nên xem những bản ghi khách hàng nào. Những điều đó vẫn là quyết định kinh doanh và quyết định truy cập Odoo. Hãy xem mô-đun nếu bạn cần một cầu nối được kiểm soát giữa danh tính khách hàng Microsoft và một cổng Odoo 19, với việc xử lý tài khoản theo từng đối tượng thay vì một đường đăng nhập duy nhất không phân biệt.