إنشاء تفريع في رحلة المستخدم باستخدام نهج 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 - الإعلان عن المطالبات
يحتاج المستخدم الذي يحدد الحساب الشخصي إلى توفير رمز وصول صالح. لذلك، نحن بحاجة إلى مطالبة للاحتفاظ بهذه القيمة:
في VS Code، افتح
ContosoCustomPolicy.XML
الملف.في
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
ملف التعريف الفني المؤكد ذاتيا لمنعه من جمع نوع الحساب.
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) وقيمتها (الشخصية) التي تنشط ملف التعريف التقني هذا.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
يجب تنشيط ملف التعريف الفني المؤكد ذاتيا.لمنع
UserInformationCollector
ملف التعريف الفني المؤكد ذاتيا من جمع نوع الحساب، حدد موقعUserInformationCollector
الملف الفني المؤكد ذاتيا، ثم:قم بإزالة
accountType
مطالبة العرض،<DisplayClaim ClaimTypeReferenceId="accountType" Required="true"/>
منDisplayClaims
المجموعة.قم بإزالة
accountType
مطالبة الإخراج،<OutputClaim ClaimTypeReferenceId="accountType"/>
، منOutputClaims
المجموعة.
الخطوة 4 - تحديث خطوات تزامن رحلة المستخدم
الآن بعد أن قمت بإعداد ملفات التعريف التقنية الخاصة بك، تحتاج إلى تحديث خطوات تزامن رحلة المستخدم:
حدد موقع رحلة المستخدم وأضف
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 - اختبار النهج المخصص
اتبع الخطوات الواردة في اختبار النهج المخصص لاختبار النهج المخصص:
- في الشاشة الأولى، بالنسبة إلى نوع الحساب، حدد حساب شخصي.
- بالنسبة إلى Access Code، أدخل 88888، ثم حدد Continue.
- أدخل بقية التفاصيل كما هو مطلوب، ثم حدد متابعة. بعد انتهاء النهج من التنفيذ، تتم إعادة توجيهك إلى
https://jwt.ms
، وترى رمز JWT المميز الذي تم فك ترميزه. - كرر الخطوة 5، ولكن هذه المرة، حدد نوع الحساب، وحدد حساب موظف Contoso، ثم اتبع المطالبات.
الخطوات التالية
في الخطوة 3، نقوم بتمكين ملف التعريف الفني أو تعطيله باستخدام EnabledForUserJourneys
العنصر . بدلا من ذلك، يمكنك استخدام الشروط المسبقة داخل خطوات تزامن رحلة المستخدم لتنفيذ خطوة تزامن أو تخطيها كما نتعلم لاحقا في هذه السلسلة.
بعد ذلك، تعرف على:
حول الشروط المسبقة لخطوات تزامن رحلة المستخدم.
كيفية استخدام ملف مخطط TrustFrameworkPolicy للتحقق من صحة ملفات نهج Azure AD B2C.