Создание ветвления в пути пользователя с помощью пользовательской политики Azure Active Directory B2C

Статья
01/11/2024

Разные пользователи одного и того же приложения могут следовать различным пути взаимодействия пользователей в зависимости от значений данных в пользовательской политике. Пользовательские политики Azure Active Directory B2C (Azure AD B2C) позволяют условно включить или отключить технический профиль для достижения этой возможности. Например, при проверке входных данных пользователей с помощью настраиваемой политики Azure AD B2C мы использовали Precondition для определения того, следует ли запускать технический профиль проверки на основе значения утверждения accountType .

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

Обзор сценария

В статье "Проверка входных данных пользователей с помощью пользовательской политики Azure AD B2C" пользователь вводит свои сведения на одном экране. В этой статье пользователю необходимо сначала выбрать тип учетной записи, учетную запись сотрудника Contoso или личную учетную запись. Пользователь, который выбирает учетную запись сотрудника Contoso, может продолжить предоставление дополнительных сведений. Однако пользователю, который выбирает личную учетную запись , необходимо предоставить действительный код доступа к приглашению, прежде чем они смогут перейти к дополнительным сведениям. Таким образом, пользователи, использующие тип учетной записи личных учетных записей , видят дополнительный пользовательский интерфейс для завершения своего пути.

A flowchart of branching in user journey.

В этой статье вы узнаете, как использовать EnabledForUserJourneys элемент внутри технического профиля для создания различных пользовательских возможностей на основе значения утверждения.

Необходимые компоненты

Если у вас еще нет клиента Azure AD B2C, создайте его. Он должен быть связан с вашей подпиской Azure.
Зарегистрируйте веб-приложение и включите неявное предоставление разрешения для маркера идентификации. Для URI перенаправления используйте https://jwt.ms.
На компьютере должен быть установлен Visual Studio Code (VS Code ).
Выполните действия, описанные в разделе "Проверка входных данных пользователей" с помощью настраиваемой политики Azure AD B2C. Эта статья является частью руководства по созданию и запуску собственных пользовательских политик.

Примечание.

Эта статья является частью серии руководств по созданию и запуску собственных пользовательских политик в Azure Active Directory B2C. Мы рекомендуем начать эту серию из первой статьи.

Шаг 1. Объявление утверждений

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

В VS Code откройте ContosoCustomPolicy.XML файл.

В разделе объявите ClaimsSchema утверждения accessCode и isValidAccessCode с помощью следующего кода:

    <ClaimType Id="accessCode">
        <DisplayName>Access Code</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Enter your invitation access code.</UserHelpText>
        <UserInputType>Password</UserInputType>
        <Restriction>
            <Pattern RegularExpression="[0-9][0-9][0-9][0-9][0-9]" HelpText="Please enter your invitation access code. It's a 5-digit number, something like 95765"/>
        </Restriction>
    </ClaimType>
    <ClaimType Id="isValidAccessCode">
        <DataType>boolean</DataType>
    </ClaimType>

Шаг 2. Определение преобразований утверждений

ClaimsTransformations Найдите элемент и добавьте следующие преобразования утверждений:

    <!---<ClaimsTransformations>-->
        <ClaimsTransformation Id="CheckIfIsValidAccessCode" TransformationMethod="CompareClaimToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="accessCode" TransformationClaimType="inputClaim1"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="compareTo" DataType="string" Value="88888"/>
                <InputParameter Id="operator" DataType="string" Value="equal"/>
                <InputParameter Id="ignoreCase" DataType="string" Value="true"/>
            </InputParameters>
            <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="outputClaim"/>
            </OutputClaims>
        </ClaimsTransformation>
        <ClaimsTransformation Id="ThrowIfIsNotValidAccessCode" TransformationMethod="AssertBooleanClaimIsEqualToValue">
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="isValidAccessCode" TransformationClaimType="inputClaim"/>
            </InputClaims>
            <InputParameters>
                <InputParameter Id="valueToCompareTo" DataType="boolean" Value="true"/>
            </InputParameters>
        </ClaimsTransformation>
    <!---</ClaimsTransformations>-->

Мы определили два преобразования утверждений, CheckIfIsValidAccessCode и ThrowIfIsNotValidAccessCode. CheckIfIsValidAccessCode использует метод преобразования CompareClaimToValue для сравнения ввода кода доступа пользователем со статическим значением 888888 (давайте используем это значение для тестирования) и назначает true или falseутверждение isValidAccessCode . ThrowIfIsNotValidAccessCode проверка указывает, равны ли два логических значения двух утверждений, и создает исключение, если они не являются.

Шаг 3. Настройка или обновление технических профилей

