单点登录回答的是身份验证问题：Microsoft 是否根据组织策略验证了此用户？它并不能回答 Odoo 内部的所有授权问题。
已通过身份验证的用户可能需要销售权限，但不需要会计权限；需要项目权限，但不需要薪资权限；或需要客户门户，但不需要内部界面。这些决定仍然由 Odoo 负责。Microsoft Entra 组和应用程序角色可以提供可信输入，让这些决定更一致。
组和应用角色用途不同
Microsoft Entra 组属于租户。它们可以代表部门、职能、项目或安全边界。应用程序角色属于特定的应用注册，并描述对该应用有意义的角色。
Microsoft 的 应用角色文档 说明应用角色可以分配给用户或组。已分配的用户登录时，Entra 可以在 roles 声明中包含已授予的角色。Microsoft 还指出，应用角色和组并非互斥。
这为 Odoo 访问设计提供了两种主要模式：
- 将稳定的 Entra 安全组 Object ID 直接映射到选定的 Odoo 组。
- 在 Entra 应用中定义面向 Odoo 的应用角色，将用户或组分配到这些角色，然后把得到的角色值映射到 Odoo 组。
直接映射适合受治理的安全组。应用角色可以提供更清晰的应用边界，因为它们的意图随应用注册而存在，而不依赖于租户特定名称。
从 Odoo 的实际访问模型开始
不要先把每个 Microsoft 组都复制到 Odoo。应从业务真正需要的 Odoo 权限开始。
列出授予实际能力的 Odoo 组。对每个组，记录：
- 该访问的业务目的。
- 负责批准该访问的人。
- 代表批准的 Entra 组或应用角色。
- 变更应多快反映到 Odoo，以及移除后活动会话会发生什么。
遵循最小权限原则。广泛的部门组可能很方便，但它可能授予比每位成员所需更多的 Odoo 访问。较小的、面向 Odoo 的安全组或应用角色通常更容易审计。
将身份绑定视为一种安全控制
许多系统最初会使用电子邮件地址来匹配现有账号。这很方便，尤其当 Odoo 和 Microsoft 已经使用相同的公司邮箱时。但这不是持久的身份键。
Microsoft 在其 ID token claims reference 中提醒，电子邮件地址、电话号码和用户主体名称都可能更改，也可能被重复使用。Microsoft 建议使用不可变声明，例如 sub 或 oid，并在需要租户上下文时使用 tid，以实现可靠识别。
更安全的模式是：
- 仅接纳预期的租户和已批准的受众。
- 在适当情况下，使用电子邮件进行受控的首次匹配。
- 拒绝存在歧义或重复的匹配。
- 在绑定后存储不可变的 Microsoft 身份和租户标识符。
- 未来登录时使用这些不可变值。
对于多租户访问，租户上下文至关重要。同一个人在不同租户中可能拥有不同的对象标识符，而来自一个租户的访问不应无提示地继承另一个租户的权限。
了解 group 声明超额情况
组声明很方便，但并非无限制。Microsoft 文档说明，JWT 中最多可包含 200 个组 Object ID。当用户成员身份超过该限制时，Entra 会省略常规组列表，并返回一个超额指示器，将应用程序引导至查询 Microsoft Graph。请参阅 groups overage guidance。
如果集成宣称支持组映射，但没有更高权限的 Microsoft Graph API 权限，这一点就很重要。组成员关系很多的用户可能不会收到预期的组声明集。
在依赖直接组映射之前，请确认如何处理超额情况。可选方案包括更小的、应用专用的组、应用角色、声明筛选，或者在获得最小权限同意后通过 Graph 查询。
登录时同步并不等于实时预配
SSO 模块可以在用户登录时，将当前 Entra 声明与已配置的 Odoo 映射进行比较。这很有用，因为访问可以在正常身份验证事件中得到对齐。
但这并不等同于持续预配。如果员工在 Odoo 会话仍处于活动状态时被移出 Entra 组，该会话可能会持续到注销、过期或其他撤销控制生效为止。如果前员工再也不登录，登录同步流程本身也不会归档 Odoo 账号。
Microsoft Entra ID Governance 为加入、调动和离职流程提供 Lifecycle Workflows，包括禁用账号和移除访问分配。请参阅 Microsoft 的 Lifecycle Workflows 指南。这些功能需要 Microsoft Entra ID Governance 或 Microsoft Entra Suite 许可。
生命周期自动化可以改善源身份状态，但如果没有集成消费该变更，它仍然不会更新 Odoo。你的离职流程应明确涵盖 Odoo 会话撤销和账号状态。
构建可审计的映射模型
保持映射数量易于理解。对于每个组或角色，使用稳定标识符和易读描述。记录相关 Odoo 访问存在的原因、批准人以及上次审核时间。
至少测试以下场景：
- 具有一个预期映射的现有用户。
- 没有已批准映射或来自不允许租户的用户。
- 首次登录的新用户。
- 已从映射组中移除的用户，或拥有大量组成员身份的用户。
- 重命名的用户，其不可变身份未发生变化。
- 已禁用的 Microsoft 账户，且已有一个 Odoo 会话。
登录事件应帮助管理员诊断声明和映射结果，而不暴露令牌、凭据或密钥。日志应标识连接和结果，但敏感值应被遮蔽。
将映射与身份验证策略结合
组和角色映射控制 Odoo 授权。Microsoft Entra 条件访问控制 Microsoft 是否会在当前条件下完成身份验证。这两层相辅相成。
例如，Entra 应用角色可以映射到 Odoo 财务组，而条件访问要求为分配该角色的用户提供抗钓鱼的身份验证强度。阅读 Microsoft Entra 条件访问如何增强 Odoo 登录，了解身份验证策略方面的内容。
对于客户和合作伙伴，不要自动复用员工映射。单独的受众和面向门户的设计可能更安全。参见 用于 Odoo 客户和合作伙伴的 Microsoft Entra 外部 ID。
将已批准的 Microsoft 访问映射到 Odoo 19
我们的 Odoo 的 Microsoft Entra SSO 模块支持将已配置的 Entra 安全组 Object ID 或应用角色映射到所选的 Odoo 访问组。它可以在登录时同步这些映射，关联受控的现有账户，并根据连接类型创建已批准的员工或门户用户。
该模块不能替代访问治理、会话撤销或有文档记录的超额策略。在启用映射之前，请审查组规模、身份绑定要求以及 Odoo 权限模型。如果这些基础已经明确，该模块可提供一种有指导的方式将它们连接起来。