Как ADB2 C, добавленный через Azure -Portal UI (OID C), создает objectId? А как насчет альтернативыSecurityId?

Question

У меня есть существующее приложение, которое использует objectId для идентификации пользователей и хранения их данных. Он использует встроенный поток для регистрации / входа. Компания AD была добавлена ​​через Azure -Portal UI как OID C -Provider.

Поскольку мы требуем, чтобы пользователь согласился с Условиями использования до регистрации, потребовалась настраиваемая политика. Эта настраиваемая политика была создана с использованием стартового пакета для локальной и социальной учетной записи. Компания AD была снова добавлена ​​в качестве поставщика OICD. Это было сделано, как описано здесь: документация

AD B2 C не может найти существующего пользователя при использовании технического профиля для чтения из AAD с помощью AlternativeSecurityId. Но этот технический профиль должен использоваться для социальных учетных записей, не так ли? t распознает пользователя и затем переходит к процессу регистрации. Что было бы правильным поведением, если бы пользователь еще не существовал.

Я предполагаю, что если AD добавляется через пользовательский интерфейс, он создает другой альтернативный идентификаторSecurityId для пользователя или не создает его в все.

Это преобразование выходных требований поставщика требований для компании AD:

<OutputClaimsTransformations>
    <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
    <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
    <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
    <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
</OutputClaimsTransformations>

Преобразование требований, использованное для создания альтернативного идентификатора безопасности, как предусмотрено в начальном пакете:

<ClaimsTransformation Id="CreateAlternativeSecurityId" TransformationMethod="CreateAlternativeSecurityId">
    <InputClaims>
        <InputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="key" />
        <InputClaim ClaimTypeReferenceId="identityProvider" TransformationClaimType="identityProvider" />
    </InputClaims>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="alternativeSecurityId" TransformationClaimType="alternativeSecurityId" />
    </OutputClaims>
</ClaimsTransformation>

Есть ли способ заставить adb2 c создать тот же objectId, используя настраиваемые политики, как это было раньше?

Answer 1

altSecId создается таким же образом на основе идентификатора пользователя, пришедшего от федеративного IdP. Таким образом, он должен возвращаться одинаково как в пользовательских потоках, так и в настраиваемых политиках.

Сравните сопоставление утверждений между потоком пользователя и настраиваемой политикой, убедитесь, что UserId сопоставлен с одним и тем же утверждением. Другая вещь, которую нужно проверить, - это эмитент в коллекции Identities. Это в настраиваемой политике устанавливается утверждением identityProvider.

Вероятно, это отличается в настраиваемой политике от User Flow. Вы можете подтвердить текущего эмитента, вернув пользователя в MS Graph Api и изучив коллекцию Identities.

Существует операция чтения для поиска социального идентификатора, объединяющая AltSecId и Issuer в коллекцию, и выполняет поиск в каталоге.

Итак, обе эти вещи должны быть абсолютно одинаковыми. Найдите текущего установленного поставщика и обновите утверждение identityProvider в настраиваемой политике той же строкой.