能否将客户Active Directory联邦至SaaS应用实现SSO？我的理解是否正确？

1. 能否像对接Google、GitHub那样集成AD？ #

可以，但和Google/GitHub这类公共身份提供商（IDP）有本质区别：Google/GitHub是面向公众的统一IDP，而Active Directory是企业私有用户身份源，原生AD本身不直接支持SAML 2.0或OIDC这类SSO协议对接外部SaaS。你需要借助微软的AD FS（Active Directory Federation Services）或者Azure AD作为中间层，把AD的身份数据通过标准SSO协议暴露出来，这样才能完成类同公共IDP的集成流程。

2. 每个企业需将专属AD实例注册为SAML IDP的理解是否正确？ #

完全正确。每个企业的AD都是独立隔离的用户池，数据仅归该企业所有，无法通过一个公共IDP访问所有企业的AD用户。因此你的SaaS必须支持多IDP配置，让每个客户企业将自己的AD对应的联邦服务实例（AD FS或Azure AD租户）注册为你的SaaS的专属SAML IDP，实现各自的用户身份验证。

3. 如何对接外部企业的AD？ #

对接外部企业AD的核心是让你的SaaS成为支持多租户的服务提供商（SP），并引导客户完成他们侧的IDP配置，具体步骤如下：

• 你的SaaS需实现SAML 2.0（或OIDC）SP功能，支持动态添加、存储多个IDP的配置信息（包括IDP实体ID、SAML断言消费服务（ACS）URL、IDP签名证书、属性映射规则等）。
• 给客户提供清晰的对接指南：
  • 若客户使用本地AD，需部署AD FS服务器，在AD FS中创建你的SaaS应用的信赖方信任，配置断言规则（确保传递用户唯一标识（如UPN）、邮箱、姓名等必要属性）。
  • 若客户使用Azure AD，只需在Azure AD租户中添加你的SaaS应用为企业应用，配置单一登录并设置属性映射。
• 交换元数据：你向客户提供你的SP元数据（包含实体ID、ACS URL、SP证书），客户向你提供他们IDP的元数据文件或URL，双方完成信任关系的配置。
• 测试与验证：客户企业用户访问你的SaaS登录页，选择AD SSO登录选项，会被重定向到客户自己的AD FS/Azure AD登录页面，验证通过后携带SAML断言跳转回你的应用，完成身份认证。

关键注意事项 #

• 用户唯一标识：确保IDP传递的用户标识（如UPN）在你的SaaS中是全局唯一的，可通过添加租户ID前缀等方式避免跨企业用户冲突。
• 证书管理：提醒客户定期轮换IDP签名证书，并及时在你的SaaS中更新，避免认证失败。
• 错误排查：提供详细的日志记录，方便排查断言验证失败、属性缺失等常见问题。

内容的提问来源于stack exchange，提问作者Lewis Ayers