Теперь вам потребуется два новых самоутверждаемых технических профилей, один для сбора типа учетной записи, а другой — для сбора кода доступа от пользователя. Для проверки кода доступа пользователя необходимо также создать технический профиль преобразования утверждений, выполнив преобразования утверждений, определенные на шаге 2. Теперь, когда мы собираем тип учетной записи в другом самоутверждаемом техническом профиле, необходимо обновить UserInformationCollector самоутверждаемый технический профиль, чтобы предотвратить сбор типа учетной записи.

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

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profiles to collect user's access code</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccessCodeInputCollector">
                    <DisplayName>Collect Access Code Input from user Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                        <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">The access code is invalid.</Item>
                        <Item Key="ClaimTypeOnWhichToEnable">accountType</Item>
                        <Item Key="ClaimValueOnWhichToEnable">personal</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accessCode" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accessCode"/>
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                        <ValidationTechnicalProfile ReferenceId="CheckAccessCodeViaClaimsTransformationChecker"/>
                    </ValidationTechnicalProfiles>
                    <EnabledForUserJourneys>OnClaimsExistence</EnabledForUserJourneys>
                </TechnicalProfile>
                <TechnicalProfile Id="CheckAccessCodeViaClaimsTransformationChecker">
                    <DisplayName>A Claims Transformations to check user's access code validity</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="isValidAccessCode"/>
                    </OutputClaims>
                    <OutputClaimsTransformations>
                        <OutputClaimsTransformation ReferenceId="CheckIfIsValidAccessCode"/>
                        <OutputClaimsTransformation ReferenceId="ThrowIfIsNotValidAccessCode"/>
                    </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Мы настроили два технических профиля: AccessCodeInputCollector и CheckAccessCodeViaClaimsTransformationChecker. Мы вызываем технический профиль CheckAccessCodeViaClaimsTransformationChecker в качестве технического профиля проверки из технического профиля AccessCodeInputCollector . Сам CheckAccessCodeViaClaimsTransformationChecker имеет технический профиль преобразования утверждений типа, который выполняет преобразования утверждений, определенные на шаге 2.

AccessCodeInputCollector — это самоутверждаемый технический профиль, используемый для сбора кода доступа от пользователя. Он включает EnabledForUserJourneys элемент, который имеет значение OnClaimsExistence. Его Metadata элемент включает утверждение (accountType) и его значение (личное), которое активирует этот технический профиль.

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

    <!--<ClaimsProviders>-->
        <ClaimsProvider>
            <DisplayName>Technical Profile to collect user's accountType</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="AccountTypeInputCollector">
                    <DisplayName>Collect User Input Technical Profile</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
                    <Metadata>
                        <Item Key="ContentDefinitionReferenceId">SelfAssertedContentDefinition</Item>
                    </Metadata>
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>
                    </DisplayClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="accountType"/>
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

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

Чтобы предотвратить UserInformationCollector самозаверяемый технический профиль сбора типа учетной записи, найдите UserInformationCollector самозаверяемый технический профиль, а затем:
1. accountType Удалите утверждение <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> отображения из DisplayClaims коллекции.
2. Удалите выходное accountTypeOutputClaims утверждение <OutputClaim ClaimTypeReferenceId="accountType"/>из коллекции.

Шаг 4. Обновление шагов оркестрации взаимодействия пользователей

Теперь, когда вы настроили технические профили, необходимо обновить шаги оркестрации взаимодействия пользователя:

Найдите путешествие HelloWorldJourney пользователя и добавьте все шаги оркестрации следующим кодом:

    <!--<OrchestrationSteps>-->
        <OrchestrationStep Order="1" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
            </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetUserInformationClaimsExchange" TechnicalProfileReferenceId="UserInformationCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="ClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

Шаги оркестрации показывают, что мы вызываем технический профиль в порядке, показанном атрибутом шагов Order оркестрации. Однако технический профиль активируется, AccessCodeInputCollector если пользователь выбирает тип учетной записи личной учетной записи .

Шаг 5. Отправка пользовательского файла политики

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

Шаг 6. Проверка настраиваемой политики

Выполните действия, описанные в разделе "Тестирование настраиваемой политики", чтобы протестировать настраиваемую политику :

На первом экране в поле "Тип учетной записи" выберите "Личная учетная запись".
Для кода доступа введите 88888, а затем нажмите кнопку "Продолжить".
Введите остальные сведения по мере необходимости и нажмите кнопку "Продолжить". После завершения выполнения политики вы будете перенаправлены https://jwt.msв , и вы увидите декодированные токены JWT.
Повторите шаг 5, но на этот раз выберите тип учетной записи, выберите учетную запись сотрудника Contoso, а затем следуйте инструкциям.

Следующие шаги

На шаге 3 мы включите или отключите технический профиль с помощью EnabledForUserJourneys элемента. Кроме того, можно использовать предварительные условия внутри шагов оркестрации взаимодействия пользователя, чтобы выполнить или пропустить шаг оркестрации, как описано далее в этой серии.

Далее вы узнаете:

Поделиться через