استكشاف أخطاء Azure AD B2C المستخدمين والتدفقات النهج المخصصة

مقالة
11/21/2023

قبل أن تبدأ استخدم اختر نوع النهجالمحدد لاختيار نوع النهج التي تقوم بإعدادها. يوفر Azure Active Directory B2C طريقتين لتحديد كيفية تفاعل المستخدمين مع تطبيقاتك: من خلال تدفقات محددة مسبقا للمستخدمين أو من خلال سياسات مخصصة قابلة للتكوين بشكل كامل. تختلف الخطوات المطلوبة في هذه المقالة لكل أسلوب.

يحتاج تطبيقك إلى معالجة أخطاء معينة قادمة من خدمة Azure B2C. تسلط هذه المقالة الضوء على بعض الأخطاء الشائعة وكيفية التعامل معها.

خطأ في إعادة تعيين كلمة المرور

يحدث هذا الخطأ عندما لا يتم تمكين self-service password reset experience في تدفق المستخدم. وبالتالي، فإن تحديد الرابط ?Forgot your password لا يؤدي إلى تدفق إعادة تعيين كلمة المرور للمستخدم. بدلاً من ذلك، يتم إرجاع رمز الخطأ AADB2C90118 إلى التطبيق الخاص بك.

يوجد حلان لهذه المشكلة:

الرد بطلب مصادقة جديد باستخدام تدفق مستخدم إعادة تعيين كلمة مرور Microsoft Azure Active Directory B2C.
استخدم تجربة إعادة تعيين كلمة مرور الخدمة الذاتية الموصى بها (SSPR).

ألغى المستخدم العملية

يمكن لخدمة Microsoft Azure Active Directory B2C أيضاً إرجاع خطأ إلى التطبيق الخاص بك عندما يقوم المستخدم بإلغاء عملية. فيما يلي أمثلة على السيناريوهات التي يقوم فيها المستخدم بعملية إلغاء:

يستخدم نهج المستخدم تجربة إعادة تعيين كلمة مرور الخدمة الذاتية الموصى بها (SSPR) مع حساب محلي للمستهلك. يحدد المستخدم الارتباط هل نسيت كلمة المرور؟ ثم يحدد الزر إلغاء قبل اكتمال تجربة تدفق المستخدم. في هذه الحالة، تقوم خدمة Microsoft Azure Active Directory B2C بإرجاع رمز الخطأ AADB2C90091 إلى التطبيق الخاص بك.
يختار المستخدم المصادقة مع موفر هوية خارجي مثل LinkedIn. حدد المستخدم الزر Cancel قبل المصادقة إلى موفر الهوية نفسه. في هذه الحالة، تقوم خدمة Microsoft Azure Active Directory B2C بإرجاع رمز الخطأ AADB2C90273 إلى التطبيق الخاص بك. تعرف على المزيد حول رموز الخطأ التي ترجعها خدمة Microsoft Azure Active Directory B2C.

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

إذا كنت تستخدم النُّهج المخصصة لدى Azure Active Directory B2C (Azure AD B2C)، فقد تواجه تحديات في استخدام تنسيق XML للغة النهج أو مشكلات تتعلق بوقت التشغيل. توضح هذه المقالة بعض الأدوات والنصائح التي يمكن أن تساعدك على اكتشاف المشكلات وحلها.

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

نظرة عامة على معرف ارتباط Azure AD B2C

معرف ارتباط B2C AD Azure هو قيمة معرف فريدة مرفقة بطلبات التخويل. يمر عبر جميع خطوات التنسيق التي يمر بها المستخدم. باستخدام معرف الارتباط، يمكنك:

تحديد نشاط تسجيل الدخول في التطبيق وتتبع أداء النهج.
ابحث عن سجلات Azure Application Insights لطلب تسجيل الدخول.
مرر معرف الارتباط إلى واجهة برمجة تطبيقات REST واستخدمه لتحديد تدفق تسجيل الدخول.

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

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

أكمل الخطوات في ابدأ العمل مع النهج المخصص في Active Directory B2C.

استدعاء معرف ارتباط Azure AD B2C

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

Screenshot of Azure AD B2C sign-in page view source.

قم بنسخ معرف الارتباط، ثم قم بمتابعة تدفق تسجيل الدخول. استخدم معرف الارتباط لمراقبة سلوك تسجيل الدخول. لمزيد من المعلومات، راجع استكشاف أخطاء Application Insights وإصلاحها.

