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

Статья
01/11/2024

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

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

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

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

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

Примечание.

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

Шаг 1. Создание приложения Facebook

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

Шаг 2. Создание ключа политики Facebook

Выполните действия, описанные в статье "Создание хранилища ключей Facebook" ключа политики в клиенте Azure AD B2C. Пропустите предварительные требования и остальные шаги в статье Настройка регистрации и входа с учетной записью Facebook.

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

Объявление дополнительных утверждений
Определите больше преобразований утверждений, чтобы помочь в манипуляциях с утверждениями, такими как создание AlternativeSecurityId.
Настройка поставщика утверждений Facebook
Настройте технические профили Microsoft Entra для чтения и записи учетной записи социальных параметров из базы данных Microsoft Entra.
Настройте самоутверждаемый технический профиль (для принятия дополнительных данных от пользователя или обновления сведений о пользователе) и его определении содержимого.

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

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

    <!--<ClaimsSchema>-->
        ...
        <ClaimType Id="issuerUserId">
            <DisplayName>Username</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
            <UserInputType>TextBox</UserInputType>
            <Restriction>
                <Pattern RegularExpression="^[a-zA-Z0-9]+[a-zA-Z0-9_-]*$" HelpText="The username you provided is not valid. It must begin with an alphabet or number and can contain alphabets, numbers and the following symbols: _ -" />
            </Restriction>
        </ClaimType>
        
        <ClaimType Id="identityProvider">
            <DisplayName>Identity Provider</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="authenticationSource">
            <DisplayName>AuthenticationSource</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Specifies whether the user was authenticated at Social IDP or local account.</UserHelpText>
        </ClaimType>  
        
        <ClaimType Id="upnUserName">
            <DisplayName>UPN User Name</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>The user name for creating user principal name.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="alternativeSecurityId">
            <DisplayName>AlternativeSecurityId</DisplayName>
            <DataType>string</DataType>
            <UserHelpText/>
        </ClaimType>
        
        <ClaimType Id="mailNickName">
            <DisplayName>MailNickName</DisplayName>
            <DataType>string</DataType>
            <UserHelpText>Your mail nick name as stored in the Azure Active Directory.</UserHelpText>
        </ClaimType>
        
        <ClaimType Id="newUser">
            <DisplayName>User is new or not</DisplayName>
            <DataType>boolean</DataType>
            <UserHelpText/>
        </ClaimType>
    <!--</ClaimsSchema>-->

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

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

   <!--<ClaimsTransformations>-->
       ...
       <ClaimsTransformation Id="CreateRandomUPNUserName" TransformationMethod="CreateRandomString">
           <InputParameters>
               <InputParameter Id="randomGeneratorType" DataType="string" Value="GUID" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   
       <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>
       
       <ClaimsTransformation Id="CreateUserPrincipalName" TransformationMethod="FormatStringClaim">
           <InputClaims>
               <InputClaim ClaimTypeReferenceId="upnUserName" TransformationClaimType="inputClaim" />
           </InputClaims>
           <InputParameters>
               <InputParameter Id="stringFormat" DataType="string" Value="cpim_{0}@{RelyingPartyTenantId}" />
           </InputParameters>
           <OutputClaims>
               <OutputClaim ClaimTypeReferenceId="userPrincipalName" TransformationClaimType="outputClaim" />
           </OutputClaims>
       </ClaimsTransformation>
   <!--</ClaimsTransformations>-->

Мы определили три преобразования утверждений, которые мы используем для создания значений alternativeSecurityId и userPrincipalName утверждений. Эти утвержденияTransformation вызываются в техническом профиле OAuth2 на шаге 3.3.

Шаг 3.3. Настройка поставщика утверждений Facebook

