Odoo sering menyimpan informasi yang penting di seluruh organisasi: data pelanggan, aktivitas penjualan, faktur, detail karyawan, proyek, inventaris, dan dokumen operasional. Akses ke informasi itu layak mendapat perhatian yang sama seperti akses ke email, file, dan sistem bisnis inti lainnya.

Namun Odoo dapat menjadi pulau identitas. Staf mungkin memiliki satu kata sandi untuk Microsoft 365 dan satu lagi untuk Odoo. Administrator mungkin perlu mengelola akses di tempat yang terpisah. Saat seseorang berganti peran atau meninggalkan perusahaan, prosesnya dapat bergantung pada daftar periksa yang harus diselesaikan dengan benar di setiap aplikasi.

Microsoft single sign-on memberi organisasi opsi lain. Dengan menghubungkan Odoo ke Microsoft Entra ID, pengguna dapat autentikasi melalui akun Microsoft mereka dan bisnis dapat menerapkan kontrol identitas Microsoft yang sudah ada ke alur masuk Odoo.

Fondasi identitas Microsoft Anda mungkin sudah ada

Jika organisasi Anda menggunakan Microsoft 365, biasanya Anda sudah memiliki tenant Microsoft Entra workforce. Microsoft menjelaskan bahwa tenant workforce dibuat untuk karyawan, aplikasi internal, dan sumber daya organisasi ketika sebuah bisnis mendaftar ke layanan cloud Microsoft seperti Microsoft 365. Hal ini menjadikan Entra penyedia identitas yang wajar untuk dipertimbangkan bagi Odoo, alih-alih memperkenalkan sistem akun mandiri lain. Lihat penjelasan Microsoft tentang konfigurasi tenant workforce dan eksternal.

Odoo juga mengenali use case ini. Dokumentasi resmi login Microsoft Azure Odoo 19 menjelaskan bagaimana pengguna Odoo dapat masuk dengan akun Microsoft. Dokumentasi itu juga menegaskan bahwa konfigurasi diperlukan di kedua sisi integrasi.

Manfaat yang lebih besar adalah Microsoft menjadi titik tempat organisasi dapat menerapkan kebijakan autentikasi sebelum sesi Odoo dimulai.

Tambahkan autentikasi yang lebih kuat ke jalur masuk Odoo

Microsoft Entra multifactor authentication dapat mewajibkan dua atau lebih bentuk verifikasi. Faktor ini dapat mencakup sesuatu yang diketahui pengguna, sesuatu yang dimiliki pengguna, atau sesuatu yang merupakan dirinya. Microsoft menjelaskan bagaimana tantangan tersebut ditangani sebagai bagian dari proses masuk Entra dalam ringkasan MFA.

Saat Odoo mendelegasikan proses masuk ke Entra, organisasi dapat mewajibkan metode MFA yang disetujui. Organisasi juga dapat mengarahkan pengguna tertentu ke metode yang tahan phishing seperti passkey, kunci keamanan FIDO2, Windows Hello for Business, atau autentikasi berbasis sertifikat. Microsoft merekomendasikan metode ini dalam panduan autentikasi.

Perbedaan ini penting. MFA konvensional umumnya lebih kuat daripada akses hanya dengan kata sandi, tetapi tidak semua metode MFA tahan phishing. NIST menyatakan bahwa kata sandi tidak tahan phishing dan kode satu kali yang dimasukkan secara manual juga tidak tahan phishing karena penyerang dapat meneruskannya. NIST mengidentifikasi WebAuthn, yang digunakan oleh autentikator FIDO2, sebagai contoh ketahanan terhadap phishing melalui domain binding. Rinciannya tersedia di NIST SP 800-63B-4.

Integrasi SSO memberi bisnis jalur untuk menggunakan kemampuan Entra ini untuk Odoo. Bisnis tetap harus mengaktifkan dan menegakkan kebijakan yang sesuai.

Buat keputusan akses dengan lebih banyak konteks

Microsoft Entra Conditional Access dapat mengevaluasi sinyal seperti pengguna, grup, aplikasi, lokasi, status perangkat, dan risiko masuk. Kemudian, akses dapat diblokir atau kontrol dapat diwajibkan, termasuk MFA, kekuatan autentikasi tertentu, atau perangkat yang patuh. Microsoft menyebut Conditional Access sebagai mesin kebijakan Zero Trust dan mendokumentasikan sinyal serta keputusan yang tersedia dalam gambaran umum Conditional Access.

Untuk deployment Odoo, ini dapat mendukung kebijakan seperti:

  • Mewajibkan MFA untuk administrator Odoo dan pengguna keuangan.
  • Mewajibkan kekuatan autentikasi tahan phishing untuk peran dengan hak istimewa.
  • Memblokir masuk Odoo dari lokasi yang tidak dilayani bisnis.
  • Mewajibkan perangkat yang patuh atau terkelola untuk akses internal yang sensitif.
  • Menerapkan kebijakan yang lebih ketat untuk masuk dari luar atau yang berisiko lebih tinggi.

Ini adalah contoh, bukan pengaturan universal. Kebijakan yang sesuai untuk tim keuangan internal mungkin tidak cocok untuk portal pelanggan. Baca bagaimana Conditional Access memperkuat masuk Odoo sebelum memilih kontrol.

Conditional Access juga memiliki persyaratan lisensi. Microsoft Entra ID P1 diperlukan untuk Conditional Access, sedangkan kebijakan berbasis risiko memerlukan P2. Microsoft 365 Business Premium menyertakan kemampuan Conditional Access. Lisensi dan ketersediaan fitur terkini harus diperiksa terhadap dokumentasi resmi Microsoft.

Dekatkan identitas dan akses Odoo

Autentikasi menjawab siapa pengguna itu. Autorisasi Odoo tetap menentukan apa yang dapat dilakukan pengguna tersebut.

Integrasi yang dirancang dengan baik dapat mencocokkan identitas Microsoft yang disetujui dengan akun Odoo yang sudah ada, membuat akun yang disetujui saat login pertama, dan memetakan grup Entra atau peran aplikasi tertentu ke grup akses Odoo. Ini dapat mengurangi administrasi ganda dan membuat keputusan akses lebih mudah ditinjau.

Penting untuk menjaga batas antara identitas dan autorisasi. Menghapus seseorang dari grup Entra harus memengaruhi pemetaan Odoo sesuai perilaku sinkronisasi yang didokumentasikan oleh integrasi, tetapi hal itu tidak selalu langsung mengakhiri sesi Odoo yang sedang aktif. Jika akses disinkronkan saat masuk, perubahan berlaku saat pengguna masuk lagi kecuali ada kontrol sesi lain yang mengintervensi.

Pencocokan email juga perlu kehati-hatian. Microsoft memperingatkan bahwa alamat email dan user principal name dapat berubah atau digunakan kembali. Panduan klaim token ID merekomendasikan pengenal yang tidak dapat diubah seperti sub atau oid, dengan konteks tenant jika diperlukan, untuk identitas yang tahan lama. Email dapat berguna saat pengaitan pertama yang terkontrol, tetapi tidak boleh menjadi kunci identitas permanen.

Untuk desain akses yang lebih mendalam, baca memusatkan akses Odoo dengan grup Entra dan peran aplikasi.

Apa yang tidak digantikan oleh Microsoft SSO

Microsoft SSO tidak menggantikan pembaruan Odoo, peran least-privilege, aturan record, hosting yang aman, cadangan, pemantauan, kontrol sesi, atau respons insiden. Dokumentasi resmi Odoo juga memperingatkan basis data yang di-host Odoo.com agar tidak menggunakan alur OAuth yang didokumentasikan untuk pemilik atau administrator basis data karena pengelolaan portal dapat terdampak. Pastikan pemilik dan administrasi darurat sebelum rollout.

Cara yang lebih aman untuk memperkenalkan Microsoft sign-in

Mulailah dengan kelompok uji kecil. Validasi metadata penemuan Microsoft dan kunci penandatanganan, konfirmasi URL callback, uji pencocokan akun, dan periksa hasil untuk pengguna baru dan pengguna tidak berwenang. Pertahankan jalur administratif darurat sampai alur telah diuji ujung ke ujung.

Kemudian dokumentasikan kebijakan yang berlaku untuk Odoo, lisensi Entra yang mereka perlukan, bagaimana perubahan grup atau peran sampai ke Odoo, dan bagaimana dukungan akan merespons jika masuk Microsoft tidak tersedia. Jika pelanggan dan mitra perlu akses, pertimbangkan desain identitas pelanggan yang terpisah, bukan memperlakukan mereka sebagai karyawan. Panduan kami tentang Microsoft Entra External ID for Odoo customers and partners menjelaskan perbedaan tersebut.

Hadirkan SSO Microsoft terpandu ke Odoo 19

Modul Microsoft Entra SSO for Odoo module kami menyediakan koneksi terpandu untuk Odoo 19, termasuk tenaga kerja dan audiens eksternal, kontrol saat masuk pertama, pemetaan grup dan peran aplikasi, pengujian masuk, serta login interaktif khusus Microsoft setelah validasi. Modul ini menggunakan alur authorization code OpenID Connect dengan PKCE.

Modul ini tidak menentukan kebijakan keamanan Anda. Organisasi Anda tetap bertanggung jawab atas konfigurasi Entra, desain akses Odoo, dan penerapan.