إعداد تدفق الاشتراك وتسجيل الدخول باستخدام حساب اجتماعي باستخدام نهج 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 وApp Secret. تخطي المتطلبات الأساسية وبقية الخطوات في مقالة إعداد التسجيل وتسجيل الدخول باستخدام حساب 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 . يتم استدعاء عمليات تحويل المطالبات هذه في ملف التعريف الفني 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.

استبدل B2C_1A_TokenSigningKeyContainer بمفتاح توقيع الرمز المميز الذي أنشأته في تكوين التوقيع.

في ContosoCustomPolicy.XML الملف، أضف ملف تعريف تقني آخر من Microsoft Entra بعد AAD-UserWriteUsingAlternativeSecurityId Technical Profile باستخدام التعليمات البرمجية التالية:

   <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 ID. ويستخدم 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 .
خطوة التنسيق 2 - Facebook-OAUTH يتم تنفيذ ملف التعريف التقني، لذلك تتم إعادة توجيه المستخدم إلى Facebook لتسجيل الدخول.
خطوة التنسيق 3 - في الخطوة 3، AAD-UserReadUsingAlternativeSecurityId يتم تنفيذ ملف التعريف الفني لمحاولة قراءة الحساب الاجتماعي للمستخدم من تخزين معرف Microsoft Entra. إذا تم العثور على الحساب الاجتماعي، objectId يتم إرجاعه كمطالبة إخراج.
خطوة التنسيق 4 - يتم تشغيل هذه الخطوة إذا لم يكن المستخدم موجودا بالفعل (objectId غير موجود). يعرض النموذج الذي يجمع المزيد من المعلومات من المستخدم أو يحدث معلومات مماثلة تم الحصول عليها من الحساب الاجتماعي.
خطوة التزامن 5 - يتم تشغيل هذه الخطوة إذا لم يكن المستخدم موجودا بالفعل (objectId غير موجود)، لذلك AAD-UserWriteUsingAlternativeSecurityId ينفذ ملف التعريف التقني لكتابة الحساب الاجتماعي في معرف Microsoft Entra.
خطوة التزامن 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 - اختبار النهج

تسجيل دخول محلي واجتماعي مشترك

الخطوات التالية

الملاحظات

الموارد الإضافية