Можно ли автоматически обновлять сведения о пользователе B2C, используя утверждения эмитента с помощью Identity Experience Framework?

Question

Я создал политику для приложения в соответствии с учебными документами B2C. Он успешно создает пользователей в арендаторе B2C, вводя имя, адрес электронной почты и т. д. от любых/всех эмитентов — в настоящее время любой другой арендатор Azure может войти в этот арендатор B2C, это то, что требуется.

Но что, если детали изменяются вместе с исходным объектом эмитента (например, изменение имени)? В настоящее время будет несоответствие, если только пользователь не отредактирует свой профиль (вручную).

Можно ли создать путешествие, которое запрашивает утверждения у эмитента ПОСЛЕ того, как объект существует в арендаторе B2C, а затем обновляет локального пользователя новыми данными?

Результатом, которого я хотел добиться, было автоматическое обновление пользователя арендатора B2C, если исходная учетная запись была каким-либо образом отредактирована, в момент аутентификации пользователя B2C. Таким образом, приложение, связанное с арендатором B2C, может получать обновленные заявки.

Я понимаю предпосылку, но чего мне не хватает, так это знания о том, какие шаги в путешествии мне понадобятся, как эти шаги будут выглядеть. Если бы кто-нибудь мог поделиться примером даже простого чтения имени от исходного эмитента и копирования его пользователем клиента B2C, это было бы чрезвычайно полезно для меня.

[Изменить] Спасибо Jas за подробное решение! Я решил эту проблему, просто добавив шаги AAD-UserReadUsingObjectId и AAD-UserWriteUsingAlternativeSecurityId в конец пути регистрации-входа. Который обновляет объект пользователя B2C утверждениями из исходного объекта каждый раз, когда они входят в систему, и соответствует требованиям, поскольку он обновляет арендатора B2C и передает обновленные атрибуты приложению, которое также требует их.

Answer 1

Выходные утверждения в техническом профиле OpenId позволяют сопоставлять утверждения, поступающие от поставщика удостоверений, с пакетом требований AAD B2C.

Давайте воспользуемся примером отслеживания того, изменилось ли displayName у IdP.

      <OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="live.com" />
  <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />
  <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
  <OutputClaim ClaimTypeReferenceId="displayNameFromIdp" PartnerClaimType="name" />
  <OutputClaim ClaimTypeReferenceId="email" />
</OutputClaims>

Затем мы читаем пользователя с помощью AAD-ReadUsingAlternativeSecurityId по умолчанию. См. выходные утверждения здесь следующим образом, это будет считывать отображаемое имя пользователя, который уже существует в каталоге B2C.

                <OutputClaims>
            <!-- Required claims -->
            <OutputClaim ClaimTypeReferenceId="objectId" />

            <!-- Optional claims -->
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="otherMails" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="identityChanged" DefaultValue="false"/>
          </OutputClaims>

А теперь сравним displayNameи значения с помощью преобразования утверждения CompareClaims .

      <ClaimsTransformation Id="CompareDisplayName" TransformationMethod="CompareClaims">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="displayNameFromIdp" TransformationClaimType="inputClaim1" />
    <InputClaim ClaimTypeReferenceId="displayName" TransformationClaimType="inputClaim2" />
  </InputClaims>
  <InputParameters>
    <InputParameter Id="operator" DataType="string" Value="NOT EQUAL" />
    <InputParameter Id="ignoreCase" DataType="boolean" Value="true" />
  </InputParameters>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="identityChanged" TransformationClaimType="outputClaim" />
  </OutputClaims>
</ClaimsTransformation>

Сделайте подобное преобразование утверждения для каждого утверждения, которое вы хотите проверить. Меняйте только inputClaims, так что если что-то изменится, это всегда будет отражено как логическое значение в утверждении.

Добавьте это требование Преобразование в качестве преобразования выходных утверждений в AAD-ReadUsingAlternativeSecurityId:

                <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CompareDisplayName" />
          </OutputClaimsTransformations>

Для каждого создаваемого вами преобразования утверждений, для каждого атрибута, который вы хотите синхронизировать, добавьте выходное преобразование утверждений, ссылающееся на идентификатор преобразования утверждений.

Теперь, если == true, мы знаем, что это технический профиль записи AAD. В своем путешествии добавьте шаг в какой-то момент после AAD-UserReadUsingAlternativeSecurityId(после прочтения пользователя), и после AAD-UserWriteUsingAlternativeSecurityId(после создания пользователя).

              <OrchestrationStep Order="NUMBER" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>identityChanged</Value>
              <Value>false</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserUpdate" TechnicalProfileReferenceId="AAD-UserUpdateUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>

Определите технический профиль Azure AD для обновления пользователя:

              <TechnicalProfile Id="AAD-UserUpdateUsingAlternativeSecurityId">
          <Metadata>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
          </Metadata>
          <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
          </PersistedClaims>
          <IncludeTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
        </TechnicalProfile>

Определение претензии identityChanged, а также displayNameFromIdp:

            <ClaimType Id="identityChanged">
        <DisplayName>identityChanged</DisplayName>
        <DataType>boolean</DataType>
      </ClaimType>
      <ClaimType Id="displayNameFromIdp">
        <DisplayName>displayNameFromIdp</DisplayName>
        <DataType>string</DataType>
      </ClaimType>

Answer 2

Поток будет:

• Вход пользователя
• Позвоните исходному эмитенту через API и получите последние данные о пользователе.
• Сравните детали и обновите, если требуется. Вы можете использовать строковые преобразования .
• Напишите обновленные данные