صدى معرف ارتباط Azure AD B2C

يمكنك تضمين معرف الارتباط في رموز Azure AD B2C المميزة. لتضمين معرف الارتباط:

افتح ملف ملحقات النُهج الخاص بك. على سبيل المثال، SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
ابحث عن عنصر BuildingBlocks . إذا كان العنصر غير موجود، قم بإضافته.
حدد موقع عنصر ClaimsSchema . إذا كان العنصر غير موجود، قم بإضافته.

أضف مطالبة معرف الارتباط للعنصر ClaimsSchema.

<!-- 
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="correlationId">
      <DisplayName>correlation ID</DisplayName>
      <DataType>string</DataType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks>-->

افتح ملف جهة الاعتماد لنهجك. على سبيل المثال، ملف SocialAndLocalAccounts/SignUpOrSignIn.xml. سيتم إضافة مطالبة الإخراج إلى الرمز المميز بعد رحلة مستخدم ناجحة وإرسالها إلى التطبيق. تعديل عنصر ملف التعريف التقني داخل قسم جهة الاعتماد لإضافة correlationId كمطالبة إخراج.
```
<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      ...
      <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>
```

استكشاف الأخطاء وإصلاحها باستخدام Application Insights

تشخيص المشاكل مع النهج المخصصة، باستخدام Application Insights. يتتبع Application Insights نشاط رحلة مستخدم النهج المخصص. يوفر طريقة لتشخيص الاستثناءات ومراقبة تبادل المطالبات بين Azure AD B2C وموفري المطالبات المتنوعين. يتم تعريف موفري المطالبات بواسطة ملفات التعريف التقنية، مثل موفري الهوية والخدمات المستندة إلى واجهة برمجة التطبيقات ودليل مستخدم Azure AD B2C والخدمات الأخرى.

نوصي بتثبيت ملحق Azure AD B2C لـ VS Code. مع ملحق B2C AD Azure، يتم تنظيم السجلات لك حسب اسم النهج ومعرف الارتباط (Application Insights يعرض الرقم الأول من معرف الارتباط) والطابع الزمني للسجلات. تساعدك هذه الميزة في العثور على السجل ذي الصلة استنادًا إلى الطابع الزمني المحلي وعرض رحلة المستخدم كما تم تنفيذها بواسطة Azure AD B2C.

إشعار

هناك تأخير قصير، عادة أقل من خمس دقائق، قبل أن تتمكن من رؤية سجلات جديدة في Application Insights.
لقد طور المجتمع ملحق Visual Studio Code لـ Azure AD B2C لمساعدة مطوري الهوية. الملحق غير مدعوم من قبل Microsoft ويتم توفيره بدقة كما هو.

يمكن أن يصدر تدفق تسجيل دخول واحد أكثر من تتبع واحد لـ Azure Application Insights. في لقطة الشاشة التالية، لدى نهج B2C_1A_signup_signin ثلاثة سجلات. يمثل كل سجل جزءًا من تدفق تسجيل الدخول.

تظهر لقطة الشاشة التالية ملحق Azure AD B2C لـ VS Code مع مستكشف تتبع Azure Application Insights.

Screenshot of Azure AD B2C extension for VS Code with Azure Application Insights trace.

تصفية سجل التتبع

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

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter highlighting.

يؤدي التمرير فوق مربع عامل التصفية وتحديد تمكين عامل التصفية على النوع إلى إظهار سجلات التتبع المطابقة فقط. استخدم زر 'X' Clear لمسح عامل التصفية.

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter.

تفاصيل سجل تتبع Application Insights

عند تحديد تتبع Azure Application Insights، يفتح الملحق إطار تفاصيل Application Insights بالمعلومات التالية:

