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

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

  • Статья

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

Настраиваемая политика может подключаться к хранилищу идентификаторов Microsoft Entra с помощью технического профиля Microsoft Entra ID для хранения, обновления или удаления сведений о пользователе. В этой статье вы узнаете, как настроить набор технических профилей Идентификатора Microsoft Entra для хранения и чтения учетной записи пользователя перед возвратом маркера JWT.

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

При вызове REST API с помощью статьи пользовательской политики Azure Active Directory B2C мы собираем сведения от пользователя, проверяем данные, называемые REST API, и, наконец, возвращаем JWT без хранения учетной записи пользователя. Мы должны хранить сведения о пользователе, чтобы мы не потеряли информацию после завершения выполнения политики. На этот раз, когда мы собираем сведения о пользователе и проверяем его, необходимо сохранить сведения о пользователе в хранилище Azure AD B2C, а затем прочитать перед возвратом маркера JWT. Полный процесс показан на следующей схеме.

A flowchart of creating a user account in Azure AD.

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

Примечание.

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

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

Необходимо объявить еще два утверждения, userPrincipalNameи passwordPolicies:

  1. ContosoCustomPolicy.XML В файле найдите элемент ClaimsSchema и объявите userPrincipalName и passwordPolicies утверждения с помощью следующего кода:

        <ClaimType Id="userPrincipalName">
        <DisplayName>UserPrincipalName</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Your user name as stored in the Azure Active Directory.</UserHelpText>
    </ClaimType>
    <ClaimType Id="passwordPolicies">
        <DisplayName>Password Policies</DisplayName>
        <DataType>string</DataType>
        <UserHelpText>Password policies used by Azure AD to determine password strength, expiry etc.</UserHelpText>
    </ClaimType>

    Дополнительные сведения об использовании и утверждений userPrincipalName в статье атрибутов профиля пользователя.passwordPolicies

Шаг 2. Создание технических профилей идентификатора Microsoft Entra

Необходимо настроить два технических профиля идентификатора Microsoft Entra. Один технический профиль записывает сведения о пользователе в хранилище идентификаторов Microsoft Entra ID, а другой считывает учетную запись пользователя из хранилища идентификатора Microsoft Entra ID.

  1. ContosoCustomPolicy.XML В файле найдите элемент ClaimsProviders и добавьте новый поставщик утверждений с помощью приведенного ниже кода. Этот поставщик утверждений содержит технические профили идентификатора Microsoft Entra:

        <ClaimsProvider>
        <DisplayName>Azure AD Technical Profiles</DisplayName>
        <TechnicalProfiles>
            <!--You'll add you Azure AD Technical Profiles here-->
        </TechnicalProfiles>
    </ClaimsProvider>

  2. В созданном поставщике утверждений добавьте технический профиль Идентификатора Microsoft Entra с помощью следующего кода:

        <TechnicalProfile Id="AAD-UserWrite">
        <DisplayName>Write user information to AAD</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Write</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
            <Item Key="UserMessageIfClaimsPrincipalAlreadyExists">The account already exists. Try to create another account</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />        
            <PersistedClaim ClaimTypeReferenceId="displayName" />
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
            <PersistedClaim ClaimTypeReferenceId="password"/>
            <PersistedClaim ClaimTypeReferenceId="passwordPolicies" DefaultValue="DisablePasswordExpiration,DisableStrongPassword" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" />
        </OutputClaims>
    </TechnicalProfile>

    Мы добавили новый технический профиль Идентификатора Microsoft Entra. AAD-UserWrite Обратите внимание на следующие важные части технического профиля:

    • Операция: операция указывает действие, которое необходимо выполнить, в данном случае — запись. Дополнительные сведения о других операциях в техническом поставщике идентификатора Microsoft Entra ID.

    • Сохраняемые утверждения: элемент PersistedClaims содержит все значения, которые должны храниться в хранилище идентификаторов Microsoft Entra.

    • InputClaims: элемент InputClaims содержит утверждение, которое используется для поиска учетной записи в каталоге или создания новой. В коллекции входных утверждений должен быть ровно один элемент входных утверждений для всех технических профилей Идентификатора Microsoft Entra. Этот технический профиль использует утверждение электронной почты в качестве идентификатора ключа для учетной записи пользователя. Дополнительные сведения о других идентификаторах ключей, которые можно использовать для уникальной идентификации учетной записи пользователя.

  3. ContosoCustomPolicy.XML В файле найдите AAD-UserWrite технический профиль и добавьте новый технический профиль после него с помощью следующего кода:

        <TechnicalProfile Id="AAD-UserRead">
        <DisplayName>Read user from Azure AD storage</DisplayName>
        <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="Operation">Read</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">false</Item>
            <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
        </Metadata>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
        </InputClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
            <OutputClaim ClaimTypeReferenceId="givenName"/>
            <OutputClaim ClaimTypeReferenceId="surname"/>
            <OutputClaim ClaimTypeReferenceId="displayName"/>
        </OutputClaims>
    </TechnicalProfile>

    Мы добавили новый технический профиль Идентификатора Microsoft Entra. AAD-UserRead Мы настроили этот технический профиль для выполнения операции чтения и возврата objectId, givenNamesurnameuserPrincipalNameи displayName утверждений, если учетная запись пользователя в emailInputClaim разделе найдена.