Чтобы пользователи могли войти с помощью учетной записи Facebook, необходимо определить учетную запись в качестве поставщика утверждений, с которым Azure AD B2C может взаимодействовать через конечную точку. Вы можете определить учетную запись Facebook в качестве поставщика утверждений.

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

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <!-- The following Domain element allows this profile to be used if the request comes with domain_hint 
                    query string parameter, e.g. domain_hint=facebook.com  -->
            <Domain>facebook.com</Domain>
            <DisplayName>Facebook</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="Facebook-OAUTH">
                <!-- The text in the following DisplayName element is shown to the user on the claims provider 
                        selection screen. -->
                <DisplayName>Facebook</DisplayName>
                <Protocol Name="OAuth2" />
                <Metadata>
                    <Item Key="ProviderName">facebook</Item>
                    <Item Key="authorization_endpoint">https://www.facebook.com/dialog/oauth</Item>
                    <Item Key="AccessTokenEndpoint">https://graph.facebook.com/oauth/access_token</Item>
                    <Item Key="HttpBinding">GET</Item>
                    <Item Key="UsePolicyInRedirectUri">0</Item>                
                    <Item Key="client_id">facebook-app-id</Item>
                    <Item Key="scope">email public_profile</Item>
                    <Item Key="ClaimsEndpoint">https://graph.facebook.com/me?fields=id,first_name,last_name,name,email</Item>
                    <Item Key="AccessTokenResponseFormat">json</Item>
                </Metadata>
                <CryptographicKeys>
                    <Key Id="client_secret" StorageReferenceId="facebook-policy-key" />
                </CryptographicKeys>
                <InputClaims />
                <OutputClaims>
                    <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
                    <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
                    <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
                    <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
                    <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
                    <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="facebook.com" AlwaysUseDefaultValue="true" />
                    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
                </OutputClaims>
                <OutputClaimsTransformations>
                    <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
                    <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
                    <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
                </OutputClaimsTransformations>
                </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Замена:

facebook-app-id значение Facebook appID , полученное на шаге 1.
facebook-policy-key с именем ключа политики Facebook, полученного на шаге 2.

Обратите внимание на преобразования утверждений, определенные на шаге 3.2 в OutputClaimsTransformations коллекции.

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

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

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

    <TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
        <DisplayName>Azure Active Directory technical profile for handling social accounts</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>
        </Metadata>        

        <CryptographicKeys>
            <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
        </CryptographicKeys>
        <InputClaims>
            <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
        </InputClaims>
        <PersistedClaims>
            <!-- Required claims -->
            <PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
            <PersistedClaim ClaimTypeReferenceId="userPrincipalName" />
            <PersistedClaim ClaimTypeReferenceId="mailNickName" DefaultValue="unknown" />
            <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />

            <!-- Optional claims -->
            <PersistedClaim ClaimTypeReferenceId="givenName" />
            <PersistedClaim ClaimTypeReferenceId="surname" />
        </PersistedClaims>
        <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="objectId" />
            <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated" />
        </OutputClaims>

    </TechnicalProfile>

Мы добавили новый технический профиль AAD-UserWriteUsingAlternativeSecurityId Microsoft Entra, который записывает новую учетную запись социальной сети в идентификатор Microsoft Entra ID.

Замените B2C_1A_TokenSigningKeyContainer ключом подписи маркера, созданным в разделе "Настройка подписи".

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

   <TechnicalProfile Id="AAD-UserReadUsingAlternativeSecurityId">
       <DisplayName>Azure Active Directory</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="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
       </Metadata>
       <CryptographicKeys>
           <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
           </CryptographicKeys>
       <InputClaims>
           <InputClaim ClaimTypeReferenceId="alternativeSecurityId" PartnerClaimType="alternativeSecurityId" Required="true" />
       </InputClaims>
       <OutputClaims>
           <!-- Required claims -->
           <OutputClaim ClaimTypeReferenceId="objectId" />

           <!-- Optional claims -->
           <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
           <OutputClaim ClaimTypeReferenceId="displayName" />
           <OutputClaim ClaimTypeReferenceId="givenName" />
           <OutputClaim ClaimTypeReferenceId="surname" />
       </OutputClaims>
   </TechnicalProfile>

Мы добавили новый технический профиль AAD-UserReadUsingAlternativeSecurityId Microsoft Entra, который считывает новую учетную запись социальной сети из идентификатора Microsoft Entra. Он используется alternativeSecurityId в качестве уникального идентификатора для социальной учетной записи.

Замените B2C_1A_TokenSigningKeyContainer ключом подписи маркера, созданным в разделе "Настройка подписи".

