إنشاء تفريع في رحلة المستخدم باستخدام نهج Azure Active Directory B2C المخصص

يمكن للمستخدمين المختلفين من نفس التطبيق اتباع رحلات مستخدم مختلفة اعتمادا على قيم البيانات في نهج مخصص. تسمح لك النهج المخصصة ل Azure Active Directory B2C (Azure AD B2C) بتمكين ملف تعريف تقني أو تعطيله بشكل مشروط لتحقيق هذه الإمكانية. على سبيل المثال، في التحقق من صحة مدخلات المستخدم باستخدام نهج Azure AD B2C المخصص، استخدمنا Precondition لتحديد ما إذا كان يجب علينا تشغيل ملف تعريف تقني للتحقق من الصحة استنادا إلى قيمة مطالبة accountType أم لا.

يوفر ملف التعريف الفني أيضا عنصرا EnabledForUserJourneys للسماح لك بتحديد ما إذا كان يجب تشغيل ملف تعريف تقني أم لا. EnabledForUserJourneys يحتوي العنصر على إحدى القيم الخمس بما في ذلك OnClaimsExistence، والتي تستخدمها لتحديد أنه يجب تشغيل ملف تعريف تقني فقط عند وجود مطالبة معينة محددة في ملف التعريف الفني. تعرف على المزيد حول عنصر EnabledForUserJourneys الخاص بملف التعريف التقني.

نظرة عامة على السيناريو

في مقالة نهج التحقق من صحة مدخلات المستخدم باستخدام نهج Azure AD B2C المخصص ، يقوم المستخدم بإدخال تفاصيله في شاشة واحدة. في هذه المقالة، يحتاج المستخدم أولا إلى تحديد نوع الحساب الخاص به أو حساب موظف Contoso أو الحساب الشخصي. يمكن للمستخدم الذي يحدد حساب موظف Contoso المتابعة لتقديم مزيد من التفاصيل. ومع ذلك، يحتاج المستخدم الذي يحدد الحساب الشخصي إلى توفير رمز وصول صالح للدعوة قبل أن يتمكن من المتابعة لتقديم مزيد من التفاصيل. ومن ثم، يرى المستخدمون الذين يستخدمون نوع الحساب الشخصي واجهة مستخدم إضافية لإكمال رحلتهم.

في هذه المقالة، ستتعلم كيفية استخدام EnabledForUserJourneys عنصر داخل ملف تعريف تقني لإنشاء تجارب مستخدم مختلفة استنادا إلى قيمة مطالبة.

المتطلبات الأساسية

• إذا لم يكن لديك واحد بالفعل ، فأنشئ مستأجر Azure AD B2C مرتبطًا باشتراك Azure الخاص بك.

• تسجيل تطبيق ويب، وتمكين تفعيل المنحة الضمنية لرمز المعرّف. بالنسبة إلى عنوان URI لإعادة التوجيه، استخدم https://jwt.ms.

• يجب أن يكون لديك Visual Studio Code (VS Code) مثبتا على الكمبيوتر الخاص بك.

• أكمل الخطوات في التحقق من صحة مدخلات المستخدم باستخدام نهج Azure AD B2C المخصص. هذه المقالة هي جزء من إنشاء سلسلة إرشاد إرشادية خاصة بالنهج المخصصة وتشغيلها.

إشعار

هذه المقالة هي جزء من سلسلة دليل كيفية إنشاء وتشغيل النهج المخصصة الخاصة بك في Azure Active Directory B2C. نوصي ببدء تشغيل هذه السلسلة من المقالة الأولى.

الخطوة 1 - الإعلان عن المطالبات

يحتاج المستخدم الذي يحدد الحساب الشخصي إلى توفير رمز وصول صالح. لذلك، نحن بحاجة إلى مطالبة للاحتفاظ بهذه القيمة:

1. في VS Code، افتح ContosoCustomPolicy.XML الملف.

2. في ClaimsSchema القسم ، أعلن عن مطالبات accessCode وisValidAccessCode باستخدام التعليمات البرمجية التالية:

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

الخطوة 2 - تحديد تحويلات المطالبات

ClaimsTransformations حدد موقع العنصر، وأضف تحويلات المطالبات التالية:

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

لقد حددنا تحويلين للمطالبات، CheckIfIsValidAccessCode و ThrowIfIsNotValidAccessCode. يستخدم CheckIfIsValidAccessCode أسلوب تحويل CompareClaimToValue لمقارنة إدخال رمز الوصول من قبل المستخدم بقيمة ثابتة 88888 (دعونا نستخدم هذه القيمة للاختبار) وتعيين true أو false إلى مطالبة isValidAccessCode. يتحقق ThrowIfIsNotValidAccessCode مما إذا كانت قيمتان منطقيتان لمطالبتين متساويتين أم لا، ويطرح استثناء إذا لم تكنا متساويتين.

الخطوة 3 - تكوين ملفات التعريف التقنية أو تحديثها