Шаг 3. Использование технического профиля идентификатора Microsoft Entra

После сбора сведений о пользователе с помощью UserInformationCollector самоутверждаемого технического профиля необходимо написать учетную запись пользователя в хранилище идентификаторов Microsoft Entra с помощью технического AAD-UserWrite профиля. Для этого используйте AAD-UserWrite технический профиль в качестве технического профиля проверки в самозаверяемом UserInformationCollector техническом профиле.

ContosoCustomPolicy.XML В файле найдите UserInformationCollector технический профиль и добавьте AAD-UserWrite технический профиль в качестве технического профиля проверки в ValidationTechnicalProfiles коллекции. Это необходимо добавить после технического CheckCompanyDomain профиля проверки.

Мы будем использовать AAD-UserRead технический профиль в шагах оркестрации взаимодействия пользователя для чтения сведений о пользователе перед выдачой токена JWT.

Шаг 4. Обновление технического профиля ClaimGenerator

Технический профиль используется ClaimGenerator для выполнения трех преобразований утверждений: GenerateRandomObjectIdTransformation, CreateDisplayNameTransformation и CreateMessageTransformation.

  1. ContosoCustomPolicy.XML В файле найдите ClaimGenerator технический профиль и замените его следующим кодом:

        <TechnicalProfile Id="UserInputMessageClaimGenerator">
        <DisplayName>User Message Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="message" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateMessageTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    <TechnicalProfile Id="UserInputDisplayNameGenerator">
        <DisplayName>Display Name Claim Generator Technical Profile</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.ClaimsTransformationProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
        </OutputClaims>
        <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateDisplayNameTransformation" />
        </OutputClaimsTransformations>
    </TechnicalProfile>

    Мы разбили технический профиль на два отдельных технических профиля. Технический профиль UserInputMessageClaimGenerator создает сообщение, отправленное как утверждение в токене JWT. Технический профиль UserInputDisplayNameGenerator создает displayName утверждение. Значение displayName утверждения должно быть доступно, прежде чем AAD-UserWrite технический профиль записывает запись пользователя в хранилище идентификатора Microsoft Entra ID. В новом коде мы удаляем файл GenerateRandomObjectIdTransformation , так как objectId он создается и возвращается идентификатором Microsoft Entra после создания учетной записи, поэтому нам не нужно создавать ее в политике.

  2. ContosoCustomPolicy.XML В файле найдите UserInformationCollector самоутверждаемый технический профиль, а затем добавьте UserInputDisplayNameGenerator технический профиль в качестве технического профиля проверки. После этого коллекция технического профиля ValidationTechnicalProfiles должна выглядеть примерно так, UserInformationCollector как показано в следующем коде:

        <!--<TechnicalProfile Id="UserInformationCollector">-->
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="CheckCompanyDomain">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
                        <Value>accountType</Value>
                        <Value>work</Value>
                        <Action>SkipThisValidationTechnicalProfile</Action>
                    </Precondition>
                </Preconditions>
            </ValidationTechnicalProfile>                        
            <ValidationTechnicalProfile ReferenceId="DisplayNameClaimGenerator"/>
            <ValidationTechnicalProfile ReferenceId="AAD-UserWrite"/>
        </ValidationTechnicalProfiles>
    <!--</TechnicalProfile>-->

    Необходимо добавить технический профиль проверки, прежде чем значение утверждения должно быть доступно, прежде чем AAD-UserWritedisplayNameAAD-UserWrite технический профиль записывает запись пользователя в хранилище идентификатора Microsoft Entra ID.

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

Найдите путешествие 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="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer"/>
    <!--</OrchestrationSteps>-->

На шаге 4оркестрации мы выполняем AAD-UserRead технический профиль для чтения сведений о пользователе (для включения в токен JWT) из созданной учетной записи пользователя.

Так как мы не сохраняем message утверждение в шаге 5оркестрации, мы выполняем UserInputMessageClaimGeneratormessage утверждение для включения в токен JWT.

Шаг 6. Отправка политики

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

Шаг 7. Проверка политики

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

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

  1. Войдите на портал Azure с разрешениями "Глобальный администратор" или "Администратор привилегированных ролей".

  2. Если у вас есть доступ к нескольким клиентам, выберите значок Параметры в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню каталогов и подписок.

  3. В разделе Службы Azure выберите Azure AD B2C. Или используйте поле поиска, чтобы найти и выбрать Azure AD B2C.

  4. В разделе Управление выберите Пользователи.

  5. Найдите только что созданную учетную запись пользователя и выберите ее. Профиль учетной записи выглядит следующим образом:

    A screenshot of creating a user account in Azure AD.

В техническом AAD-UserWrite профиле Идентификатора Microsoft Entra мы указываем, что если пользователь уже существует, мы создадим сообщение об ошибке.

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

A screenshot of error as account already exists.

Примечание.

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

Проверка адреса электронной почты пользователя

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

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

Элемент управления отображением — это элемент пользовательского интерфейса, который реализует особую функциональность и взаимодействует с внутренней службой Azure Active Directory B2C (Azure AD B2C). Она позволяет пользователю выполнять на странице действия, которые вызывают технический профиль проверки из внутренней службы. Элементы управления отображением размещаются на этой странице, и на них ссылается технический профиль с самостоятельным подтверждением.

Чтобы добавить проверку электронной почты с помощью элемента управления отображением, выполните следующие действия.

Объявление утверждения

Необходимо объявить утверждение, которое будет использоваться для хранения кода проверки.

Чтобы объявить утверждение в файле, ContosoCustomPolicy.XML найдите ClaimsSchema элемент и объявите verificationCode утверждение с помощью следующего кода:

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="verificationCode">
            <DisplayName>Verification Code</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Enter your verification code</UserHelpText>
            <UserInputType>TextBox</UserInputType>
        </ClaimType>
    <!--</ClaimsSchema>-->

Настройка технического профиля отправки и проверки кода

Azure AD B2C использует технический профиль Microsoft Entra ID SSPR для проверки адреса электронной почты. Этот технический профиль может создавать и отправлять код на адрес электронной почты или проверять код в зависимости от его настройки.

