Portal Odoo memberi pelanggan dan mitra akses ke dokumen, transaksi, dan layanan yang relevan. Ini menimbulkan pertanyaan desain identitas: apakah pengguna eksternal harus berbagi direktori karyawan dan model akses?

Terkadang akun tamu bisnis di tenant workforce sudah tepat. Pada skala yang lebih besar, atau saat dibutuhkan sign-in pelanggan bermerek dan registrasi mandiri, Microsoft Entra External ID menyediakan model manajemen identitas dan akses pelanggan yang khusus.

Menghubungkan model tersebut ke Odoo dapat mendukung batas yang lebih jelas antara pengguna internal dan pengguna portal. Namun batas itu tetap memerlukan penerimaan yang eksplisit, pembuatan akun, dan aturan otorisasi Odoo.

Tenant workforce dan external dirancang untuk audiens yang berbeda

Microsoft mendefinisikan tenant workforce sebagai lingkungan untuk karyawan, aplikasi bisnis internal, dan sumber daya organisasi. Ini juga dapat berisi mitra bisnis dan tamu yang diundang. Tenant external adalah konfigurasi terpisah untuk aplikasi yang ditawarkan kepada konsumen dan pelanggan bisnis. Microsoft menjelaskan perbedaannya dalam panduan konfigurasi tenant.

Tenant external memiliki direktori pelanggan dan registrasi aplikasi sendiri. External ID menambahkan registrasi mandiri, sign-in, reset kata sandi, pengelolaan akun, dan federasi penyedia identitas. Ikhtisar External ID menjelaskan model khusus ini.

Pemisahan ini dapat membantu organisasi menghindari perlakuan terhadap pelanggan seperti karyawan hanya karena keduanya perlu mengakses layanan Odoo.

Pilih audiens sebelum mengonfigurasi sign-in

Ada setidaknya tiga audiens Odoo yang berbeda untuk dipertimbangkan:

Karyawan dan pengguna internal

Pengguna ini biasanya berada di tenant workforce organisasi. Jika diizinkan ke Odoo, mereka umumnya memerlukan akun pengguna Odoo internal dengan grup akses yang dipetakan secara cermat.

Orang dari organisasi mitra yang disetujui

Sebagian bisnis ingin pengguna dari daftar tertentu tenant Entra pelanggan atau mitra. Koneksi workforce multi-tenant dengan allow-list tenant yang tepat dapat sesuai ketika setiap organisasi sudah dikenal dan akses disetujui secara kontraktual.

Validasi tenant sangat penting. Mencocokkan domain email saja tidak cukup karena domain dan alamat email dapat berubah. Validasi tenant token dan pengenal subject atau object yang tidak berubah sesuai desain koneksi.

Pelanggan dan pengguna eksternal

Untuk aplikasi yang berhadapan dengan pelanggan, tenant External ID dapat menyediakan direktori dan pengalaman sign-in yang terpisah. Akun Odoo yang dibuat untuk audiens ini biasanya harus berupa pengguna portal, bukan pengguna internal.

Model ini harus dikonfigurasi sebagai koneksi terpisah ketika aturan penerimaan dan akun Odoo mereka berbeda. Satu koneksi yang terlalu luas lebih sulit dipahami dan lebih mudah salah konfigurasi.

External ID mendukung alur sign-in pelanggan

Alur pengguna External ID menentukan metode autentikasi pelanggan dan informasi yang dikumpulkan selama pendaftaran. Alur ini dikaitkan dengan aplikasi yang terdaftar untuk mengaktifkan pendaftaran dan sign-in. Microsoft mendokumentasikan ini dalam menambahkan aplikasi ke alur pengguna External ID.

External ID dapat mendukung akun lokal dan federasi dengan penyedia identitas termasuk Microsoft Entra ID dan penyedia OpenID Connect kustom. Atribut bawaan dan kustom dapat dikumpulkan selama pendaftaran, seperti dijelaskan dalam panduan atribut pelanggan Microsoft.

Kumpulkan hanya informasi yang benar-benar dibutuhkan Odoo, dan dokumentasikan tujuan, retensi, serta perlakuan privasi untuk setiap atribut.

Izin default membantu menjaga pemisahan

Microsoft menyatakan bahwa pengguna external tenant memulai dengan izin default yang terbatas. Mereka umumnya dapat mengakses aplikasi dan mengelola profil mereka sendiri, tetapi tidak memperoleh hak administrasi direktori yang luas. Lihat izin default di external tenant.

