使用者名稱和密碼只能回答部分存取問題。企業也可能需要知道使用者是否已完成 MFA、裝置是否受管理，以及請求是否來自預期的位置。
Microsoft Entra 條件式存取將這些訊號納入原則決策。當 Odoo 使用 Microsoft Entra 作為身分識別提供者時，條件式存取可以在使用者返回 Odoo 之前先評估 Microsoft 登入。
這能讓 Odoo 驗證更一致地符合 Microsoft 管理的環境。不過，若部署不慎，也可能將合法使用者拒之門外。目標是制定一套符合 Odoo 使用者群與資料內容的審慎原則。
條件式存取實際上做什麼
Microsoft 將條件式存取描述為其 Zero Trust 原則引擎。原則運作方式如同 if-then 陳述式，當符合所定義的條件時，Entra 會套用設定的存取決策。官方 條件式存取概觀 列出常見訊號，包括使用者與群組、IP 位置、裝置、應用程式，以及即時或計算出的風險。
授與控制可要求：
- 多重要素驗證。
- 指定的驗證強度。
- 已標記為合規的裝置。
- Microsoft Entra 混合式加入的裝置。
- 已核准的用戶端應用程式或應用程式保護原則。
- 變更密碼或接受使用條款。
原則也可以封鎖存取。多個原則可能會套用到同一次登入，Microsoft 說明所有適用的原則要求都必須滿足。請參閱 條件式存取原則的評估方式。
Odoo 的實務原則模式
為具特權的 Odoo 使用者要求 MFA
Odoo 管理員、財務人員，以及可匯出敏感記錄的使用者，都是採用更強驗證的合理對象。依據 Microsoft 的 MFA 文件，Microsoft Entra MFA 需要來自不同要素類別的兩種或以上驗證方法。
不要假設每一種 MFA 方法都提供相同的保護。Microsoft 在其 驗證概觀 中建議使用抗網路釣魚選項，例如 passkeys、FIDO2 安全金鑰、Windows Hello for Business 與憑證式驗證。
一個實用的推進方式，是先要求所有員工使用者完成 MFA，接著對具特權群組要求抗網路釣魚的驗證強度。合適的順序取決於可用裝置、註冊準備度與支援能量。
要求合適的裝置
條件式存取可要求合規或混合式加入的裝置。當 Odoo 涉及不應從未受管理端點下載的財務、人事或營運資料時，這會很有用。
請用真實使用者測試這項決策。承包商、共用工作站與行動使用者，可能不符合員工筆電原則。裝置合規性也取決於相關的 Microsoft 設定與授權。
把位置當作其中一個訊號，而不是身分證明
條件式存取可以根據已定義的位置與 IP 範圍封鎖或允許存取。當組織只在有限地理區域營運，或擁有已知的企業出口位址時，這有助於降低暴露風險。
位置不是身分證明。員工會旅行，行動連線也會變動，攻擊者則可能利用允許地區內的基礎架構。請將它與強式驗證和裝置控制結合。
在已授權的情況下套用風險型原則
Microsoft Entra ID Protection 可以將使用者風險與登入風險提供給條件式存取。Microsoft 表示，風險型條件式存取需要 Entra ID P2。這可支援對高風險登入採取更嚴格的回應，但此功能並非所有 Entra 授權都包含。
條件式存取會在權杖發行期間評估可用訊號。它不會檢查使用者稍後在 Odoo 內執行的每一項動作。
條件式存取與 Odoo 工作階段邊界
條件式存取在 Microsoft 驗證與權杖發行期間發揮作用。Odoo 驗證結果並建立自身工作階段之後，Odoo 的工作階段行為仍然很重要。
例如，將使用者從目標群組中移除，不會回溯變更已發行的權杖。Microsoft 的 原則文件 指出，當新的權杖發行時，新加入的角色或群組成員會受到原則約束。同樣地，在登入時同步 Odoo 群組的整合，不一定會立即撤銷現有的 Odoo 工作階段。
因此，您的設計應涵蓋：
- Odoo 工作階段存續時間與登出行為。
- Odoo 存取對應更新的速度。
- 緊急撤銷程序。
- 停用 Microsoft 帳戶的影響。
- 是否適合僅使用 Microsoft 的互動式登入。
- 在身分識別提供者故障時，管理員如何重新取得存取權。
在強制執行原則前先規劃部署
Microsoft 的 條件式存取部署指南 建議先規劃、使用測試使用者、溝通變更，並確保使用者在強制執行前能夠註冊 MFA。
對於 Odoo 上線，實務上的順序是：
- 註冊 Odoo 連線，並驗證其回呼、探索資訊與簽署金鑰。
- 使用非管理員帳戶測試 Microsoft 登入。
- 確認 Odoo 帳戶比對與存取群組結果。
- 以預期的 Conditional Access 原則，鎖定一小組試點使用者。
- 檢視登入記錄與支援回饋。
- 逐步擴大適用對象。
- 只有在已記錄並測試緊急存取之後，才啟用僅限 Microsoft 的互動式登入。
避免廣泛排除。請使用最小必要例外，記錄其擁有者，並設定檢視日期。
了解授權界線
Conditional Access 需要 Microsoft Entra ID P1。Microsoft 365 Business Premium 也包含 Conditional Access 功能。以風險為基礎的 Conditional Access 需要 Entra ID P2。其他控制項可能依賴個別產品，包括 Microsoft Intune 或 Defender for Cloud Apps。最新詳細資訊維護於 Conditional Access 授權需求。
沒有 P1 或 P2 的組織可以使用 Microsoft 的安全性預設值作為基本安全基準，但 Microsoft 建議安全性預設值與 Conditional Access 不應合併使用。在確認授權與租用戶設定之前，不要以某項功能作為 Odoo 存取方案的基礎。
將原則與 Odoo 授權連結
Conditional Access 決定 Microsoft 是否會完成登入。Odoo 群組決定使用者進入 Odoo 後會發生什麼事。謹慎連結這兩層可建立更清晰的模型：Entra 控制驗證條件，而核准的群組或應用程式角色會對應到特定的 Odoo 存取。
請閱讀 使用 Microsoft Entra 群組與應用程式角色集中管理 Odoo 存取，了解授權層面。如果您仍在判斷 SSO 是否值得導入，請先看 為何應使用 Microsoft SSO 保護您的 Odoo 執行個體。
將 Microsoft 登入控制套用至 Odoo 19
我們的 Microsoft Entra SSO for Odoo 模組 提供引導式的 Odoo 19 連線至 Microsoft Entra ID 或 External ID。它會驗證 Microsoft 探索資訊與簽署金鑰，支援互動式登入測試，並且在連線經過驗證後，可要求互動式使用者使用 Microsoft 登入。
此模組可啟用連線，但不會自動建立正確的 Conditional Access 原則，也不會免除測試 Odoo 工作階段與權限的需要。如果您想要透過現有 Entra 原則來控管 Odoo 登入，這個模組可作為受控的整合點。