Question

正如我从文档中了解到的，Azure AD B2C为来自社交登录（例如GMail / Facebook）的每个用户创建了一个新的本地帐户，同时第一次登录（如果我错了，请纠正我）。但是，我想拦截这个并将用户链接到已经存在的（用户自己的）本地帐户，而无需通过自定义策略创建新的本地帐户。

Answer 1

The Wingtip sample包含此流程的示例。

请参阅the "B2C_1A_link" relying party file和the "Link" user journey以供参考。

请注意，此用户旅程会提示最终用户在使用社交帐户登录之前使用本地帐户登录。

Answer 2

给出了详细的示例here。

更新“用户身份”会将社交帐户与本地帐户相关联。

这可以通过使用户经历类似于以下的过程来实现。

<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"
    }**

在Azure AD B2C中，如何在首次登录社交登录时将用户的社交帐户与已存在的本地帐户相关联？

2 个答案: