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

Статья
01/11/2024

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

В этой статье вы узнаете, как написать пользовательскую политику Azure Active Directory B2C (Azure AD B2C), которая позволяет пользователю создавать локальную учетную запись Azure AD B2C или входить в нее. Локальная учетная запись ссылается на учетную запись, созданную в клиенте Azure AD B2C при регистрации пользователя в приложении.

Обзор

Azure AD B2C использует протокол проверки подлинности OpenID Подключение для проверки учетных данных пользователя. В Azure AD B2C вы отправляете учетные данные пользователя вместе с другими сведениями в безопасную конечную точку, которая затем определяет, являются ли учетные данные допустимыми или нет. При использовании реализации OpenID Подключение Azure AD B2C можно выполнять аутсорсинг регистрации, входа и других возможностей управления удостоверениями в веб-приложениях в идентификатор Microsoft Entra ID.

Пользовательская политика Azure AD B2C предоставляет технический профиль OpenID Подключение, который используется для вызова безопасной конечной точки Майкрософт. Дополнительные сведения о техническом профиле OpenID Подключение.

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

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

Примечание.

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

Шаг 1. Настройка технического профиля OpenID Подключение

Чтобы настроить технический профиль OpenID Подключение, необходимо выполнить три действия.

Объявите больше утверждений.
Зарегистрируйте приложения в портал Azure.
Наконец, настройте сам технический профиль OpenID Подключение

Шаг 1.1. Объявление дополнительных утверждений

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

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="grant_type">
            <DisplayName>grant_type</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="scope">
            <DisplayName>scope</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="nca">
            <DisplayName>nca</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Special parameter passed for local account authentication to login.microsoftonline.com.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="client_id">
            <DisplayName>client_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="resource_id">
            <DisplayName>resource_id</DisplayName>
            <DataType>string</DataType>
            <AdminHelpText>Special parameter passed to EvoSTS.</AdminHelpText>
            <UserHelpText>Special parameter passed to EvoSTS.</UserHelpText>
        </ClaimType>
    <!--</ClaimsSchema>-->

Шаг 1.2. Регистрация приложений identity Experience Framework

Azure AD B2C требует регистрации двух приложений, которые используются для регистрации и входа пользователей с локальными учетными записями: IdentityExperienceFramework, веб-API и ProxyIdentityExperienceFramework, собственного приложения с делегированным разрешением для приложения IdentityExperienceFramework.

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

Чтобы зарегистрировать приложение IdentityExperienceFramework, выполните действия, описанные в разделе "Регистрация приложения IdentityExperienceFramework". Скопируйте идентификатор приложения (клиента), appID для регистрации приложения Identity Experience Framework для использования на следующем шаге.
Чтобы зарегистрировать приложение ProxyIdentityExperienceFramework, выполните действия, чтобы зарегистрировать приложение Proxy Identity Experience Framework. Скопируйте идентификатор приложения (клиента), proxyAppID для регистрации приложения Proxy Identity Experience Framework для использования на следующем шаге.

Шаг 1.3. Настройка технического профиля OpenID Подключение

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

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>OpenID Connect Technical Profiles</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SignInUser">
                    <DisplayName>Sign in with Local Account</DisplayName>
                    <Protocol Name="OpenIdConnect" />
                    <Metadata>
                        <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We didn't find this account</Item>
                        <Item Key="UserMessageIfInvalidPassword">Your password or username is incorrect</Item>
                        <Item Key="UserMessageIfOldPasswordUsed">You've used an old password.</Item>
                        <Item Key="ProviderName">https://sts.windows.net/</Item>
                        <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item>
                        <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item>
                        <Item Key="response_types">id_token</Item>
                        <Item Key="response_mode">query</Item>
                        <Item Key="scope">email openid</Item>
                        <!-- Policy Engine Clients -->
                        <Item Key="UsePolicyInRedirectUri">false</Item>
                        <Item Key="HttpBinding">POST</Item>
                        <Item Key="client_id">proxyAppID</Item>
                        <Item Key="IdTokenAudience">appID</Item>
                    </Metadata>
                    <InputClaims>
                        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="username" Required="true" />
                        <InputClaim ClaimTypeReferenceId="password" PartnerClaimType="password" Required="true" />
                        <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" />
                        <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" />
                        <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" />
                        <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="proxyAppID" />
                        <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="appID" />
                    </InputClaims>
                    <OutputClaims>
                        <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" />
                    </OutputClaims>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Замените оба экземпляра:

appID с идентификатором приложения (клиента) приложения Identity Experience Framework, скопированного на шаге 1.2.
proxyAppID с идентификатором приложения Application (client) приложения Proxy Identity Experience Framework, скопированного на шаге 1.2.

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

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

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

    <TechnicalProfile Id="UserSignInCollector">
        <DisplayName>Local Account Signin</DisplayName>
        <Protocol Name="Proprietary"
            Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
        <Metadata>
            <Item Key="setting.operatingMode">Email</Item>
            <Item Key="SignUpTarget">AccountTypeInputCollectorClaimsExchange</Item>
        </Metadata>
        <DisplayClaims>
            <DisplayClaim ClaimTypeReferenceId="email" Required="true" />
            <DisplayClaim ClaimTypeReferenceId="password" Required="true" />
        </DisplayClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="password"  />
            <OutputClaim ClaimTypeReferenceId="objectId" />
        </OutputClaims>
        <ValidationTechnicalProfiles>
            <ValidationTechnicalProfile ReferenceId="SignInUser" />
        </ValidationTechnicalProfiles>
    </TechnicalProfile>

