#azure-ad-b2c
#azure-ad-b2c
Вопрос:
В моей пользовательской политике я пытаюсь получить пользователя из каталога, используя свойство strongAuthenticationEmailAddress, как описано в следующем примере (строка 135 в TrustFrameworkExtensions.xml ), однако, похоже, что это работает не так, как ожидалось.
<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. Теперь у меня есть рабочее решение, использующее коллекцию имен входа, большое спасибо за информацию.