Шаг 3.5. Настройка определения контента

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

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

    <ContentDefinition Id="socialAccountsignupContentDefinition">
        <LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
        <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
        <DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.7</DataUri>
        <Metadata>
            <Item Key="DisplayName">Collect information from user page alongside those from social Idp.</Item>
        </Metadata>
    </ContentDefinition>

Мы используем это определение содержимого в качестве метаданных в самозаверяемом техническом профиле на следующем шаге (шаг 3.6).

Шаг 3.6. Настройка самозаверяющего технического профиля

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

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

    <!--<ClaimsProviders>-->
        ...
        <ClaimsProvider>
            <DisplayName>Self Asserted for social sign in</DisplayName>
            <TechnicalProfiles>
                <TechnicalProfile Id="SelfAsserted-Social">
                    <DisplayName>Collect more info during social signup</DisplayName>
                    <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    <Metadata>
                      <Item Key="ContentDefinitionReferenceId">socialAccountsignupContentDefinition</Item>
                    </Metadata>
                    <CryptographicKeys>
                      <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
                    </CryptographicKeys>
                    <InputClaims>
                      <!-- These claims ensure that any values retrieved in the previous steps (e.g. from an external IDP) are prefilled. 
                           Note that some of these claims may not have any value, for example, if the external IDP did not provide any of
                           these values, or if the claim did not appear in the OutputClaims section of the IDP.
                           In addition, if a claim is not in the InputClaims section, but it is in the OutputClaims section, then its
                           value will not be prefilled, but the user will still be prompted for it (with an empty value). -->
                      <InputClaim ClaimTypeReferenceId="displayName" />
                      <InputClaim ClaimTypeReferenceId="givenName" />
                      <InputClaim ClaimTypeReferenceId="surname" />
                    </InputClaims>
                    <!---User will be asked to input or update these values-->
                    <DisplayClaims>
                        <DisplayClaim ClaimTypeReferenceId="displayName"/>
                        <DisplayClaim ClaimTypeReferenceId="givenName"/>
                        <DisplayClaim ClaimTypeReferenceId="surname"/>
                    </DisplayClaims>

                    <OutputClaims>
                      <!-- These claims are not shown to the user because their value is obtained through the "ValidationTechnicalProfiles"
                           referenced below, or a default value is assigned to the claim. A claim is only shown to the user to provide a 
                           value if its value cannot be obtained through any other means. -->
                      <OutputClaim ClaimTypeReferenceId="objectId" />
                      <OutputClaim ClaimTypeReferenceId="newUser" />
                      <!---<OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />-->
          
                      <!-- Optional claims. These claims are collected from the user and can be modified. If a claim is to be persisted in the directory after having been 
                           collected from the user, it needs to be added as a PersistedClaim in the ValidationTechnicalProfile referenced below, i.e. 
                           in AAD-UserWriteUsingAlternativeSecurityId. -->
                      <OutputClaim ClaimTypeReferenceId="displayName" />
                      <OutputClaim ClaimTypeReferenceId="givenName" />
                      <OutputClaim ClaimTypeReferenceId="surname" />
                    </OutputClaims>
                    <ValidationTechnicalProfiles>
                      <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                    </ValidationTechnicalProfiles>
                  </TechnicalProfile>
            </TechnicalProfiles>
        </ClaimsProvider>
    <!--</ClaimsProviders>-->

Добавленный поставщик утверждений содержит самоутверждаемый технический профиль. SelfAsserted-Social Самоутверждаемый технический профиль использует AAD-UserWriteUsingAlternativeSecurityId Технический профиль в качестве технического профиля проверки. Таким образом, AAD-UserWriteUsingAlternativeSecurityId технический профиль выполняется, когда пользователь нажимает кнопку "Продолжить " (см. снимок экрана на шаге 7).

