在 Azure AD 中创建用户之前，是不是可以使用 Azure B2C 自定义策略验证来自社交身份提供商 (iDP) 的电子邮件声明？

Posted 2023-03-14

【中文标题】在 Azure AD 中创建用户之前，是不是可以使用 Azure B2C 自定义策略验证来自社交身份提供商 (iDP) 的电子邮件声明？

【英文标题】：Is it possible to validate the Email claim from Social Identity Providers (iDPs) using Azure B2C custom policy before creating a User in Azure AD?在 Azure AD 中创建用户之前，是否可以使用 Azure B2C 自定义策略验证来自社交身份提供商 (iDP) 的电子邮件声明？

【发布时间】：2020-02-05 04:22:47

【问题描述】：

场景是这样的：我们已将 Microsoft iDP 添加到我们的应用程序中。用户可以单击 Microsoft 帐户按钮并使用其 MSA 帐户进行注册\登录。

当用户注册时，我们希望根据我们的数据库验证电子邮件。如果用户的电子邮件在我们的数据库中，让他们继续注册；否则我们想阻止他们注册并显示错误消息。这将阻止在我们的 Azure B2C AD 中创建用户。

我使用了以下TechnicalProfile：

<TechnicalProfile Id="REST-ValidateEmail">
      <DisplayName>Validate Membership Email</DisplayName>
      <Protocol Name="Proprietary" 
        Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="ServiceUrl">Settings:AzureAppServiceUrl/api/User/ValidateEmail</Item>
        <Item Key="AuthenticationType">None</Item>
        <Item Key="SendClaimsIn">Body</Item>
      </Metadata>
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" 
          PartnerClaimType="UserEmail" />
      </InputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
</TechnicalProfile>

然后将REST-ValidateEmail 添加到LocalAccountSignUpWithLogonEmail 作为验证技术配置文件。

<ClaimsProvider>
      <DisplayName>Local Account</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
          <Metadata>
            <!--Demo: disable the email validation in development environment-->
            <!--Demo action required: remove in production environment-->
            <Item Key="EnforceEmailVerification">False</Item>
          </Metadata>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="extension_MembershipEmail" 
              PartnerClaimType="UserEmail" />
          </OutputClaims>
          <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="REST-ValidateEmail" />
            <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
          </ValidationTechnicalProfiles>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>

向自定义策略添加了 Application Insights 调试。我看到 UserJourney(s) 正在 Azure 门户中登录。但是，无论我做什么，我都看不到来自我编写的 REST API 验证方法的 trace 日志，也看不到对 REST-ValidateEmail 的调用。看起来它根本没有被调用。

来自this comment：

这个从我的自定义策略调用外部 API 的技巧不起作用 因为我们无法拦截来自社交媒体的登录\注册电话。一世 尝试创建一个 REST API，它将电子邮件作为我的输入声明 自定义策略（TrustFrameworkExtensions）并进一步点击 Graph API 到 检查此电子邮件是否存在于 B2C 中仅适用于本地 帐户，而不是社交媒体帐户。

如果这是真的，我试图让这个场景发挥作用就不会成功。

此评论是否属实？如果是，在与第 3 方 iDP 合作时，是否有其他方法可以拦截登录\注册操作？

注 1：

探索更多TrustFrameworkBase.xml 文件我看到了这个技术简介SelfAsserted-Social。我想我将不得不使用它而不是 LocalAccountSignUpWithLogonEmail。

【参考方案1】：

是的，注意 1 我在上面的问题中添加的是要走的路。

刚刚使用SelfAsserted-Social 技术配置文件而不是LocalAccountSignUpWithLogonEmail 测试了场景。

它工作正常，其余 API 已按预期调用。我可以在应用服务的日志流中看到跟踪和尝试发送的电子邮件。

当提供无效的电子邮件时，用户可以看到从自定义验证端点返回的错误消息。

这是TrustFrameworkExtensions.xml 中被覆盖\补充的技术配置文件：

<ClaimsProvider>
  <DisplayName>Self Asserted</DisplayName>
  <TechnicalProfiles>

    <TechnicalProfile Id="SelfAsserted-Social">
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateEmail" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>

  </TechnicalProfiles>
</ClaimsProvider>

【讨论】：

@arunthomas：不确定……因为这个项目很旧，我无法为 MS 帐户测试这个特定案例。