Application Insights - معلومات عامة حول سجل التتبع، بما في ذلك اسم النهج معرف الارتباط ومعرّف تتبع Azure Application Insights والطابع الزمني.
ملفات التعريف الفنية - قائمة التشكيلات الفنية التي تظهر في سجل التتبع.
المطالبات - القائمة الأبجدية للمطالبات التي تظهر في سجل التتبع وقيمها. إذا ظهرت مطالبة في سجل التتبع عدة مرات بقيم مختلفة، تعين علامة => أحدث قيمة. يمكنك مراجعة هذه المطالبات لتحديد ما إذا تم تعيين قيم المطالبة المتوقعة بشكل صحيح. على سبيل المثال، إذا كان لديك شرط مسبق يتحقق من قيمة المطالبة، في حين يمكن أن يساعدك قسم المطالبات في تحديد سبب عمل التدفق المتوقع بشكل مختلف.
تحويل المطالبات - قائمة تحويلات المطالبات التي تظهر في سجل التتبع. يحتوي كل تحويل مطالبات على مطالبات الإدخال ومعلمات الإدخال ومطالبات الإخراج. ويعطي قسم تحويل المطالبات تفاصيل على البيانات المرسلة ونتائج تحويل المطالبات.
الرموز المميزة - قائمة الرموز المميزة التي تظهر في سجل التتبع. تتضمن الرموز المميزة OAuth الموحد الأساسي ورموز مميزة لموفري هوية OpenId Connect. يعطي الرمز المميز لموفري الهوية الموحد تفاصيل حول كيفية إرجاع موفر الهوية للمطالبات إلى Azure AD B2C حتى تتمكن من تعيين مطالبات إخراج ملف التعريف التقني لموفر الهوية.
استثناءات - قائمة الاستثناءات أو الأخطاء الفادحة التي تظهر في سجل التتبع.
Application Insights JSON - البيانات الأولية المرتجعة من Application Insights.

تظهر لقطة الشاشة التالية مثالًا على إطار تفاصيل سجل تتبع Application Insights.

Screenshot of Azure AD B2C extension Azure AD B2C trace report.

استكشاف أخطاء رموز JWT المميزة وإصلاحها

لأغراض التحقق من صحة الرمز المميز JWT وتصحيح الأخطاء، يمكنك فك تشفير رموز JWT المميزة باستخدام موقع مثل https://jwt.ms. إنشاء تطبيق اختبار يمكنه إعادة توجيه إلى https://jwt.ms لفحص الرمز المميز. إذا لم تكن قد فعلت ذلك مسبقًا، يمكنك تسجيل تطبيق الويب، وتمكين المنح المضمن للرمز المميز للمعرّف.

Screenshot of JWT token preview.

استخدم تشغيل الآن وhttps://jwt.ms لاختبار نهجك بشكل مستقل عن تطبيق الويب أو الجوال. يعمل هذا الموقع مثل تطبيق جهة اعتماد. يعرض محتويات رمز ويب JSON المميز (JWT) الذي ينشئه نهج Azure AD B2C.

استكشاف أخطاء بروتوكول SAML وإصلاحها

للمساعدة في تكوين وتصحيح التكامل مع مزود الخدمة الخاص بك، يمكنك استخدام ملحق مستعرض لبروتوكول SAML، على سبيل المثال، ملحق SAML DevTools لـ Chrome، أو SAML-tracer لـ FireFox، أو Edge أو أدوات IE Developer.

توضح لقطة الشاشة التالية كيفية لملحق SAML DevTools أن يقدم طلب SAML الذي يرسله Azure AD B2C إلى موفر الهوية واستجابة SAML.

Screenshot of SAML protocol trace log.

باستخدام هذه الأدوات، يمكنك التحقق من التكامل بين التطبيق الخاص بك وAzure AD B2C. على سبيل المثال:

تحقق مما إذا كان طلب SAML يحتوي على توقيع وحدد الخوارزمية المستخدمة لتسجيل الدخول في طلب التفويض.
تحقق مما إذا كان Microsoft Azure Active Directory B2C يُرجع رسالة خطأ.
تحقق مما إذا كان قسم التأكيد مشفرًا.
استدعاء اسم المطالبات التي تُرجع موفر الهوية.

يمكنك أيضا تتبع تبادل الرسائل بين مستعرض العميل وAzure AD B2C، مع Fiddler. يمكن أن تساعدك في الحصول على إشارة إلى أين تفشل رحلتك في خطوات التزامن الخاصة بك.

استكشاف أخطاء صلاحية النهج وإصلاحها

بعد الانتهاء من تطوير النهج الخاص بك، يمكنك تحميل النهج إلى Azure AD B2C. قد تكون هناك بعض المشكلات في النهج الخاص بك، ولكن يمكنك صلاحية النهج قبل تحميله.

الخطأ الأكثر شيوعاً في إعداد النُهج المخصصة هو XML المنسق بشكل غير صحيح. محرر XML جيد أمر ضروري تقريبًا. يعرض XML في الأصل، محتوى رموز الألوان، يقوم بتصفية المصطلحات الشائعة مسبقا، ويحافظ على فهرسة عناصر XML، ويمكن التحقق من صحتها مقابل مخطط XML.

