在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?

问题描述

情况是这样的:我们已经将Microsoft iDP添加到了我们的应用程序中.用户可以单击"Microsoft帐户"按钮，然后使用其MSA帐户进行注册\登录.

The scenario is this: we have added Microsoft iDP to our app. The user can click the Microsoft Account button and use their MSA account to sign-up\sign-in.

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

When the user signs up we'd like to validate the e-mail against our database. If the user's email is in our database, let them proceed and signup; otherwise we'd like to prevent them from signing up and display an error message. This would prevent creating a User in our 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作为验证技术资料.

Then added REST-ValidateEmail to LocalAccountSignUpWithLogonEmail as a validation technical profile.

<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正在登录Azure门户.但是，无论我做什么，我都看不到我编写的REST API验证方法中的trace日志，也没有看到对REST-ValidateEmail的调用.看起来根本没有被调用.

Added Application Insights debugging to the custom policy. I see UserJourney(s) being logged in Azure Portal. However no matter what I do I can't see trace logs from the REST API validate method I wrote and no calls to REST-ValidateEmail. Looks like it's not being called at all.

来自

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

This trick of calling external API from my custom policy didn't work because we can't intercept sign-in\sign-up calls from social media. I tried creating a REST API that will take email as an input claim in my custom policy(TrustFrameworkExtensions) and further hit Graph API to check that this email exists in B2C or not will work only for local accounts and not for social media accounts.

如果属实，那么我尝试使这种情况正常运行的尝试将不会成功.

If this holds true my attempt to get this scenario working won't flourish.

此评论是否成立?如果是，在使用第三方iDP时是否还有其他方法可以拦截登录\注册操作?

Does this comment holds true? If yes, is there any other way of intercepting Sign-in\Sign-up actions when working with 3rd party iDPs?

注释1:

进一步浏览TrustFrameworkBase.xml文件，我看到此技术资料SelfAsserted-Social.我想我得用它代替LocalAccountSignUpWithLogonEmail.

Exploring a bit more of TrustFrameworkBase.xml file I see this technical profile SelfAsserted-Social. I guess I'll have to use it instead of LocalAccountSignUpWithLogonEmail.

推荐答案

是的，注释1 我在上面的问题中添加的是解决方法.

Yep, Note 1 I added in the question above is the way to go.

仅使用SelfAsserted-Social技术简介而不是LocalAccountSignUpWithLogonEmail对场景进行了测试.

Just tested the scenario using SelfAsserted-Social technical profile instead of LocalAccountSignUpWithLogonEmail.

它起作用了，其余的API均按预期方式被调用.我可以在应用程序服务的日志流中看到跟踪和尝试发送的电子邮件.

It worked and the rest API was called as expected. I can see the traces and the e-mail attempted inside the app service's log stream.

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

When providing an invalid e-mail, the user is able to see the error message returned from the custom validation endpoint.

这是TrustFrameworkExtensions.xml中覆盖的，补充的技术资料:

This is the overridden\complemented technical profile that goes in TrustFrameworkExtensions.xml:

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

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

  </TechnicalProfiles>
</ClaimsProvider>

这篇关于在Azure AD中创建用户之前，是否可以使用Azure B2C自定义策略来验证来自社会身份提供商(iDP)的电子邮件声明?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！