为什么应使用 Microsoft 单点登录保护你的 Odoo 实例

Odoo 往往保存着与整个组织都相关的信息，包括客户记录、销售活动、发票、员工详情、项目、库存和运营文档。对这些信息的访问，理应像对电子邮件、文件和其他核心业务系统的访问一样受到重视。

然而，Odoo 也可能变成一个身份孤岛。员工可能对 Microsoft 365 使用一个密码，对 Odoo 使用另一个密码。管理员可能需要在不同位置管理访问权限。当某人更换岗位或离职时，相关流程可能取决于每个应用中的清单是否都正确完成。

Microsoft 单点登录为组织提供了另一种选择。通过将 Odoo 连接到 Microsoft Entra ID，用户可以通过其 Microsoft 账户进行身份验证，企业也可以把既有的 Microsoft 身份控制应用到 Odoo 登录流程中。

你的 Microsoft 身份基础设施可能已经存在

如果你的组织使用 Microsoft 365，通常已经拥有一个 Microsoft Entra 工作负载租户。Microsoft 说明，当企业注册 Microsoft 365 等 Microsoft 云服务时，会为员工、内部应用和组织资源创建工作负载租户。这使 Entra 成为考虑用于 Odoo 的自然身份提供方，而不是引入另一个独立账户系统。请参阅 Microsoft 对工作负载和外部租户配置的说明。

Odoo 也认可这一使用场景。官方的Odoo 19 Microsoft Azure 登录文档说明了 Odoo 用户如何使用 Microsoft 账户登录。它也明确指出，集成双方都需要进行配置。

更大的好处在于，Microsoft 变成了组织在 Odoo 会话开始前应用身份验证策略的地点。

为 Odoo 登录路径添加更强身份验证

Microsoft Entra 多因素身份验证可以要求两种或以上的验证方式。这些因素可以包括用户知道的内容、用户持有的内容，或用户自身的特征。Microsoft 在其MFA 概述中说明了此挑战如何作为 Entra 登录流程的一部分来处理。

当 Odoo 将登录委托给 Entra 时，组织可以要求使用经批准的 MFA 方法。它还可以推动部分用户采用抗钓鱼方法，例如通行密钥、FIDO2 安全密钥、Windows Hello for Business 或基于证书的身份验证。Microsoft 在其身份验证指导中推荐了这些方法。

这一区别很重要。传统 MFA 通常比仅密码访问更强，但并非所有 MFA 方法都能抵抗钓鱼。NIST 指出，密码不具备抗钓鱼能力，手动输入的一次性代码也不具备抗钓鱼能力，因为攻击者可以中继这些代码。NIST 将 WebAuthn 视为 FIDO2 身份验证器所使用的抗钓鱼示例，其通过域绑定实现。详细内容见NIST SP 800-63B-4。

SSO 集成为企业提供了一条将这些 Entra 能力用于 Odoo 的路径。企业仍然必须启用并强制执行适当的策略。

用更多上下文做出访问决策

Microsoft Entra 条件访问可以评估用户、组、应用、位置、设备状态和登录风险等信号。然后它可以阻止访问，或要求执行包括 MFA、特定身份验证强度或合规设备在内的控制。Microsoft 将条件访问称为其零信任策略引擎，并在条件访问概述中记录了可用的信号和决策。

对于 Odoo 部署，这可以支持以下策略：

• 要求 Odoo 管理员和财务用户使用 MFA。
• 对特权角色要求抗钓鱼的身份验证强度。
• 阻止来自企业不服务地区的 Odoo 登录。
• 对敏感的内部访问要求使用合规或受管理设备。
• 对外部或高风险登录应用更严格的策略。

这些只是示例，不是通用设置。适用于内部财务团队的策略，可能并不适合客户门户。在选择控制措施之前，请先阅读条件访问如何加强 Odoo 登录。

条件访问也有许可要求。条件访问需要 Microsoft Entra ID P1，而基于风险的策略需要 P2。Microsoft 365 Business Premium 包含条件访问能力。许可和当前功能可用性应以Microsoft 官方文档为准进行核对。

让身份与 Odoo 访问更紧密地结合

身份验证回答的是用户是谁。Odoo 授权仍然决定该用户能做什么。

设计良好的集成可以将已批准的 Microsoft 身份与现有 Odoo 账户匹配，在首次登录时创建已批准的账户，并将选定的 Entra 组或应用角色映射到 Odoo 访问组。这可以减少重复管理，并使访问决策更容易审查。

保留身份与授权之间的边界很重要。将某人从 Entra 组中移除，应根据集成文档中的同步行为影响 Odoo 映射，但这并不一定会立即终止现有的 Odoo 会话。如果访问是在登录时同步的，那么除非有其他会话控制介入，否则该变更会在用户再次登录时生效。

电子邮件匹配也需要谨慎。Microsoft 提醒，电子邮件地址和用户主体名称可能会变化或被重复使用。其ID 令牌声明指导建议使用不可变标识符，例如 sub 或 oid，并在需要时结合租户上下文，以实现持久身份。在受控的首次关联过程中，电子邮件会很有用，但不应作为永久身份键。

如需更深入的访问设计，请阅读使用 Entra 组和应用角色集中管理 Odoo 访问。

Microsoft SSO 不会替代什么

Microsoft SSO 不能替代 Odoo 更新、最小权限角色、记录规则、安全托管、备份、监控、会话控制或事件响应。官方 Odoo 文档还警告 Odoo.com 托管数据库不要将其文档中描述的 OAuth 流程用于数据库所有者或管理员，因为这可能影响门户管理。上线前，请确认所有者和紧急管理方案。

更安全地引入 Microsoft 登录的方法

先从一个小型测试组开始。验证 Microsoft 发现元数据和签名密钥，确认回调 URL，测试账户匹配，并检查新用户和未授权用户的结果。在端到端测试完成之前，保留一条紧急的管理路径。

然后记录适用于 Odoo 的策略、它们所需的 Entra 许可证、组或角色变更如何传递到 Odoo，以及如果 Microsoft 登录不可用，支持将如何响应。如果客户和合作伙伴需要访问，请考虑单独的客户身份设计，而不要将他们视为员工。我们关于面向 Odoo 客户和合作伙伴的 Microsoft Entra External ID 的指南对此区别进行了说明。

为 Odoo 19 引入引导式 Microsoft SSO

我们的 适用于 Odoo 的 Microsoft Entra SSO 模块 为 Odoo 19 提供引导式连接，包括员工和外部受众、受控的首次登录、组和应用角色映射、登录测试，以及在验证后仅使用 Microsoft 的交互式登录。它使用带 PKCE 的 OpenID Connect 授权码流程。

该模块不会替您选择安全策略。您的组织仍然负责 Entra 配置、Odoo 访问设计和部署。