Ошибка при получении пользователя с использованием strongAuthenticationEmailAddress

#azure-ad-b2c

#azure-ad-b2c

Вопрос:

В моей пользовательской политике я пытаюсь получить пользователя из каталога, используя свойство strongAuthenticationEmailAddress, как описано в следующем примере (строка 135 в TrustFrameworkExtensions.xml ), однако, похоже, что это работает не так, как ожидалось.

https://github.com/azure-ad-b2c/samples/tree/master/policies/force-unique-email-across-social-identities

 <TechnicalProfile Id="AAD-UserReadUsingExternalIdpEmailAddress">
          <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
          </Metadata>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="strongAuthenticationEmailAddress" Required="true" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="tempObjectId" PartnerClaimType="objectId"/>
          </OutputClaims>
          <IncludeTechnicalProfile ReferenceId="AAD-Common" />
        </TechnicalProfile>
  

После изучения трассировок в App Insights я обнаружил следующую ошибку.

«Исключение»: { «Вид»: «Обработано», «HResult»: «80131500», «Сообщение»: «Произошла ошибка при получении пользователя с использованием идентификатора типа утверждения «strongAuthenticationEmailAddress» в клиенте «XXX». Возвращенная ошибка была 400/Request_UnsupportedQuery: свойство ‘strongAuthenticationEmailAddress’ не существует как объявленное свойство или свойство расширения.»

Я что-то упускаю, что нужно сделать, прежде чем это заработает?

Ответ №1:

Вы можете прочитать пользователя только по идентификатору объекта, именам входа или альтернативному идентификатору безопасности. Это интерфейс к Microsoft Graph API, и он ограничен тем, что он поддерживает для получения учетной записи по уникальному идентификатору. StrongAuthEmail не является уникальным идентификатором.

Комментарии:

1. Похоже, что образец противоречит этому, поэтому мы перепроверим у создателя.

2. Спасибо, Джас, я буду ждать разъяснений. Необходимо убедиться, что адреса электронной почты уникальны для всех учетных записей — например, чтобы предотвратить регистрацию локальной учетной записи, а затем с помощью социального idp, который использует тот же адрес электронной почты. Существуют ли какие-либо другие способы, которыми это может быть достигнуто полностью в рамках пользовательской политики?

3. Да, вы должны сохранить электронное письмо в коллекции имен входа для этого требования, и перекрестная проверка будет проводиться по именам входа вместо strongAuthEmail.

4. Теперь у меня есть рабочее решение, использующее коллекцию имен входа, большое спасибо за информацию.