Кроме того, обратите внимание, что мы добавили определение содержимого, socialAccountsignupContentDefinitionкоторое мы настроили на шаге 3.5 в разделе метаданных.

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

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

    <!--<OrchestrationSteps>-->
        ...
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp">
            <ClaimsProviderSelections>
                <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
            </ClaimsProviderSelections>
        </OrchestrationStep>
    
        <OrchestrationStep Order="2" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="FacebookExchange"
                    TechnicalProfileReferenceId="Facebook-OAUTH" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- For social IDP authentication, attempt to find the user account in the
        directory. -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <!-- Show self-asserted page only if the directory does not have the user account
        already (i.e. we don't have an objectId).  -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
            </ClaimsExchanges>
        </OrchestrationStep>
    
        <OrchestrationStep Order="5" Type="ClaimsExchange">
            <Preconditions>
                <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                    <Value>objectId</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
            </Preconditions>
            <ClaimsExchanges>
                <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
            </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="6" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
    <!--</OrchestrationSteps>-->

В оркестрации мы использовали ссылку на технические профили, позволяющие пользователю входить с помощью учетной записи социальных параметров.

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

Шаг оркестрации 1 . Этот шаг включает ClaimsProviderSelections элемент, в котором перечислены доступные параметры входа, которые пользователь может выбрать. В этом случае у нас есть только один вариант, FacebookExchangeпоэтому при запуске политики пользователи отправляются непосредственно в Facebook.com на шаге 2, как показано атрибутом TargetClaimsExchangeId .
Шаг 2Facebook-OAUTH. Технический профиль выполняется, поэтому пользователь перенаправляется на Facebook для входа.
Шаг 3. На шаге 3 AAD-UserReadUsingAlternativeSecurityId технический профиль выполняется, чтобы попытаться прочитать учетную запись пользователя из хранилища идентификатора Microsoft Entra ID. Если обнаружена учетная запись социальной сети, objectId возвращается в качестве выходного утверждения.
Шаг оркестрации 4 . Этот шаг выполняется, если пользователь еще не существует (objectId не существует). В нем показана форма, которая собирает дополнительные сведения от пользователя или обновляет аналогичную информацию, полученную из социальной учетной записи.
Шаг оркестрации 5 . Этот шаг выполняется, если пользователь еще не существует (objectId не существует), поэтому AAD-UserWriteUsingAlternativeSecurityId технический профиль выполняет запись социальной учетной записи в идентификатор Microsoft Entra ID.
Шаг оркестрации 6. Наконец, шаг 6 собирает и возвращает токен JWT в конце выполнения политики.

Шаг 5. Обновление утверждений выходных данных проверяющей стороны

ContosoCustomPolicy.XML В файле найдите RelyingParty элемент и замените всю коллекцию выходных утверждений следующим кодом:

    <OutputClaim ClaimTypeReferenceId="displayName" />
    <OutputClaim ClaimTypeReferenceId="givenName" />
    <OutputClaim ClaimTypeReferenceId="surname" />
    <OutputClaim ClaimTypeReferenceId="email" />
    <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
    <OutputClaim ClaimTypeReferenceId="identityProvider" />

Мы добавили поставщика удостоверений (identityProvider) в качестве выходного утверждения, поэтому он будет включен в токен JWT, возвращенный приложению проверяющей стороны.

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

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

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

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

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

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

Введите или обновите отображаемое имя, заданное имя и фамилию, а затем нажмите кнопку "Продолжить".

После завершения выполнения политики вы будете перенаправлены https://jwt.msв , и вы увидите декодированные токены JWT. Он выглядит примерно так, как показано в следующем фрагменте маркера JWT:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "pxLOMWFgP4T..."
}.{
   ...
  "acr": "b2c_1a_contosocustompolicy",
   ...
  "given_name": "Maurice",
  "family_name": "Paulet",
  "name": "Maurice Paulet",
  "email": "maurice.p@contoso.com",
  "idp": "facebook.com"
}.[Signature]

Обратите внимание, "idp": "facebook.com"что поставщик удостоверений включен в токен JWT.

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

Чтобы добавить объединенную локальную и социальную учетную запись, выполните следующие действия.

ContosoCustomPolicy.XML В файле найдите AccountTypeInputCollector самоутверждаемый технический профиль, а затем добавьте authenticationSource утверждение в коллекцию выходных утверждений с помощью следующего кода:
```
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localIdpAuthentication" AlwaysUseDefaultValue="true" />
```

