シングル サインオンは認証の問いに答えます。つまり、Microsoft が組織のポリシーに従ってこのユーザーを確認したか、という点です。Odoo 内のすべての認可の問いに答えるわけではありません。
認証済みユーザーには、販売部門へのアクセスは必要でも会計は不要、プロジェクトは必要でも給与計算は不要、あるいは社外向けポータルは必要でも社内インターフェースは不要、ということがあります。これらの判断は引き続き Odoo の責任です。Microsoft Entra グループとアプリケーション ロールは、これらの判断をより一貫して行うための信頼できる入力を提供できます。
グループと app roles は異なる目的を持つ
Microsoft Entra グループはテナントに属します。部署、職務、プロジェクト、セキュリティ境界を表すことがあります。アプリケーション ロールは特定のアプリ登録に属し、そのアプリにとって意味のあるロールを表します。
Microsoft の app-role documentation では、app roles はユーザーまたはグループに割り当てられると説明されています。割り当て済みユーザーがサインインすると、Entra は付与されたロールを roles クレームに含めることができます。Microsoft はまた、app roles とグループは排他的ではないと述べています。
これにより、Odoo のアクセス設計には 2 つの主要なパターンがあります。
- 安定した Entra セキュリティ グループの Object ID を、選択した Odoo グループに直接マッピングする。
- Entra のアプリケーションで Odoo 向けの app roles を定義し、ユーザーまたはグループをそのロールに割り当て、結果の role 値を Odoo グループにマッピングする。
直接マッピングは、適切に管理されたセキュリティ グループと相性が良い方法です。app roles は、テナント固有の名前に依存するのではなく、意図がアプリ登録に付随するため、より明確なアプリケーション境界を提供できます。
Odoo の実際のアクセス モデルから始める
Microsoft のすべてのグループを Odoo にコピーすることから始めないでください。まず、ビジネスが本当に必要とする Odoo の権限から始めます。
実質的な機能を付与する Odoo グループを一覧化します。各グループについて、次を記録します。
- そのアクセスの業務上の目的。
- 承認責任者。
- 承認を表す Entra グループまたは app role。
- 変更が Odoo に反映されるまでの時間と、削除後にアクティブ セッションがどうなるか。
最小権限の原則を使います。広い部署グループは便利かもしれませんが、すべてのメンバーに必要とは限らない Odoo アクセスまで付与してしまうことがあります。より小さな Odoo 専用のセキュリティ グループや app role の方が、監査しやすいことがよくあります。
ID の紐付けはセキュリティ制御として扱う
多くのシステムは、まずメール アドレスで既存アカウントを照合します。これは便利ですが、特に Odoo と Microsoft が同じ会社メールを使っている場合に有効です。しかし、永続的な ID キーではありません。
Microsoft は ID token claims reference で、メール アドレス、電話番号、user principal names は変更される可能性があり、再利用される可能性もあると警告しています。Microsoft は、信頼できる識別には、tenant context が必要な場合は tid を併用し、sub や oid のような不変クレームを使うことを推奨しています。
より安全なパターンは次のとおりです。
- 想定されたテナントと承認済みオーディエンスのみを受け入れる。
- 適切な場合は、制御された初回照合にメールを使う。
- 曖昧または重複する照合は拒否する。
- 紐付け後に、不変の Microsoft ID とテナント識別子を保存する。
- 今後のサインインでは、それらの不変値を使う。
マルチテナント アクセスでは、テナント コンテキストが重要です。同じ人物でもテナントごとに object identifier は異なる場合があり、あるテナントからのアクセスが別のテナントに関連付けられた権限を自動的に継承してはなりません。
グループ クレームの overage ケースを理解する
グループ クレームは便利ですが、無制限ではありません。Microsoft は JWT 内の group Object ID を 200 個までと文書化しています。ユーザーのメンバーシップがその上限を超えると、Entra は通常の group list を省略し、アプリケーションに Microsoft Graph を問い合わせるよう指示する overage indicator を返します。詳細は groups overage guidance を参照してください。
これは、Microsoft Graph API の追加権限なしで group mapping をうたう統合では重要です。グループ メンバーシップが多いユーザーでは、期待どおりの group claim set が返らない可能性があります。
直接の group mapping に依存する前に、overage の処理方法を確認してください。選択肢には、より小さな app 固有のグループ、app roles、claim filtering、または最小権限の同意を使った Graph ベースの参照があります。
サインイン時の同期はリアルタイム プロビジョニングではない
SSO モジュールは、ユーザーがサインインしたときに現在の Entra クレームを構成済みの Odoo マッピングと比較できます。通常の認証イベント中にアクセスを整合させられるため、これは有用です。
しかし、継続的なプロビジョニングと同じではありません。社員が Odoo のセッションが有効なまま Entra グループから削除されても、そのセッションはログアウト、期限切れ、または別の失効制御が適用されるまで続くことがあります。退職者が再度サインインしない場合、サインイン同期の仕組み自体では Odoo アカウントはアーカイブされません。
Microsoft Entra ID Governance には、入社、異動、退職のプロセス向けの Lifecycle Workflows があり、アカウントの無効化やアクセス割り当ての削除が含まれます。Microsoft の Lifecycle Workflows guidance を参照してください。これらの機能には、Microsoft Entra ID Governance または Microsoft Entra Suite のライセンスが必要です。
ライフサイクル自動化はソース側の ID 状態を改善できますが、変更を取り込む統合がなければ Odoo は更新されません。オフボーディング手順では、Odoo セッションの失効とアカウント状態を明示的に扱う必要があります。
監査可能なマッピング モデルを構築する
マッピング数は把握しやすく保ちます。各グループまたはロールについて、安定した識別子と人間が読める説明を使用します。関連する Odoo アクセスがなぜ存在するのか、誰が承認したのか、いつ最後に見直したのかを記録します。
少なくとも次のケースをテストします。
- 1 つの想定マッピングを持つ既存ユーザー。
- 承認済みマッピングがないユーザー、または許可されていないテナントのユーザー。
- 初回サインインのために許可された新規ユーザー。
- マッピング済みグループから削除されたユーザー、または多数の group membership を持つユーザー。
- 不変IDが変更されていない名前変更済みユーザー。
- 既存の Odoo セッションを持つ無効化された Microsoft アカウント。
サインインイベントは、トークン、資格情報、またはシークレットを公開せずに、管理者がクレームとマッピングの結果を診断できるようにする必要があります。ログは接続と結果を識別すべきですが、機密値はマスクされる必要があります。
マッピングを認証ポリシーと組み合わせる
グループとロールのマッピングは Odoo の認可を制御します。Microsoft Entra 条件付きアクセスは、現在の条件下で Microsoft が認証を完了するかどうかを制御します。この 2 つの層は補完し合います。
たとえば、Entra のアプリ ロールを Odoo の会計グループにマッピングし、そのロールに割り当てられたユーザーには条件付きアクセスでフィッシング耐性のある認証強度を要求できます。Microsoft Entra 条件付きアクセスが Odoo のサインインを強化する方法を、認証ポリシー側の参考としてご覧ください。
顧客やパートナーについては、従業員のマッピングを自動的に再利用しないでください。別の対象者向けで、ポータル重視の設計のほうが安全な場合があります。詳細は Microsoft Entra External ID for Odoo customers and partners をご覧ください。
承認済みの Microsoft アクセスを Odoo 19 にマッピングする
当社の Microsoft Entra SSO for Odoo module は、設定済みの Entra セキュリティ グループの Object ID またはアプリケーション ロールを、選択した Odoo アクセス グループにマッピングすることをサポートします。サインイン時にそれらのマッピングを同期し、制御された既存アカウントをリンクし、接続タイプに応じて承認済みの従業員ユーザーまたはポータル ユーザーを作成できます。
このモジュールは、アクセス ガバナンス、セッション失効、または文書化されたオーバーエイジ戦略の代替ではありません。マッピングを有効にする前に、グループ規模、ID バインディング要件、および Odoo の権限モデルを確認してください。これらの基盤が明確であれば、このモジュールはそれらをつなぐための案内された方法を提供します。