Odooには、組織全体に関わる重要な情報が含まれることがよくあります。顧客記録、販売活動、請求書、従業員情報、プロジェクト、在庫、運用文書などです。こうした情報へのアクセスは、メール、ファイル、その他の基幹業務システムへのアクセスと同じレベルで注意を払う必要があります。
しかし、OdooがIDの孤立した存在になることがあります。社員はMicrosoft 365用のパスワードとは別に、Odoo用のパスワードを持つことがあります。管理者は、アクセスを別々の場所で管理しなければならない場合があります。誰かが異動したり退職したりすると、すべてのアプリケーションでチェックリストが正しく完了していることが前提になることがあります。
Microsoftのシングルサインオンには、別の選択肢があります。OdooをMicrosoft Entra IDに接続することで、ユーザーはMicrosoftアカウントで認証でき、組織は既存のMicrosoftのID管理をOdooのサインインにも適用できます。
MicrosoftのID基盤は、すでに存在しているかもしれません
組織がMicrosoft 365を使っている場合、通常はすでにMicrosoft Entraのワークフォーステナントを持っています。Microsoftによると、ワークフォーステナントは、企業がMicrosoft 365のようなMicrosoftクラウドサービスに登録すると、従業員、社内アプリケーション、組織リソース向けに作成されます。これにより、EntraはOdooに対して検討すべき自然なIDプロバイダーになります。別の独立したアカウントシステムを追加する必要はありません。Microsoftによるworkforce and external tenant configurationsの説明も参照してください。
Odooもこのユースケースを認識しています。公式のOdoo 19 Microsoft Azure sign-in documentationでは、OdooユーザーがMicrosoftアカウントでサインインする方法を説明しています。また、統合の両側で設定が必要であることも明記しています。
より大きな利点は、Odooのセッションが始まる前に、Microsoftが組織の認証ポリシーを適用する場になることです。
Odooのサインイン経路に強力な認証を追加する
Microsoft Entraの多要素認証では、2つ以上の確認方法を求めることができます。これらの要素には、ユーザーが知っているもの、所有しているもの、本人そのものであることを示すものが含まれます。Microsoftは、このチャレンジがEntraのサインインプロセスの一部としてどのように処理されるかを、MFA overviewで説明しています。
OdooがサインインをEntraに委任すると、組織は承認済みのMFA方式を必須にできます。また、パスキー、FIDO2セキュリティキー、Windows Hello for Business、証明書ベース認証など、フィッシング耐性のある方法へ特定のユーザーを移行させることもできます。Microsoftは、これらの方法をauthentication guidanceで推奨しています。
ここでの違いは重要です。従来のMFAは、通常、パスワードのみのアクセスよりも強力ですが、すべてのMFA方式がフィッシング耐性を持つわけではありません。NISTは、パスワードはフィッシング耐性がなく、手入力のワンタイムコードも攻撃者が中継できるためフィッシング耐性がないと述べています。NISTは、FIDO2認証器で使われるWebAuthnを、ドメインバインディングによるフィッシング耐性の例として挙げています。詳細はNIST SP 800-63B-4にあります。
SSO統合により、組織はEntraの機能をOdooにも適用する道を得られます。ただし、適切なポリシーを有効化し、適用するのは引き続き組織側の責任です。
より多くの文脈でアクセスを判断する
Microsoft Entra Conditional Accessは、ユーザー、グループ、アプリケーション、場所、デバイスの状態、サインインリスクなどのシグナルを評価できます。そのうえで、アクセスをブロックしたり、MFA、特定の認証強度、準拠済みデバイスなどの制御を要求したりできます。MicrosoftはConditional AccessをZero Trustのポリシーエンジンと呼び、利用可能なシグナルと判断をConditional Access overviewで説明しています。
Odooの導入では、次のようなポリシーを支援できます。
- Odooの管理者と経理ユーザーにMFAを必須にする。
- 権限の高い役割には、フィッシング耐性のある認証強度を要求する。
- 組織が対応していない場所からのOdooサインインをブロックする。
- 機密性の高い社内アクセスには、準拠済みまたは管理対象のデバイスを必須にする。
- 外部からのサインインや高リスクのサインインには、より厳格なポリシーを適用する。
これらは例であり、すべてに共通する設定ではありません。社内の経理チームに適したポリシーが、顧客ポータルには不適切な場合があります。制御を選ぶ前に、how Conditional Access strengthens Odoo sign-inを読んでください。
Conditional Accessにはライセンス要件もあります。Conditional AccessにはMicrosoft Entra ID P1が必要であり、リスクベースのポリシーにはP2が必要です。Microsoft 365 Business PremiumにはConditional Accessの機能が含まれます。ライセンスと現在の機能の提供状況は、Microsoft's official documentationで確認してください。
IDとOdooアクセスをより近づける
認証は、そのユーザーが誰であるかを示します。Odooの認可は、そのユーザーに何ができるかを決めます。
適切に設計された統合では、承認済みのMicrosoft IDを既存のOdooアカウントに対応付け、初回サインイン時に承認済みアカウントを作成し、選択したEntraグループやアプリケーションロールをOdooのアクセスグループにマッピングできます。これにより、重複する管理作業を減らし、アクセス判断を確認しやすくできます。
IDと認可の境界を保つことが重要です。Entraグループから誰かを削除すると、その統合のドキュメント化された同期動作に従ってOdooのマッピングに反映されますが、既存のOdooセッションが直ちに終了するとは限りません。アクセスがサインイン時に同期される場合、別のセッション制御が介入しない限り、変更はユーザーが再度サインインしたときに有効になります。
メールアドレスの照合にも注意が必要です。Microsoftは、メールアドレスとUser Principal Nameは変更されたり再利用されたりする可能性があると警告しています。ID token claims guidanceでは、永続的なIDには、必要に応じてテナントの文脈とともに、subやoidのような不変の識別子を推奨しています。メールアドレスは、制御された初回リンク時には有用ですが、恒久的なIDキーにすべきではありません。
より深いアクセス設計については、centralising Odoo access with Entra groups and app rolesを読んでください。
Microsoft SSOが置き換えないもの
Microsoft SSOは、Odooの更新、最小権限のロール、レコードルール、セキュアホスティング、バックアップ、監視、セッション制御、インシデント対応を置き換えるものではありません。公式のOdooドキュメントでも、Odoo.comでホストされているデータベースに対して、データベース所有者または管理者にその文書化されたOAuthフローを使用しないよう警告しています。これはポータル管理に影響する可能性があるためです。展開前に、所有者と緊急時の管理方法を確認してください。
Microsoftサインインを導入するより安全な方法
小規模なテストグループから始めてください。Microsoft のディスカバリーメタデータと署名キーを検証し、コールバック URL を確認し、アカウント照合をテストし、新規ユーザーと未承認ユーザーの結果を確認します。フローをエンドツーエンドでテストするまでは、緊急時の管理パスを維持してください。
次に、Odoo に適用されるポリシー、必要な Entra ライセンス、グループまたはロールの変更が Odoo に反映される方法、そして Microsoft サインインが利用できない場合のサポート対応を文書化します。顧客やパートナーにアクセスが必要な場合は、従業員として扱うのではなく、別の顧客アイデンティティ設計を検討してください。私たちのガイドMicrosoft Entra External ID for Odoo customers and partnersでは、その違いを説明しています。
Odoo 19 にガイド付き Microsoft SSO を導入
私たちのMicrosoft Entra SSO for Odoo moduleは、Odoo 19 向けのガイド付き接続を提供します。これには、社内ユーザーと外部ユーザー、制御された初回サインイン、グループとアプリロールのマッピング、サインインテスト、検証後の Microsoft 専用対話型ログインが含まれます。OpenID Connect の authorization code flow with PKCE を使用します。
このモジュールはセキュリティポリシーを決定しません。Entra の設定、Odoo のアクセス設計、展開については、引き続きお客様の組織が責任を負います。