UserJourneys В разделе добавьте новое путешествие пользователя с LocalAndSocialSignInAndSignUp помощью следующего кода:

    <!--<UserJourneys>-->
        ...
        <UserJourney Id="LocalAndSocialSignInAndSignUp">
            <OrchestrationSteps>
                <!--Orchestration steps will be added here-->
            </OrchestrationSteps>
        </UserJourney>
    <!--</UserJourneys>-->

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

    <!--<UserJourneys>
        ...
        <UserJourney Id="LocalAndSocialSignInAndSignUp">
            <OrchestrationSteps>-->
            <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="SignupOrSigninContentDefinition">
                <ClaimsProviderSelections>
                  <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
                  <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
                </ClaimsProviderSelections>
                <ClaimsExchanges>
                  <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="UserSignInCollector" />
                </ClaimsExchanges>
            </OrchestrationStep>
            <!-- Check if the user has selected to sign in using one of the social providers -->
            <OrchestrationStep Order="2" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
                    <ClaimsExchange Id="AccountTypeInputCollectorClaimsExchange" TechnicalProfileReferenceId="AccountTypeInputCollector"/>
                </ClaimsExchanges>
            </OrchestrationStep>

            <!--For Local sign in option start-->

            <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>work</Value>
                      <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</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>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="UserInformationCollector" />
                </ClaimsExchanges>
            </OrchestrationStep>  

            <OrchestrationStep Order="5" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>socialIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserReaderExchange" TechnicalProfileReferenceId="AAD-UserRead"/>
                </ClaimsExchanges>
            </OrchestrationStep>                
            <!--For Local sign in option end-->

            <!--For social sign in option start-->
            <!-- For social IDP authentication, attempt to find the user account in the
            directory. -->
            <OrchestrationStep Order="6" Type="ClaimsExchange">
               <Preconditions>
                <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                    <Value>authenticationSource</Value>
                    <Value>localIdpAuthentication</Value>
                    <Action>SkipThisOrchestrationStep</Action>
                </Precondition>
               </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <!-- Show self-asserted page only if the directory does not have the user account
            already (i.e. we do not have an objectId).  -->
            <OrchestrationStep Order="7" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>localIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
                </ClaimsExchanges>
            </OrchestrationStep>

            <OrchestrationStep Order="8" Type="ClaimsExchange">
                <Preconditions>
                    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
                        <Value>objectId</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                    <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
                        <Value>authenticationSource</Value>
                        <Value>localIdpAuthentication</Value>
                        <Action>SkipThisOrchestrationStep</Action>
                    </Precondition>
                </Preconditions>
                <ClaimsExchanges>
                    <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
                </ClaimsExchanges>
            </OrchestrationStep>
            <!--For social sign in option end-->
            <OrchestrationStep Order="9" Type="ClaimsExchange">
                <ClaimsExchanges>
                <ClaimsExchange Id="GetMessageClaimsExchange" TechnicalProfileReferenceId="UserInputMessageClaimGenerator"/>
                </ClaimsExchanges>          
            </OrchestrationStep>

            <OrchestrationStep Order="10" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
           <!-- </OrchestrationSteps>
        </UserJourney>
    </UserJourneys>-->

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

В разделе измените RelyingParty значение DefaultUserJourney наReferenceIdLocalAndSocialSignInAndSignUp
Используйте процедуру на шаге 6 и шаге 7 для отправки и запуска политики. После запуска политики отобразится экран, аналогичный следующему снимку экрана.

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

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

Узнайте больше о том, как определить технический профиль OAuth2 в пользовательской политике Azure Active Directory B2C.

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

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

Шаг 1. Создание приложения Facebook

Шаг 2. Создание ключа политики Facebook

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

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

Шаг 3.3. Настройка поставщика утверждений Facebook

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

Шаг 3.5. Настройка определения контента

Шаг 3.6. Настройка самозаверяющего технического профиля

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

Шаг 5. Обновление утверждений выходных данных проверяющей стороны

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

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

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

Обратная связь

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

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

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

Шаг 1. Создание приложения Facebook

Шаг 2. Создание ключа политики Facebook

Шаг 3. Настройка входа в Facebook

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

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

Шаг 3.3. Настройка поставщика утверждений Facebook

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

Шаг 3.5. Настройка определения контента

Шаг 3.6. Настройка самозаверяющего технического профиля

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

Шаг 5. Обновление утверждений выходных данных проверяющей стороны

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

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

Объединенный локальный и социальный вход

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

Обратная связь

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