ContosoCustomPolicy.XML В файле найдите ClaimsProviders элемент и добавьте поставщика утверждений с помощью следующего кода:

    <ClaimsProvider>
        <DisplayName>Azure AD self-service password reset (SSPR)</DisplayName>
        <TechnicalProfiles>
            <TechnicalProfile Id="AadSspr-SendCode">
            <DisplayName>Send Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">SendCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
            <TechnicalProfile Id="AadSspr-VerifyCode">
            <DisplayName>Verify Code</DisplayName>
            <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AadSsprProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
            <Metadata>
                <Item Key="Operation">VerifyCode</Item>
            </Metadata>
            <InputClaims>
                <InputClaim ClaimTypeReferenceId="verificationCode" />
                <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="emailAddress" />
            </InputClaims>
            </TechnicalProfile>
        </TechnicalProfiles>
    </ClaimsProvider>

Мы настроили два технических профиля AadSspr-SendCode и AadSspr-VerifyCode. AadSspr-SendCode создает и отправляет код на адрес электронной почты, указанный в InputClaims разделе, в то время как AadSspr-VerifyCode проверяет код. Вы указываете действие, которое вы хотите выполнить в метаданных технического профиля.

Настройка элемента управления отображением

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

Чтобы настроить элемент управления отображением, выполните следующие действия.

  1. ContosoCustomPolicy.XML В файле найдите BuildingBlocks раздел и добавьте элемент управления отображения в качестве дочернего элемента с помощью следующего кода:

        <!--<BuildingBlocks>-->
        ....
        <DisplayControls>
            <DisplayControl Id="emailVerificationControl" UserInterfaceControlType="VerificationControl">
              <DisplayClaims>
                <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
                <DisplayClaim ClaimTypeReferenceId="verificationCode" ControlClaimType="VerificationCode" Required="true" />
              </DisplayClaims>
              <OutputClaims></OutputClaims>
              <Actions>
                <Action Id="SendCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-SendCode" />
                  </ValidationClaimsExchange>
                </Action>
                <Action Id="VerifyCode">
                  <ValidationClaimsExchange>
                    <ValidationClaimsExchangeTechnicalProfile TechnicalProfileReferenceId="AadSspr-VerifyCode" />
                  </ValidationClaimsExchange>
                </Action>
              </Actions>
            </DisplayControl>
        </DisplayControls> 
    <!--</BuildingBlocks>-->

    Мы объявили элемент управления отображением. emailVerificationControl Обратите внимание на следующие важные части:

    • DisplayClaims — как и в самоутверждаемом техническом профиле, этот раздел указывает коллекцию утверждений, собираемых пользователем в элементе управления отображением.

    • Действия — указывает порядок действий, выполняемых элементом управления отображением. Каждое действие ссылается на технический профиль, отвечающий за выполнение действий. Например, SendCode ссылается на AadSspr-SendCode технический профиль, который создает и отправляет код на адрес электронной почты.

  2. ContosoCustomPolicy.XML В файле найдите UserInformationCollector самоутверждаемый технический профиль и замените утверждение отображения электронной почты для emailVerificationControl отображения элемента управления:

    С:

        <DisplayClaim ClaimTypeReferenceId="email" Required="true"/>

    Кому:

        <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />

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

Обновление учетной записи пользователя с помощью технического профиля Идентификатора Microsoft Entra

Технический профиль идентификатора Microsoft Entra можно настроить для обновления учетной записи пользователя вместо попытки создать новую. Для этого задайте технический профиль идентификатора Microsoft Entra, чтобы вызвать ошибку, если указанная учетная запись пользователя еще не существует в Metadata коллекции с помощью следующего кода. Операция должна иметь значение Write:

    <Item Key="Operation">Write</Item>
    <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>

Использование настраиваемых атрибутов

В этой статье вы узнали, как хранить сведения о пользователе с помощью встроенных атрибутов профиля пользователя. Однако часто необходимо создать собственные настраиваемые атрибуты для управления конкретным сценарием. Для этого следуйте инструкциям в статье "Определение настраиваемых атрибутов" в статье Azure Active Directory B2C .

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