В Azure AD B2C: как связать социальную учетную запись пользователя с уже существующей локальной учетной записью при первом входе из социальной сети?

Образец Wingtip содержит пример этот поток.

См. файл проверяющей стороны "B2C_1A_link" и путь пользователя" Ссылка " для справки.

Обратите внимание, что этот путь пользователя побуждает конечного пользователя войти в систему с локальной учетной записью, прежде чем он войдет в систему с учетной записью социальной сети.

Подробный пример приведен здесь.

Обновление «идентификаторов пользователей» свяжет учетную запись социальной сети с локальной учетной записью.

Этого можно достичь, пройдя путь пользователя, аналогичный приведенному ниже.

<UserJourney Id="AccountLinkage">
  <PreserveOriginalAssertion>false</PreserveOriginalAssertion>
  <OrchestrationSteps>
    <!-- Demo: The following orchestration step is always executed. 
         Asks user to sign-in with local account (only)-->
    <OrchestrationStep Order="1" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselections">
      <ClaimsProviderSelections>
        <ClaimsProviderSelection TargetClaimsExchangeId="LocalAccountSigninEmailExchange" />
      </ClaimsProviderSelections>
    </OrchestrationStep>

    <!-- Demo: Sign-in with local account-->
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: After user is sign-in, it reads the user, by user object ID,
         from the Azure AD identity store. An error is raised if the user does not exist. -->
    <OrchestrationStep Order="3" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: After user is sign-in, and we have the user object ID.
        Now, ask the user to re-sign-in, but this time with
        one of the social account. This orchestration step, displays the sign-in with social
        account buttons.
        Note, You may want to add additional social accounts here-->
    <OrchestrationStep Order="4" Type="ClaimsProviderSelection" ContentDefinitionReferenceId="api.idpselections">
      <ClaimsProviderSelections>
        **<ClaimsProviderSelection TargetClaimsExchangeId="GoogleExchange" />
        <ClaimsProviderSelection TargetClaimsExchangeId="AmazonAccountExchange" />**
      </ClaimsProviderSelections>
    </OrchestrationStep>

    <!-- Demo: Run the sign-in with social account, based on user choice (from previous step)
        Note, You may want to add additional social accounts here -->
    <OrchestrationStep Order="5" Type="ClaimsExchange">
      <ClaimsExchanges>
        **<ClaimsExchange Id="GoogleExchange" TechnicalProfileReferenceId="Google-OAUTH" />
        <ClaimsExchange Id="AmazonAccountExchange" TechnicalProfileReferenceId="AmazonAccount-OAuth2" />**
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: Updates the social account for a user, identified by the object
         identifier for the user, in the Azure AD identity store. 
         An error is raised if the user does not exist. -->
    <OrchestrationStep Order="6" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AAD-UserWriteUsingAlternativeSecurityId-ThrowIfNotExists" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId-ThrowIfNotExists" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: Re-reads the user, by user object Id, from the Azure Active Directory.
         An error is raised if the user does not exist. -->
    <OrchestrationStep Order="7" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectIdAfter" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: Issues a JWT token to the relying party. -->
    <OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
  </OrchestrationSteps>
</UserJourney>

Затем создайте политику LinkExternalAccount.xml, аналогичную приведенной ниже.

<RelyingParty>
<!-- Demo: This relying party policy executes the `AccountLinkage` user journey.
Please see the B2C_1A_Link_TrustFrameworkExtensions policy for more details -->
<DefaultUserJourney ReferenceId="AccountLinkage" />
<TechnicalProfile Id="PolicyProfile">
  <DisplayName>PolicyProfile</DisplayName>
  <Protocol Name="OpenIdConnect" />
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="email" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
    <OutputClaim ClaimTypeReferenceId="identityProvider" />
  </OutputClaims>
  <SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>

Как только мы запустим наш «Linkexternalaccount.xml», он будет перенаправлен на нашу локальную учетную запись для входа в систему, а после успешного входа в систему он запросит выбор IDP и на основе выбора пользователя атрибут «Идентификационные данные пользователя» будет обновлен. Мы можем проверить то же самое, запросив пользователя. Образец удостоверения пользователя выглядит следующим образом:

 **"userIdentities": [
    {
        "issuer": "google.com",
        "issuerUserId": "MTA5MjA5ODQwNzAyNjc3NTEzMzM5"
    }**