Можно ли проверить заявление по электронной почте от поставщиков социальной идентификации (iDP) с помощью настраиваемой политики Azure B2C, прежде чем создавать пользователя в Azure AD?

Question

Сценарий таков: мы добавили 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. Однако, независимо от того, что я делаю, я не вижу trace журналов из метода проверки REST API, который я написал, и никаких вызовов REST-ValidateEmail. Похоже, он вообще не вызывается.

Из этого комментария :

Этот трюк вызова внешнего API из моей пользовательской политики не сработал, потому что мыне может перехватить входящие \ входящие звонки из социальных сетей. Я попытался создать REST API, который будет принимать электронную почту в качестве входной заявки в моей настраиваемой политике (TrustFrameworkExtensions), и еще раз нажал Graph API, чтобы убедиться, что эта электронная почта существует в B2C или не будет работать только для локальных учетных записей, а не для учетных записей социальных сетей.

Если это правда, моя попытка заставить этот сценарий работать не будет успешной.

Этот комментарий верен? Если да, есть ли какой-либо другой способ перехвата действий входа в систему при регистрации с iDP сторонних производителей?

Примечание 1:

Более подробное изучениеиз файла TrustFrameworkBase.xml Я вижу этот технический профиль SelfAsserted-Social. Я думаю, мне придется использовать его вместо LocalAccountSignUpWithLogonEmail.

Answer 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>