نوصي باستخدام Visual Studio Code. ثم قم بتثبيت ملحق XML، مثل دعم لغة XML باستخدام Red Hat. ملحق XML يمكنك من التحقق من صحة مخطط XML قبل تحميل ملف XML الخاص بك باستخدام تعريف مخطط XSD للنهج المخصص.

يمكنك استخدام استراتيجية إقران ملف XML لربط ملف XML XSD بإضافة الإعدادات التالية إلى ملف VS Code settings.json. للقيام بذلك:

من VS Code، حدد تفضيلات الملف>> الإعدادات. لمزيد من المعلومات، راجع إعدادت مساحة العمل والمستخدم.
ابحث عن fileAssociations، ثم ضمن Extension، حدد XML.
حدد Edit in settings.json.

في settings.js، أشف التعليمات البرمجية JSON التالية:

"xml.fileAssociations": [
  {
    "pattern": "**.xml",
    "systemId": "https://raw.githubusercontent.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/master/TrustFrameworkPolicy_0.3.0.0.xsd"
  }
]

ا‏‏حفظ التغييرات.

يظهر المثال التالي خطأ التحقق من صحة XML. عند تحريك الماوس فوق اسم العنصر تكون قائمة الملحقات هي العناصر المتوقعة.

Screenshot of VS Code XML schema validation error indicator.

في الحالة التالية، العنصر DisplayName صحيح. ولكنه، في الترتيب الخاطئ. يجب أن يكون DisplayName قبل العنصر Protocol. لإصلاح المشكلة، حرك الماوس فوق العنصر DisplayName إلى الترتيب الصحيح للعناصر.

Screenshot of VS Code XML schema validation order error.

تحميل النهج والتحقق من صحتها

يتم إجراء التحقق من صحة ملف نهج XML تلقائيًا عند التحميل. تتسبب معظم الأخطاء في فشل التحميل. يتضمن التحقق من الصحة ملف النهج الذي تريد تحميله. كما يتضمن سلسلة الملفات التي يشير إليها ملف التحميل (ملف نهج جهة الاعتماد، وملف الملحقات، والملف الأساسي).

تلميح

يقوم Azure AD B2C بتشغيل التحقق من صحة إضافية لنهج جهة الاعتماد. عند وجود مشكلة في نهجك، حتى إذا قمت بتحرير سياسة الملحقات فقط، فمن الممارسات الجيدة تحميل نهج جهة الاعتماد أيضًا.

يحتوي هذا القسم على أخطاء التحقق من الصحة الشائعة والحلول المحتملة.

تم العثور على خطأ التحقق من صحة المخطط ... يحتوي على عنصر تابع غير صالح '{name}'

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

هناك تسلسل مفتاحي مكرر '{number}'

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

تلميح

يمكنك استخدام ملحق Microsoft Azure Active Directory B2C للأمر VS Code(Shift+Ctrl+r) لإعادة ترقيم جميع رحلات المستخدم وخطوات تنسيق الرحلات الفرعية في سياستك.

... كان من المتوقع أن يكون لديك خطوة بالترتيب "{number}"، ولكن لم يتم العثور عليها...

تحقق من الخطأ السابق.

ترتيب خطوة التزامن "{number}" في الرحلة "{name}" ... يُتبع بخطوة اختيار موفر المطالبات ويجب أن يكون تبادل المطالبات، لكنه من نوع ...

نوع خطوات التزامن من ClaimsProviderSelection، وCombinedSignInAndSignUp يحتوي على قائمة بالخيارات التي يمكن للمستخدم الاختيار من بينها. يجب أن يتبع ذلك حسب نوع ClaimsExchange مع واحد أو أكثر من تبادل المطالبات.

تتسبب خطوات التزامن التالية في حدوث هذا النوع أو الخطأ. يجب أن تكون خطوة التزامن الثانية من نوع ClaimsExchange، وليس ClaimsProviderSelection.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/>
          <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange"/>
        </ClaimsProviderSelections>
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email"/>
        </ClaimsExchanges>
      </OrchestrationStep> 

      <OrchestrationStep Order="2" Type="ClaimsProviderSelection">
        ...
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... الخطوة {number} مع اثنين من تبادل المطالبات. يجب أن يسبقها اختيار موفر المطالبات من أجل تحديد أي تبادل للمطالبات التي يمكن استخدامها

