如何将基于Windows Identity Framework的自定义认证服务从ACS迁移至Azure AD/B2C？

当然可以用Azure AD或者Azure AD B2C来替代即将停用的ACS！这俩都是微软当前主推的身份管理解决方案，不仅能覆盖ACS的核心功能，还能提供更多扩展能力来适配你的场景。下面给你拆解具体的迁移思路和最佳实践：

一、先选对目标服务：Azure AD vs Azure AD B2C #

先根据你的业务场景做选择：

• 如果你的依赖方都是企业内部应用，或者面向企业客户（B2B协作场景），Azure AD是更合适的选择——它主打企业级身份管理，天然支持自定义身份提供商（包括你基于WIF开发的服务）。
• 如果你的应用面向外部消费者（B2C场景），或者需要同时支持多种社交身份源+自定义认证服务，Azure AD B2C会更灵活，它专门针对客户身份访问管理（CIAM），定制化能力更强。

二、Azure AD迁移核心步骤 #

1. 把你的WIF自定义认证服务注册为Azure AD身份提供商 #

Azure AD支持SAML 2.0、WS-Federation（WIF常用协议）等标准协议，你只需要做适配配置：

• 如果你的WIF服务已经支持SAML 2.0，直接在Azure AD的身份提供商菜单下添加一个SAML类型的身份提供商，配置元数据URL（或者手动输入实体ID、单点登录地址等核心参数）。
• 如果是基于WS-Federation，Azure AD同样支持该协议的身份提供商集成，提供你的WIF服务的元数据端点即可完成配置。

2. 迁移依赖方应用配置 #

原来在ACS中配置的依赖方，现在要迁移到Azure AD中：

• 为每个依赖方在Azure AD中创建应用注册或企业应用（根据应用类型选择，比如Web应用选应用注册，传统应用选企业应用）。
• 为这些应用配置身份验证流程，指定使用你刚才注册的WIF自定义身份提供商作为登录选项。
• 更新依赖方应用的配置文件，把原来指向ACS的身份验证端点替换成Azure AD的对应端点（比如OpenID Connect的/authorize端点，或者SAML的断言消费端点）。

3. 验证与调试 #

• 模拟用户登录流程，验证从依赖方跳转至你的WIF服务完成认证后，能成功回到应用并获取有效的身份令牌。
• 检查令牌中的声明是否符合依赖方的业务需求，必要时在Azure AD中配置声明映射规则，调整令牌输出的声明格式和内容。

三、Azure AD B2C迁移要点 #

如果选B2C，核心逻辑和Azure AD类似，但有一些B2C特有的配置细节：

• 优先使用自定义策略（User Flow适合基础场景，但自定义策略更适配复杂的自定义身份提供商集成），在策略中添加你的WIF服务作为Claims Provider，配置对应的协议（SAML或WS-Fed）和元数据信息。
• 为依赖方应用在B2C租户中注册，并关联对应的自定义策略或User Flow。
• B2C支持高度定制的登录页面和用户体验，你可以根据需要调整认证流程的UI、令牌声明等。

四、迁移最佳实践 #

• 小步迭代迁移：不要一次性切换所有依赖方，先选一个非核心的应用做试点，验证流程没问题后再批量迁移，降低风险。
• 保留过渡兼容层：如果部分依赖方暂时无法修改配置，可以考虑在Azure AD/B2C和原WIF服务之间做一层轻量适配，确保平滑过渡。
• 开启日志监控：打开Azure AD/B2C的登录日志和审核日志，跟踪身份验证请求，及时排查迁移过程中的报错或异常。
• 更新内部文档：把新的身份验证流程、配置步骤和注意事项整理成文档，方便团队后续维护。

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