Batas direktori itu tidak otomatis mengonfigurasi izin portal Odoo. Odoo tetap mengontrol rekaman mana yang dapat dilihat pengguna portal melalui hak akses dan record rule miliknya sendiri. Uji pengalaman portal dengan rekaman pelanggan representatif dan lebih dari satu perusahaan atau akun untuk memastikan data terisolasi dengan benar.

Jangan menaikkan pengguna eksternal yang baru dibuat menjadi pengguna internal Odoo kecuali ada proses bisnis terpisah yang disetujui.

Gunakan alur OpenID Connect modern yang tervalidasi

Microsoft mendukung alur otorisasi OAuth 2.0 dengan Proof Key for Code Exchange dan OpenID Connect untuk aplikasi web berbasis server. Dokumentasi alur otorisasi code flow menjelaskan kombinasi yang didukung tersebut.

OIDC memperluas OAuth 2.0 untuk autentikasi. Microsoft menerbitkan metadata discovery, detail endpoint, dan kunci penandatanganan publik. Microsoft juga merekomendasikan validasi token yang diterima dan pemeriksaan nonce untuk mengurangi risiko replay. Lihat OpenID Connect di platform identitas Microsoft.

Integrasi yang aman harus memvalidasi issuer, audience, signature, konteks tenant, dan nonce yang diharapkan. PKCE tidak menggantikan validasi token, konfigurasi callback yang tepat, TLS, atau perlindungan secret klien.

Sign-in dasar dapat meminta scope OIDC standar seperti openid, profile, dan email. Microsoft mencatat bahwa scope ini dihosting di Microsoft Graph dan merekomendasikan hanya meminta izin yang dibutuhkan aplikasi. Lihat scope platform identitas Microsoft. Maka klaim produk yang tepat adalah "tanpa izin Microsoft Graph API berhak tinggi untuk sign-in standar," bukan klaim menyeluruh bahwa Graph tidak terlibat.

Tentukan bagaimana pengguna eksternal mengakses Odoo

Sebelum mengaktifkan sign-in pertama, tentukan:

  • Apakah registrasi mandiri dibuka atau memerlukan persetujuan.
  • Tenant atau penyedia identitas mana yang diizinkan.
  • Apakah akun portal Odoo yang sudah ada dapat ditautkan.
  • Pengidentifikasi Microsoft yang tidak dapat diubah mana yang disimpan setelah ditautkan.
  • Perusahaan Odoo dan record partner mana yang menjadi milik pengguna.
  • Grup portal dan aturan record mana yang berlaku.
  • Apa yang terjadi saat akses dicabut.
  • Cara sesi Odoo yang aktif dicabut.

Pembuatan akun otomatis dapat mengurangi administrasi, tetapi sebaiknya dilakukan hanya setelah identitas memenuhi aturan penerimaan koneksi. Autentikasi Microsoft yang berhasil membuktikan kendali atas identitas yang diterima. Namun, itu sendiri tidak membuktikan bahwa orang tersebut semestinya melihat record Odoo milik pelanggan tertentu.

Rencanakan dukungan pelanggan dan pemulihan

Pengguna eksternal mungkin tidak memiliki help desk internal. Publikasikan jalur dukungan dan identifikasi siapa yang mengelola identitas. Uji pengaturan ulang kata sandi, pemulihan, penghapusan tenant, dan skenario email yang berubah. Jaga agar event diagnostik tetap berguna tetapi disamarkan.

Jika kebutuhan langsung Anda adalah akses karyawan, baca mengapa Anda harus melindungi instance Odoo Anda dengan Microsoft SSO. Untuk izin internal, lihat memusatkan akses Odoo dengan grup Entra dan peran aplikasi.

Hubungkan audiens eksternal ke Odoo 19

Module Microsoft Entra SSO for Odoo kami mendukung koneksi terpisah untuk karyawan, organisasi yang disetujui, dan audiens pelanggan Microsoft Entra External ID. Koneksi External ID secara default membuat pengguna portal, sedangkan koneksi workforce membuat pengguna internal. Penyiapan terpandu memvalidasi informasi discovery dan signing key, lalu memerlukan pengujian interaktif sebelum sign-in Microsoft diaktifkan.

Module ini tidak memutuskan siapa yang harus diterima atau record pelanggan mana yang harus mereka lihat. Hal-hal tersebut tetap menjadi keputusan bisnis dan akses Odoo. Tinjau module ini jika Anda memerlukan jembatan terkontrol antara identitas pelanggan Microsoft dan portal Odoo 19, dengan penanganan akun khusus audiens, bukan satu jalur login yang tidak dibedakan.