خطوة التزامن من نوع ClaimsExchange يجب أن تكون بـ ClaimsExchange واحد، ما لم تكن الخطوة السابقة هي نوع من ClaimsProviderSelection أو CombinedSignInAndSignUp. تتسبب خطوات التزامن التالية في حدوث هذا النوع من الأخطاء. الخطوة السادسة تحتوي على اثنين بتبادل المطالبات.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

لإصلاح هذا النوع من الأخطاء، استخدم خطوتي التزامن. كل خطوة تزامن مع تبادل مطالبة واحد.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

هناك تسلسل مفتاحي مكرر '{name}'

الرحلة لها عدة ClaimsExchange مع Id ذاته. الخطوات التالية تسبب هذا النوع من الخطأ. المعرف AADUserWrite يظهر مرتين في الرحلة.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

لإصلاح هذا النوع من الأخطاء، قم بتغيير تبادل مطالبات خطوات التزامن الثامنة إلى اسم فريد، مثل Call-REST-API.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-API" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... يجعل مرجع ClaimType مع معرف "{claim name}" ولكن لا النهج ولا أي من النهج الأساسية الخاصة به تحتوي على مثل هذا العنصر

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

على سبيل المثال، ملف تعريف فني مع مطالبة إخراج schoolId. ولكن لم يُعلن عن مطالبة المخرجات schoolId مطلقاً في السياسة أو في نهج الأصل.

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="schoolId" />
  ...
</OutputClaims>

لإصلاح هذا النوع من الأخطاء، تحقق مما إذا كانت ClaimTypeReferenceId القيمة بها أخطاء إملائية أو غير موجودة في المخطط. إذا تم تحديد المطالبة في نهج الملحقات، ولكن يتم استخدامها أيضًا في النهج الأساسي. تأكد من تحديد المطالبة في النهج المستخدم به، أو في نهج مستوى أعلى.

إضافة المطالبة إلى مخطط المطالبات يحل هذا النوع من الخطأ.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="schoolId">
      <DisplayName>School name</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your school name</UserHelpText>
      <UserInputType>TextBox</UserInputType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks> -->

... تجعلها إشارة إلى ClaimsTransformation مع معرف...

سبب هذا الخطأ مشابهة لخطأ المطالبة ذلك. تحقق من الخطأ السابق.

يتم تسجيل المستخدم حاليًا كمستخدم للمستأجر 'yourtenant.onmicrosoft.com'...

يمكنك تسجيل الدخول باستخدام حساب من مستأجر يختلف عن النهج الذي تحاول تحميله. على سبيل المثال، سجل دخولك باستخدام admin@contoso.onmicrosoft.com، بينما يتم تعيين النهج TenantId الخاص بك إلى fabrikam.onmicrosoft.com.

<TrustFrameworkPolicy ...
  TenantId="fabrikam.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>fabrikam.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  ...
</TrustFrameworkPolicy>

تحقق من أن القيمة TenantId في عنصري <TrustFrameworkPolicy\> و<BasePolicy\> تطابق مستأجر Azure AD B2C المستهدف.

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

في نهج جهة الاعتماد، أضفت مطالبة إخراج، ولكن مطالبة الإخراج ليست مطالبة إخراج في أي من خطوات رحلة المستخدم. لا يمكن لـ Azure AD B2C قراءة قيمة المطالبة من حقيبة المطالبات.

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

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="schoolId" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

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

<OutputClaim ClaimTypeReferenceId="schoolId" DefaultValue="" />

لم تكن سلسلة الإدخال في تنسيق صحيح

تعيين نوع قيمة غير صحيح إلى مطالبة من نوع آخر. على سبيل المثال، يمكنك تحديد مطالبة عدد صحيح.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="age">
      <DisplayName>Age</DisplayName>
      <DataType>int</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

ثم يمكنك محاولة تعيين قيمة سلسلة:

<OutputClaim ClaimTypeReferenceId="age" DefaultValue="ABCD" />

لإصلاح هذا النوع من الأخطاء، تأكد من تعيين القيمة الصحيحة، مثل DefaultValue="0".

المستأجر "{name}" لديه بالفعل نهج بمعرف "{name}". لا يمكن تخزين نهج آخر بنفس المعرف

يمكنك محاولة تحميل نهج إلى المستأجر، ولكنه تم تحميل نهج بنفس الاسم بالفعل إلى المستأجر.

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

Screenshot that demonstrates how to overwrite the custom policy if it already exists.

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

تعلم كيفية جمع سجلات Azure Active Directory B2C باستخدام Application Insights.

مشاركة عبر