Мы добавили технический профиль SelfAsserted UserSignInCollector, который отображает форму входа для пользователя. Мы настроили технический профиль для сбора адреса электронной почты пользователя в качестве имени входа, как указано в setting.operatingMode метаданных. Форма входа включает ссылку на регистрацию, которая ведет пользователя к форме регистрации, как указано метаданными SignUpTarget . Вы увидите, как настроить SignUpWithLogonEmailExchangeClaimsExchange в шагах оркестрации.

Кроме того, мы добавили Подключение Технического профиля SignInUser OpenID в качестве файла ValidationTechnicalProfile. Таким образом, технический профиль SignInUser выполняется, когда пользователь выбирает кнопку входа (см. снимок экрана на шаге 5).

На следующем шаге (шаг 2.2) мы настроим определение содержимого, которое мы будем использовать в этом техническом профиле selfAsserted.

ContosoCustomPolicy.XML В файле найдите раздел ContentDefinitions, а затем войдите в определение контента с помощью следующего кода:

    <!--<ContentDefinitions>-->
        ...
            <ContentDefinition Id="SignupOrSigninContentDefinition">
                <LoadUri>~/tenant/templates/AzureBlue/unified.cshtml</LoadUri>
                <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
                <DataUri>urn:com:microsoft:aad:b2c:elements:contract:unifiedssp:2.1.7</DataUri>
                <Metadata>
                    <Item Key="DisplayName">Signin and Signup</Item>
                </Metadata>
            </ContentDefinition>
    <!--</ContentDefinitions>-->

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

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

ContosoCustomPolicy.XML В файле найдите путешествие пользователя HelloWorldJourney и замените всю коллекцию шагов оркестрации следующим кодом:

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
            </ClaimsProviderSelections>
            <ClaimsExchanges>
                <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
            </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                  <Value>accountType</Value>
                  <Value>company</Value>
                  <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="GetAccessCodeClaimsExchange" TechnicalProfileReferenceId="AccessCodeInputCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>
        
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
            </ClaimsExchanges>
        </OrchestrationStep>  
      
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
            </ClaimsExchanges>
        </OrchestrationStep>                
        
        <OrchestrationStep Order="6" Type="ClaimsExchange">
            <ClaimsExchanges>
            <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
            </ClaimsExchanges>          
        </OrchestrationStep>                
        
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

В шагах оркестрации два–пять мы использовали предварительные условия, чтобы определить, должен ли выполняться шаг оркестрации. Нам нужно определить, входит ли пользователь в систему или подписывается.

При запуске настраиваемой политики:

Шаг 1 оркестрации — отображает страницу входа, чтобы пользователь смог войти или выбрать ссылку "Регистрация сейчас". Обратите внимание, что мы указываем определение содержимого, которое использует самотверждаемый технический профиль UserSignInCollector для отображения формы входа.
Шаг оркестрации 2 . Этот шаг выполняется, если пользователь регистрируется (objectId не существует), поэтому мы отображаем форму выбора типа учетной записи путем вызова самоутверждаемого технического профиля AccountTypeInputCollector .
Шаг оркестрации 3 . Этот шаг выполняется, если пользователь регистрируется (objectId не существует), и что пользователь не выбирает компанию accountType. Поэтому мы должны попросить пользователя ввести ввод, accessCode вызвав самозаверяемый технический профиль AccessCodeInputCollector .
Шаг оркестрации 4 . Этот шаг выполняется, если пользователь регистрируется (objectId не существует), поэтому мы отображаем форму регистрации, вызвав самоподдерживаемый технический профиль UserInformationCollector .
Шаг оркестрации 5 . Этот шаг считывает сведения об учетной записи из идентификатора Microsoft Entra (мы вызываем AAD-UserRead технический профиль Microsoft Entra ID), поэтому он запускается, регистрируется ли пользователь или входит в систему.
Шаг оркестрации 6 . Этот шаг вызывает технический профиль UserInputMessageClaimGenerator для сборки приветствия пользователя.
Шаг оркестрации 7 . Наконец, шаг 8 собирает и возвращает токен JWT в конце выполнения политики.

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

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

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

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

screenshot of sign-up or sign-in interface.

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

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

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

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

Обзор

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

Шаг 1. Настройка технического профиля OpenID Подключение

Шаг 1.1. Объявление дополнительных утверждений

Шаг 1.2. Регистрация приложений identity Experience Framework

Шаг 1.3. Настройка технического профиля OpenID Подключение

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

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

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

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

Дополнительные ресурсы

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

Обзор

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

Шаг 1. Настройка технического профиля OpenID Подключение

Шаг 1.1. Объявление дополнительных утверждений

Шаг 1.2. Регистрация приложений identity Experience Framework

Шаг 1.3. Настройка технического профиля OpenID Подключение

Шаг 2. Настройка пользовательского интерфейса входа

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

Шаг 2.2. Настройка определения содержимого интерфейса входа

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

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

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

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

Дополнительные ресурсы