تحتاج الآن إلى ملفي تعريف تقنيين جديدين مؤكدين ذاتيا، أحدهما لجمع نوع الحساب، والآخر لجمع رمز الوصول من المستخدم. تحتاج أيضا إلى ملف تعريف تقني لنوع تحويل المطالبات جديد للتحقق من صحة رمز وصول المستخدم عن طريق تنفيذ تحويلات المطالبات التي قمت بتعريفها في الخطوة 2. الآن بعد أن جمعنا نوع الحساب في ملف تعريف تقني مختلف مؤكد ذاتيا، نحتاج إلى تحديث UserInformationCollector ملف التعريف الفني المؤكد ذاتيا لمنعه من جمع نوع الحساب.

1. ClaimsProviders حدد موقع العنصر، ثم أضف موفر مطالبات جديد باستخدام التعليمات البرمجية التالية:

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

   لقد قمنا بتكوين ملفي تعريف تقنيين، AccessCodeInputCollector و CheckAccessCodeViaClaimsTransformationChecker. نطلق على ملف التعريف الفني CheckAccessCodeViaClaimsTransformationChecker كملف تعريف تقني للتحقق من الصحة من داخل ملف التعريف الفني AccessCodeInputCollector . CheckAccessCodeViaClaimsTransformationChecker نفسه من نوع ملف التعريف الفني لتحويل المطالبات، والذي ينفذ تحويلات المطالبات التي حددناها في الخطوة 2.

   AccessCodeInputCollector هو ملف تعريف فني مؤكد ذاتيا يستخدم لجمع رمز وصول من المستخدم. يتضمن EnabledForUserJourneys العنصر الذي تم تعيينه إلى OnClaimsExistence. يتضمن عنصره Metadata مطالبة (accountType) وقيمتها (الشخصية) التي تنشط ملف التعريف التقني هذا.

2. ClaimsProviders حدد موقع العنصر، ثم أضف موفر مطالبات جديد باستخدام التعليمات البرمجية التالية:

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

   لقد قمنا بتكوين ملف تعريف تقني مؤكد ذاتيا، والذي AccountTypeInputCollectorيجمع نوع حساب المستخدم. إنها قيمة أنواع الحسابات التي تحدد ما إذا كان AccessCodeInputCollector يجب تنشيط ملف التعريف الفني المؤكد ذاتيا.

3. لمنع UserInformationCollector ملف التعريف الفني المؤكد ذاتيا من جمع نوع الحساب، حدد موقع UserInformationCollector الملف الفني المؤكد ذاتيا، ثم:

   1. قم بإزالة accountType مطالبة العرض، <DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/> من DisplayClaims المجموعة.

   2. قم بإزالة accountType مطالبة الإخراج، <OutputClaim ClaimTypeReferenceId="accountType"/>، من OutputClaims المجموعة.

الخطوة 4 - تحديث خطوات تزامن رحلة المستخدم

الآن بعد أن قمت بإعداد ملفات التعريف التقنية الخاصة بك، تحتاج إلى تحديث خطوات تزامن رحلة المستخدم:

1. حدد موقع رحلة المستخدم وأضف HelloWorldJourney استبدال جميع خطوات التنسيق بالتعليمات البرمجية التالية:

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

   توضح خطوات التزامن أننا نستدعي ملف التعريف الفني بالترتيب الذي تظهره سمة خطوات Order التزامن. ومع ذلك، AccessCodeInputCollector يتم تنشيط ملف التعريف الفني إذا حدد المستخدم نوع الحساب الشخصي .

الخطوة 5 - تحميل ملف نهج مخصص

اتبع الخطوات الواردة في تحميل ملف نهج مخصص لتحميل ملف النهج الخاص بك. إذا كنت تقوم بتحميل ملف بنفس اسم الملف الموجود بالفعل في المدخل، فتأكد من تحديد الكتابة فوق النهج المخصص إذا كان موجودا بالفعل.

الخطوة 6 - اختبار النهج المخصص

اتبع الخطوات الواردة في اختبار النهج المخصص لاختبار النهج المخصص:

1. في الشاشة الأولى، بالنسبة إلى نوع الحساب، حدد حساب شخصي.
2. بالنسبة إلى Access Code، أدخل 88888، ثم حدد Continue.
3. أدخل بقية التفاصيل كما هو مطلوب، ثم حدد متابعة. بعد انتهاء النهج من التنفيذ، تتم إعادة توجيهك إلى https://jwt.ms، وترى رمز JWT المميز الذي تم فك ترميزه.
4. كرر الخطوة 5، ولكن هذه المرة، حدد نوع الحساب، وحدد حساب موظف Contoso، ثم اتبع المطالبات.

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

في الخطوة 3، نقوم بتمكين ملف التعريف الفني أو تعطيله باستخدام EnabledForUserJourneys العنصر . بدلا من ذلك، يمكنك استخدام الشروط المسبقة داخل خطوات تزامن رحلة المستخدم لتنفيذ خطوة تزامن أو تخطيها كما نتعلم لاحقا في هذه السلسلة.

بعد ذلك، تعرف على:

• حول الشروط المسبقة لخطوات تزامن رحلة المستخدم.

• كيفية استخدام ملف مخطط TrustFrameworkPolicy للتحقق من صحة ملفات نهج Azure AD B2C.