تكوين WebApp SSO واستكشاف أخطائه وإصلاحها على CMS

المقدمة

يصف هذا المستند كيفية تكوين تنفيذ تطبيق ويب الخاص بتسجيل الدخول الأحادي (SSO) لخادم الاجتماعات (CMS) من Cisco واستكشاف أخطائه وإصلاحها.

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

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• CMS CallBridge، الإصدار 3.1 أو إصدار أحدث

• CMS Webbridge، الإصدار 3.1 أو إصدار أحدث

• خادم Active Directory

• تعريف الموفر (IDp)

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

• CMS CallBridge، الإصدار 3.2

• CMS WebBridge، الإصدار 3.2

• Microsoft Active Directory Windows Server 2012 R2

• نظام التشغيل Microsoft ADFS 3.0 Windows Server 2012 R2

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

الخلفية

CMS 3.1 وفيما بعد قدمت إمكانية للمستخدمين لتسجيل الدخول باستخدام SSO دون الحاجة إلى إدخال كلمة المرور الخاصة بهم في كل مرة يقوم المستخدم بتسجيل الدخول، لأنه يتم إنشاء جلسة عمل واحدة باستخدام موفر التعريف.
تستخدم هذه الميزة لغة تمييز تأكيد الأمان (SAML) الإصدار 2.0 كآلية SSO.

ملاحظة: يدعم CMS روابط HTTP-POST فقط في SAML 2.0 ويرفض أي موفر تعريف بدون روابط HTTP-POST متوفرة.

ملاحظة: عند تمكين SSO، تصبح مصادقة LDAP الأساسية غير ممكنة.

التكوين

الرسم التخطيطي للشبكة

تثبيت ADFS والإعداد الأولي

يستخدم سيناريو النشر هذا Microsoft Active Directory Federation Services (ADFS) كموفر الهوية (IdP)، وبالتالي، يقترح أن يكون ADFS (أو IdP المقصود) مثبتا ومشغلا قبل هذا التكوين.

تعيين مستخدمي CMS لموفر الهوية (IDp)

للحصول على مصادقة صالحة للمستخدمين، يجب تعيينهم في واجهة برمجة التطبيقات (API) للحقل المترابط الذي تم توفيره بواسطة IdP. الخيار المستخدم لهذا هو authenationIdMapping في ldapMapping من واجهة برمجة التطبيقات.

1. انتقل إلى التكوين > API على واجهة المستخدم الرسومية (GUI) لإدارة الويب ل CMS

CO

2. تحديد موقع تخطيط LDAP الحالي (أو إنشاء تخطيط جديد) تحت API/V1/ldapMappings/<GUID-of-LDAP-Mapping>.

3. في كائن ldapMapping المحدد، قم بتحديث AuthenticationIdMapping إلى سمة LDAP التي يتم تمريرها من IdP. في المثال، الخيار $sAMAccountNameيستخدم كسمة LDAP للتعيين.

ملاحظة: يتم إستخدام AuthenticationIdMapping من قبل CallBridge/قاعدة البيانات للتحقق من صحة المطالبة التي تم إرسالها من IdP في SAMLResonse وتزويد المستخدم برمز JSON Web Token (JWT).

4. قم بإجراء مزامنة LDAP على ldapSource المقترنة ب ldapMapping الذي تم تعديله مؤخرا:

على سبيل المثال:

5. بعد اكتمال مزامنة LDAP، انتقل في واجهة برمجة تطبيقات CMS في التكوين > API/V1/المستخدمون وتحديد مستخدم تم إستيراده والتحقق من معرف المصادقة تم ملؤه بشكل صحيح.

إنشاء XML لبيانات تعريف WebBridge ل IdP

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

مثال على بيانات Webbridge الأولية بالقيم المطلوبة:

1. EntityID - هذا هو عنوان خادم WebBridge3 (FQDN/Hostname) والمنفذ المقترن الذي يمكن الوصول إليه بواسطة المستعرضات للمستخدمين.
   
   

   ملاحظة: في حالة وجود العديد من جسور ويب تستخدم عنوان URL واحد، يجب أن يكون هذا عنوان موازنة حمل.

   
   
   
2. الموقع - هذا هو الموقع الذي يتم فيه تأكيد HTTP-POST ConfirmationConsumerService لعنوان WebBridge. هذا ما يخبر IDp بمكان إعادة توجيه مستخدم تمت مصادقته بعد تسجيل الدخول. يجب تعيين هذا إلى URL الخاص ب IdpResponse: https://<WebBrdgeFQDN>:<port>/api/auth/sso/idpResponse.  على سبيل المثال، https://join.example.com:443/api/auth/sso/idpResponse.
   
   
3. إختياري - مفتاح عام للتوقيع - هذا هو المفتاح العام (شهادة) للتوقيع، والذي يتم إستخدامه من قبل المعرف للتحقق من طلب المصادقة من WebBridge. يجب أن يتطابق هذا مع المفتاح الخاص 'sso_sign.key' على حزمة SSO التي تم تحميلها على WebBridge بحيث يمكن ل IdP إستخدام المفتاح العام (الشهادة) للتحقق من التوقيع. يمكنك إستخدام شهادة موجودة من عملية النشر.  افتح الترخيص في ملف نصي وانسخ المحتوى في ملف بيانات WebBridge الأولية.  أستخدم المفتاح المطابق للشهادة المستخدمة في ملف sso_xxxx.zip الخاص بك كملف sso_sign.key.
   
   
4. إختياري - مفتاح عام للتشفير - هذا هو المفتاح العام (ترخيص) الذي يتم إستخدامه لتشفير معلومات SAML التي يتم إرسالها إلى Webbridge. يجب أن يتطابق هذا مع المفتاح الخاص 'sso_encrypt.key' على حزمة SSO التي تم تحميلها على WebBridge، حتى يتمكن WebBridge من فك تشفير ما تم إرساله بواسطة IDp.  يمكنك إستخدام شهادة موجودة من عملية النشر.  افتح الترخيص في ملف نصي وانسخ المحتوى في ملف بيانات WebBridge الأولية.  أستخدم المفتاح المطابق للشهادة المستخدمة في ملف sso_xxxx.zip الخاص بك كملف sso_encrypt.key. 

مثال على بيانات تعريف WebBridge التي سيتم إستيرادها إلى IdP مع بيانات مفتاح عام (ترخيص) إختيارية:

إستيراد بيانات تعريف ل Webbridge إلى موفر الهوية (IDp)

بمجرد إنشاء XML لبيانات التعريف باستخدام السمات المناسبة، يمكن إستيراد الملف إلى خادم Microsoft ADFS لإنشاء جهة اعتماد.

1. سطح المكتب البعيد في Windows Server الذي يستضيف خدمات ADFS

2. افتح وحدة التحكم الإدارية AD FS، والتي يمكن الوصول إليها عادة من خلال "إدارة الخوادم".

        

3. بمجرد أن تصل إلى وحدة تحكم إدارة ADFS، انتقل إلى ADFS > علاقات الثقة > ثقة الطرف في الجزء الأيسر.

4. في الجزء الأيمن من وحدة التحكم الإدارية ل ADFS، حدد خيار إضافة ثقة جهة الاعتماد....

5. بعد إجراء هذا التحديد، يتم فتح معالج "إضافة ثقة طرف الاعتماد". حدد خيار البدء.

6. في صفحة تحديد مصدر البيانات، حدد الزر التبادلي لاستيراد البيانات حول الطرف المعول من ملف وحدد إستعراض وانتقل إلى موقع ملف Webbridge MetaData.

7. في صفحة تحديد اسم العرض، ضع اسما ليتم عرضه للكيان في ADFS (اسم العرض ليس غرض الخادم للاتصال ADFS وهو إعلامي محض).

8. في صفحة تكوين المصادقة متعددة العوامل الآن؟، أترك كإعداد افتراضي وحدد التالي.

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

10. في صفحة جاهز لإضافة الثقة، يمكن مراجعة التفاصيل المستوردة الخاصة بجهة الاعتماد على WebBridge من خلال علامات التبويب. تحقق من المعرفات ونقاط النهاية لتفاصيل عنوان URL الخاص بموفر خدمة WebBridge.

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

إنشاء قواعد المطالبات لخدمة WebBridge على IdP

الآن بعد إنشاء "ثقة الطرف المعول" ل WebBridge، يمكن إنشاء قواعد المطالبة لمطابقة سمات LDAP المحددة لأنواع المطالبات الصادرة التي سيتم توفيرها إلى WebBridge في إستجابة SAML.

1. في وحدة تحكم إدارة ADFS، ركز على ثقة الطرف المعول في WebBridge وحدد تحرير قواعد المطالبة في الجزء الأيمن.

2. في صفحة تحرير قواعد المطالبات ل <DisplayName>، حدد قاعدة الإضافة....

3. في صفحة معالج إضافة قاعدة مطالبة التحويل، حدد إرسال سمات LDAP كمطالبات لخيار قالب قاعدة المطالبة وحدد التالي.

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

1. اسم قاعدة المطالبة = يجب أن يكون هذا اسما معطى للقاعدة في ADFS (لمرجع القاعدة فقط)
2. مخزن السمات = Active Directory
3. سمة LDAP = يجب أن يتطابق هذا مع AuthenticationIdMapping في CallBridge API. (على سبيل المثال، $sAMAccountName$.)
4. نوع المطالبة الصادر = يجب أن يتطابق هذا مع AuthenticationIdMapping في WebBridge SSO config.json. (على سبيل المثال، UID)
   
   

إنشاء ملف ZIP لأرشيف SSO ل WebBridge:

هذا التكوين هو ما يشير إليه WebBridge للتحقق من تكوين SSO للمجالات المدعومة وتخطيط المصادقة وما إلى ذلك. يجب مراعاة هذه القواعد لهذا الجزء من التكوين:

• يجب أن يبدأ ملف ZIP ب sso_prefixed إلى اسم الملف (على سبيل المثال، sso_cmstest.zip).
• بمجرد تحميل هذا الملف، يقوم WebBridge بتعطيل المصادقة الأساسية ويمكن إستخدام SSO فقط ل WebBridge الذي تم تحميله.
• في حالة إستخدام العديد من موفري الهوية، يجب تحميل ملف ZIP منفصل بمخطط تسمية مختلف (ما زال يتم تسميته مسبقا مع SSO_).
• عند إنشاء ملف zip، تأكد من إبراز محتويات الملف وإبرازها بضغط، ولا تضع الملفات المطلوبة في مجلد وإضغط ذلك المجلد.

تتكون محتويات ملف ZIP من 2 إلى 4 ملفات، حسب ما إذا كان التشفير قيد الاستخدام أم لا.

اسم الملف	الوصف	مطلوب؟
idp_config.xml	هذا هو ملف MetaData الذي يمكن تجميعه بواسطة المعرف. في ADFS، يمكن تحديد هذا الموضع بالانتقال إلى https://<ADFSFQDN>/FederationMetadata/2007-06/FederationMetadata.xml.	نعم
config.json	هذا هو ملف JSON الذي يستخدم WebBridge فيه للتحقق من صحة المجالات المدعومة، وتخطيط المصادقة ل SSO.	نعم
sso_sign.key	هذا هو المفتاح الخاص لمفتاح التوقيع العام الذي تم تكوينه على تعريف الموفر. مطلوب فقط لتأمين البيانات الموقعة	لا
sso_encrypt.key	هذا هو المفتاح الخاص لمفتاح التشفير العام الذي تم تكوينه على موفر التحديد. مطلوب فقط لتأمين البيانات المشفرة	لا

الحصول على IDP_config.xml وتكوينه

1. على خادم ADFS (أو مكان له إمكانية الوصول إلى ADFS)، افتح متصفح ويب.
   
   

2. في متصفح الويب، أدخل عنوان URL: https://<ADFSFQDN>/FederationMetadata/2007-06/FederationMetadata.xml (يمكنك أيضا إستخدام مضيف محلي بدلا من FQDN إذا كنت محليا على خادم ADFS).  يؤدي هذا إلى تنزيل الملف FederationMetadata.xml.

3. انسخ الملف الذي تم تنزيله إلى موقع يتم فيه إنشاء الملف zip وإعادة تسميته إلى idp_config.xml.

قم بإنشاء ملف config.json مع المحتويات

يحتوي config.json على السمات الثلاث هذه ويجب أن تكون موجودة داخل أقواس، { }:

1. supportedDomains - هذه قائمة بالمجالات التي يتم فحصها لمصادقة SSO مقابل IdP. يمكن فصل المجالات المتعددة بفاصلة.
2. AuthenticationIdMapping - هذه هي المعلمة التي يتم تمريرها مرة أخرى كجزء من قاعدة المطالبة الصادرة من ADFS/IdP. يجب أن يتطابق هذا مع قيمة اسم نوع المطالبة الصادرة على IdP. قاعدة المطالبة.
3. ssoServiceProviderAddress - هذا هو عنوان URL ل FQDN الذي يرسل إليه موفر التعريف استجابات SAML. يجب أن يكون هذا هو FQDN الخاص ب WebBridge.
   
   

تعيين sso_sign.key (إختياري) 

يجب أن يحتوي هذا الملف على المفتاح الخاص للشهادة المستخدمة للتوقيع في بيانات تعريف Webbridge التي تم إستيرادها إلى IdP. يمكن تعيين الشهادة المستخدمة للتوقيع أثناء إستيراد بيانات تعريف Webbridge في ADFS عن طريق ملء شهادة X509 بمعلومات الشهادة ضمن قسم <KeyDescriptor use=signature>. كما يمكن عرضه (واستيراده) على ADFS في WebBridge الاعتماد على جهة الثقة ضمن الخصائص > التوقيع. 

في المثال التالي، يمكنك رؤية شهادة CallBridge (CN=cmscb3.brhuff.local)، والتي تمت إضافتها إلى بيانات تعريف Webbridge قبل إستيرادها إلى ADFS. المفتاح الخاص المدرج في sso_sign.key هو المفتاح الذي يطابق شهادة cmscb3.brhuff.local.

هذا تكوين إختياري ولا يلزم إلا إذا كنت تنوي تشفير استجابات SAML.

تعيين sso_encrypt.key (إختياري)

يجب أن يحتوي هذا الملف على المفتاح الخاص للشهادة المستخدمة للتشفير في بيانات تعريف Webbridge التي تم إستيرادها إلى IdP. يمكن تعيين الشهادة المستخدمة للتشفير أثناء إستيراد بيانات تعريف Webbridge في ADFS عن طريق ملء شهادة X509 بمعلومات الشهادة ضمن قسم <KeyDescriptor use=encryption>. كما يمكن عرضه (واستيراده) على ADFS في WebBridge الاعتماد على جهة الثقة ضمن الخصائص > التشفير. 

في المثال التالي، يمكنك رؤية شهادة CallBridge (CN=cmscb3.brhuff.local)، والتي تمت إضافتها إلى بيانات تعريف WebBridge قبل إستيرادها إلى ADFS. المفتاح الخاص المدرج في 'sso_encrypt.key' هو المفتاح الذي يطابق شهادة cmscb3.brhuff.local.

هذا تكوين إختياري ولا يحتاج إليه إلا إذا كنت تنوي تشفير استجابات SAML.

إنشاء ملف SSO ZIP

1. قم بتمييز جميع الملفات المراد إستخدامها لملف تكوين SSO.

2. انقر بزر الماوس الأيمن فوق ملفات الإبراز وحدد مجلد إرسال إلى > مضغوط (مضغوط).

3. بعد سحب الملفات، قم بإعادة تسميتها إلى الاسم المرغوب باستخدام البادئة sso_:

تحميل ملف (ملفات) SSO Zip إلى WebBridge

افتح عميل SFTP/SCP، في هذا المثال يتم إستخدام WinSCP، واتصل بالخادم الذي يستضيف WebBridge3.

1. في الجزء الأيسر، انتقل إلى الموقع الذي يوجد فيه ملف SSO ZIP وانقر بزر الماوس الأيمن فوق تحديد تحميل أو سحب الملف وإسقاطه.

2. بمجرد تحميل الملف بالكامل إلى خادم WebBridge3، افتح جلسة SSH وقم بتشغيل الأمر webbridge3 restart.

3. في syslog، تشير هذه الرسائل إلى أن تمكين SSO كان ناجحا:

بطاقة الوصول المشترك (CAC)

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

فيما يلي عملية تسجيل الدخول بالكامل للمستخدمين الذين يستخدمون بطاقات CAC:

1. قم بتشغيل الكمبيوتر، وألصق بطاقة CAC
2. قم بتسجيل الدخول (أختر شهادة في بعض الأحيان)، ثم أدخل رمز PIN
3. فتح المستعرض
4. انتقل إلى عنوان URL للانضمام وانظر خيارات الانضمام إلى إجتماع أو تسجيل الدخول
5. تسجيل الدخول: أدخل اسم المستخدم الذي تم تكوينه ك jidMapping الذي يتوقعه Active Directory من تسجيل دخول CAC
6. تسجيل الدخول
7. تظهر صفحة ADFS بشكل مختصر ويتم تعبئتها تلقائيا
8. تم تسجيل دخول المستخدم عند هذه النقطة

قم بتكوين jidMapping (هذا هو اسم تسجيل الدخول للمستخدمين) في Ldapmapping مثل ما يستخدمه ADFS لبطاقة CAC.  $UserPrincipalName$ على سبيل المثال (حساس لحالة الأحرف)

قم أيضا بتعيين نفس سمة LDAP ل authenticationIdMapping لمطابقة السمة المستخدمة في قاعدة المطالبة في ADFS. 

هنا، تظهر قاعدة المطالبة أنها ستقوم بإرسال $userPrincipalName$ مرة أخرى إلى CMS ك UID.

إختبار تسجيل دخول SSO عبر WebApp

الآن بعد تكوين SSO، يمكنك إختبار الخادم:

1. انتقل إلى عنوان URL الخاص ب WebBridge الخاص بتطبيق ويب وحدد الزر تسجيل الدخول.

2. يقدم للمستخدم خيار إدخال اسم المستخدم (لاحظ لا يوجد خيار كلمة مرور في هذه الصفحة).

3. تتم بعد ذلك إعادة توجيه المستخدم إلى صفحة ADFS (بعد إدخال تفاصيل المستخدم) حيث يجب على المستخدم إدخال بيانات الاعتماد الخاصة به للمصادقة على IDp.

4. تتم إعادة توجيه المستخدم، بعد إدخال بيانات الاعتماد والتحقق من صحتها باستخدام الرمز المميز للوصول إلى الصفحة الرئيسية ل Web App:

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

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

فيما يتعلق باستكشاف أي مشكلة متعلقة بالمسوحات وإصلاحها بشكل أساسي:

1. تأكد من تكوين بيانات التعريف التي تم إنشاؤها ل WebBridge3 المستخدم في الاستيراد كوثيقة اعتماد في IdP بشكل صحيح ومن تطابق عنوان URL الذي تم تكوينه تماما مع ssoServiceProviderAddress في config.json.
2. تأكد من أن بيانات التعريف الموفرة من قبل IDp والمزودة في ملف تكوين WebBridge3 حتى تكون الأحدث من IDp، كما لو كان هناك أي تغييرات على اسم مضيف الخادم، والشهادات، وما إلى ذلك، فإنه يحتاج إلى إعادة تصديره وإدخاله في ملف التكوين.
3. إذا كنت تستخدم مفاتيح التوقيع والتشفير الخاصة لتشفير البيانات، فتأكد من أن المفاتيح المطابقة الصحيحة هي جزء من ملف sso_xxxx.zip الذي قمت بتحميله إلى WebBridge. إذا أمكن، حاول الاختبار دون إستخدام المفاتيح الخاصة الاختيارية لمعرفة ما إذا كان اتصال SSO يعمل بدون هذا الخيار المشفر.
4. تأكد من تكوين config.json باستخدام التفاصيل الصحيحة لمجالات SSO و WebBridge3 URL و AuthenticationMapping المتوقع لمطابقته من SAMLResonse.

وسيكون من المثالي أيضا محاولة أستكشاف المشكلات وحلها من منظور السجل:

1. عند التنقل إلى عنوان URL الخاص ب WebBridge، ضع؟trace=true في نهاية عنوان URL لتمكين تسجيل المطرد على syslog ل CMS. (مثال: https://join.example.com/en-US/home?trace=true).
2. قم بتشغيل syslog follow على خادم WebBridge3 لالتقاط Live أثناء الاختبار أو تشغيل الاختبار باستخدام خيار التتبع المضاف إلى عنوان URL وتجميع logBundle.tar.gz من خوادم WebBridge3 و CMS CallBridge.  إذا كان WebBridge و callbridge على نفس الخادم، فإن هذا يتطلب ملف logBundle.tar.gz واحد فقط.

رموز فشل Microsoft ADFS

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

رموز حالة Microsoft

مثال على ذلك:

client_backend: خطأ: SamlManager: فشل طلب مصادقة SAML _e135ca12-4b87-4443-abe1-30d396590d58 لسبب: urn:oasis:الأسماء:tc:saml:2.0:status:responder

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

فشل الحصول على authenationID

يمكن أن يكون هناك مثيلات أثناء تبادل SAMLResonse مرة أخرى من IdP، يمكن ل WebBridge عرض رسالة الخطأ هذه في السجلات مع فشل في تسجيل الدخول عبر SSO:

client_backend: INFO: SamlManager: [57dff9e3-862e-4002-b4fa-683e4aa6922c] فشل الحصول على معرف المصادقة

يشير هذا إلى أنه عند مراجعة بيانات SAMLResonse التي تم تمريرها مرة أخرى من IdP أثناء تبادل المصادقة، لم يعثر WebBridge3 على سمة مطابقة صالحة في الاستجابة مقارنة ب config.json ل authenticationId الخاص به.

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

في إخراج تسجيل الشبكة في أدوات المطور، المشار إليها أيضا باسم بيانات HAR، ابحث عن IdpResponse تحت عمود الاسم وحدد Payload للاطلاع على إستجابة SAML.  وكما ذكر سابقا، يمكن فك ترميز هذا باستخدام أداة فك الترميز base64.

عند تلقي بيانات SAMLResponse، تحقق من قسم <AttributeStatement> لتحديد موقع أسماء السمات التي تم إرسالها مرة أخرى، ويمكنك العثور على أنواع المطالبات التي تم تكوينها وإرسالها من IdP. على سبيل المثال:

<AttributeStatement>
<attribute name=<url for common name">
<AttributeValue>testuser1</AttributeValue>
</attribute>
<Attribute Name=<URL ل NameID">
<AttributeValue>testuser1</AttributeValue>
</attribute>
<اسم السمة="uid">
<AttributeValue>testuser1</AttributeValue>
</attribute>
</AttributeStatement>

ومراجعة الأسماء السابقة، يمكنك التحقق من <AttributeName> ضمن قسم "بيان السمات" ومقارنة كل قيمة بما تم تعيينه في قسم authenticationIdmapping في SSO config.json.

في المثال السابق، يمكنك أن ترى أن التكوين ل authenticationIdMapping لا يتطابق تماما مع ما تم تمريره ومن ثم ينتج عنه فشل في تحديد موقع معرف مصادقة مطابق:

AuthenticationIdMapping : http://example.com/claims/NameID

لحل هذه المشكلة، هناك طريقتان محتملتان لمحاولة:

1. يمكن تحديث قاعدة المطالبة الصادرة الخاصة ب IdP بحيث تحتوي على مطالبة مطابقة تتطابق تماما مع ما تم تكوينه في AuthenticationIdMapping الخاص ب config.json على WebBridge3. (تمت إضافة قاعدة المطالبة على IdP ل http://example.com/claims/NameID)
   أو
2. يمكن تحديث config.json على WebBridge3 ليطابق 'authenticationIdMapping' ما تم تكوينه بالضبط كأحد قواعد المطالبة الصادرة التي تم تكوينها على IdP. (وهو 'authenticationIdMapping' المطلوب تحديثه لمطابقة أحد أسماء السمات، والتي يمكن أن تكون "uid" أو "<URL>/NameID" أو "<URL>/CommonName". طالما تطابق (بالضبط) القيمة المتوقعة التي تم تكوينها على واجهة برمجة تطبيقات CallBridge عند مرورها)

لم يتم تمرير/مطابقة أي تأكيد في التحقق من الصحة

في بعض الأحيان، أثناء تبادل SAMLRonse من IdP، يعرض WebBridge هذا الخطأ للإشارة إلى وجود فشل في مطابقة التأكيد وتخطي أي تأكيدات لا تتطابق مع تكوين الخادم:

client_backend: خطأ: SamlManager: لم يتم تمرير أية تأكيدات عملية التحقق من الصحة
client_backend: معلومات: SamlManager: تخطي التأكيد دون وجودنا في الجمهور المسموح به

يشير هذا الخطأ إلى أنه عند مراجعة SAMLRonse من IdP، فشل WebBridge في تحديد أية تأكيدات مطابقة وبالتالي تجاوز حالات الفشل غير المطابقة مما أدى في النهاية إلى فشل سجل SSO. 

لتحديد موقع هذه المشكلة، من المثالي مراجعة SAMLRonse من IdP. إذا لم يتم تشفير الاتصال باستخدام مفاتيح الإشارة والتشفير الخاصة، يمكن إستخراج إستجابة SAML من تسجيل شبكة أدوات المطور عبر متصفح ويب وفك ترميزه باستخدام Base64. إذا تم تشفير الاستجابة، يمكنك طلب إستجابة SAML التي تم فك تشفيرها من جانب IdP. 

عند مراجعة بيانات SAMLResonse، بالنظر إلى قسم <AudienceRestriction>في الاستجابة، يمكنك العثور على كافة الجماهير التي تم تقييد هذه الاستجابة لها:

<الشروط NotBefore=2021-03-30T19:35:37.071Z NotOnOrAfter=2021-03-30T19:36:37.071Z>
<AudienceRestriction>
<audience>https://cisco.example.com</audience>
</AudienceRestriction>
</الشروط>

باستخدام القيمة الموجودة في قسم <Audience>(https://cisco.example.com) يمكنك مقارنتها ب ssoServiceProviderAddress في config.json الخاص بتكوين WebBridge والتحقق من أنها تطابق تام. ل هذا مثال، أنت يستطيع رأيت أن سبب للفشل أن الجماعة المستهدفة لا تلاءم المزود عنوان في التشكيل، لأن هو يتلقى ال :443:

ssoServiceProviderAddress : https://cisco.example.com:443

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

1. يمكن إزالة :443 من العنوان الموجود في قسم ssoServiceProviderAddress من config.json، بحيث يتطابق مع حقل الجمهور المتوفر في SAMLResonse من IdP.
أو

2. يمكن تحديث بيانات التعريف أو الجهة الموثوق بها ل WebBridge3 في IdP لتضمين :443 إلى URL. (في حالة تحديث بيانات التعريف، يجب إستيرادها مرة أخرى كجهة ثقة معتمدة على ADFS. ومع ذلك، إذا قمت بتعديل جهة الاعتماد من معالج IdP مباشرة، فلن تحتاج إلى إستيرادها مرة أخرى.)

فشل تسجيل الدخول على Web App:

فشل تسجيل الدخول

السيناريو 1:

لا يمكن الوصول إلى ADFS.  عند محاولة العميل تسجيل الدخول (باستخدام https://<joinurl>؟trace=true)، يتحقق WebBridge من أن المجال المستخدم يطابق واحدا في ملف config.json، ثم يرسل معلومات SAML إلى العميل، يعلم العميل بمكان الاتصال به للمصادقة.  يحاول العميل الاتصال ب IdP الموجود في رمز SAML المميز.  في المثال، يظهر المستعرض هذه الصفحة لأنها لا تستطيع الوصول إلى خادم ADFS.

خطأ في مستعرض العميل

مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)

مارس 19 10:47:07.927 user.info cmscb3-1 client_backend: معلومات: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] تطابق SSO_2024.zip في طلب رمز SAML المميز

مارس 19 10:47:07.927 user.info cmscb3-1 client_backend: معلومات: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] محاولة العثور على SSO في طلب رمز SAML المميز

مارس 19 10:47:07.930 user.info cmscb3-1 client_backend: معلومات: SamlManager: [63cdc9ed-ab52-455c-8bb2-9e925cb9e16b] تم إنشاء رمز SAML المميز بنجاح

السيناريو الثاني:

حاول المستخدم تسجيل الدخول باستخدام مجال غير موجود في ملف SSO zip في صفحة تسجيل الدخول إلى WebBridge.  يرسل العميل في TokenRequest مع حمولة من اسم المستخدم الذي أدخله.  يقوم WebBridge بإيقاف محاولة تسجيل الدخول على الفور.

مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)

MAR 18 14:54:52.698 user.err cmscb3-1 client_backend: خطأ: SamlManager: محاولة تسجيل دخول SSO غير صالحة

مارس 18 14:54:52.698 user.info cmscb3-1 client_backend: معلومات: SamlManager: [3f93fd14-f4c9-4e5e-94d5-49bf643319e] فشل في العثور على SSO في طلب رمز SAML المميز

مارس 18 14:54:52.698 user.info cmscb3-1 client_backend: معلومات: SamlManager: [3f93fd14-f4c9-4e5e-94d5-49bf643319e] محاولة العثور على SSO في طلب رمز SAML المميز

السيناريو 3:

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

مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)

مارس 19 16:39:17.714 user.info cmscb3-1 client_backend: معلومات: SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] تطابق SSO_2024.zip في طلب رمز SAML المميز

مارس 19 16:39:17.714 user.info cmscb3-1 client_backend: معلومات: SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] محاولة العثور على SSO في SAML إستجابة للمشردين داخليا

MAR 19 16:39:17.720 user.err cmscb3-1 client_backend: خطأ: SamlManager: لم يتم العثور على عنصر محدد ل AuthenticationId في تأكيدات SAML الموقعة

user.info معلومات:SamlManager: [ef8fe67f-685c-4a81-9240-f76239379806] فشل في الحصول على معرف المصادقة

سبب السيناريو 3 هو إستخدام قاعدة المطالبة في IdP لنوع مطالبة لا تتطابق مع AuthenticationIdMapping في ملف config.json المستخدم في ملف SSO zip الذي تم تحميله إلى WebBridge.  يبحث WebBridge في إستجابة SAML ويتوقع أن يطابق اسم السمة ما تم تكوينه في config.json.

قاعدة المطالبة في ADFS

مثال config.json

لم يتم التعرف على اسم المستخدم

السيناريو 1:

قام المستخدم بتسجيل الدخول باسم مستخدم غير صحيح (يتطابق المجال مع ما هو موجود في ملف SSO zip الذي تم تحميله إلى WebBridge3، ولكن المستخدم غير موجود)

لم يتم التعرف على اسم المستخدم

مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)

مارس 18 14:58:47.777 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbb6c87c6] تطابق SSO_2024.zip في طلب رمز SAML المميز

مارس 18 14:58:47.777 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] محاولة العثور على SSO في طلب رمز SAML المميز

مارس 18 14:58:47.780 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] تم إنشاء رمز SAML المميز بنجاح

مارس 18 14:58:48.072 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbb6c87c6] تطابق SSO_2024.zip في طلب رمز SAML المميز

مارس 18 14:58:48.072 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbb6c87c6] محاولة العثور على SSO في إستجابة SAML للمشردين داخليا

مارس 18 14:58:48.077 user.info cmscb3-1 client_backend: معلومات: SamlManager: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] تم الحصول على المصادقة بنجاح معرف:darmckin@brhuff.com

مارس 18 14:58:48.078 user.info cmscb3-1 host:server: INFO: WB3Cmgr: [79e9a87e-0fa4-44df-a914-bbb6c87c6] AuthRequestReceived لمعرف الاتصال=6400456-faea-479f-aabe-691e1783aa=40a4026c-06c 72-42a1-b125-136fdf5612a5 (user=steve@brhuff.com)

مارس 18 14:58:48.092 user.info cmscb3-1 host:server: معلومات: لم يتم العثور على مستخدم للتخويل

مارس 18 14:58:48.092 user.info cmscb3-1 host:server: معلومات: طلب تسجيل الدخول غير الناجح من steve@brhuff.com

السيناريو الثاني:

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

لم يتم التعرف على اسم المستخدم

مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)

مارس 18 15:08:52.114 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] تطابق SSO_2024.zip في طلب رمز SAML

مارس 18 15:08:52.114 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] محاولة العثور على SSO في طلب رمز SAML المميز

مارس 18 15:08:52.117 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] تم إنشاء رمز SAML المميز بنجاح

مارس 18 15:08:52.386 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] تطابق SSO_2024.zip في طلب رمز SAML

مارس 18 15:08:52.386 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] محاولة العثور على SSO في SAML إستجابة النازحين

مارس 18 15:08:52.391 user.info cmscb3-1 client_backend: معلومات: SamlManager: [d626bbaf-80c3-4286-8284-fac6f71eb140] تم الحصول على المصادقةID:darmckin@brhuff.com بنجاح

مارس 18 15:08:52.391 user.info cmscb3-1 host:server: معلومات: WB3Cmgr: [d626bbaf-80c3-4286-8284-fac6f71eb140] AuthRequestReceived للاتصال id=64004556-faea-479f-aabe-691e1783aa5=40a040 26c-0272-42a1-b125-136fdf5612a5 (user=darmckin@brhuff.com)

مارس 18:08:52.399 user.تحذير cmscb3-1 host:server: تحذير: رفض محاولة تسجيل الدخول من المستخدم 'darmckin@brhuff.com' — المصادقةID غير صحيح

18 مارس 15:08:52.412 user.info cmscb3-1 host:server: معلومات: طلب تسجيل الدخول غير الناجح من darmckin@brhuff.com

لا يتطابق AuthenticationIdMapping في CMS LDAPMAPPING مع سمة LDAP التي تم تكوينها المستخدمة لقاعدة المطالبة في ADFS. يشير السطر الذي يقول تم بنجاح الحصول على المصادقةID:darmckin@brhuff.com" إلى أن ADFS لديه قاعدة مطالبة تم تكوينها بالسمة التي تحصل على darmckin@brhuff.com من الدليل النشط، ولكن AuthenticationID في CMS API>Users يظهر أنه يتوقع الدرك.  في CMS LDAPmappings، يتم تكوين AuthenticationID ك $sAMAccountName$، ولكن يتم تكوين قاعدة المطالبة في ADFS لإرسال عناوين البريد الإلكتروني، لذلك لا يتطابق ذلك. 

كيفية إصلاح هذا:

قم بأي من الخيارين للتقليل:

1. قم بتغيير AuthenticationID في CMS LDAPMAPPING لمطابقة ما يتم إستخدامه في قاعدة المطالبة على ADFS وإجراء مزامنة جديدة
2. تغيير سمة LDAP المستخدمة في قاعدة مطالبة ADFS لتطابق ما تم تكوينه في تعيين CMS LDPmapping

API LDAPMapping

مثال مستخدم API

قاعدة المطالبة من ADFS

سجل WebBridge الذي يظهر مثال تسجيل الدخول إلى العمل.  المثال الذي تم إنشاؤه باستخدام <trace=true في عنوان URL المتصل:

مارس 18 14:24:01.096 user.info cmscb3-1 client_backend: معلومات: SamlManager: [7979f13c-d490-4f8b-899c-0c8285369ba] تطابق SSO_2024.zip في طلب رمز SAML المميز

مارس 18 14:24:01.096 user.info cmscb3-1 client_backend: معلومات: SamlManager: [7979f13c-d490-4f8b-899c-0c82853369ba] محاولة العثور على SSO في SAML إستجابة للمشردين داخليا

مارس 18 14:24:01.101 user.info cmscb3-1 client_backend: معلومات: SamlManager: [7979f13c-d490-4f8b-899c-0c82853369ba] تم الحصول على المصادقةID:darmckin@brhuff.com

مارس 18 14:24:01.102 user.info cmscb3-1 host:server: معلومات: WB3Cmgr: [7979f13c-d490-4f8b-899c-0c82853369ba] AuthRequestReceived لمعرف الاتصال=64004556-faea-479f-aabe-691e1783aa=40a 4026c-0272-42a1-b125-136fdf5612a5 (user=darmckin@brhuff.com)

مارس 18 14:24:01.130 user.info cmscb3-1 host:server: معلومات: طلب تسجيل دخول ناجح من darmckin@brhuff.com

مارس 18 14:24:01.130 user.info cmscb3-1 host:server: INFO: WB3Cmgr: [7979f13c-d490-4f8b-899c-0c82853369ba] إصدار JWT ID e2a860ef-f4ef-4391-b5d5-9abdfa89ba0f

مارس 18 14:24:01.132 user.info cmscb3-1 host:server: معلومات: WB3CMGR: [7979f13c-d490-4f8b-899c-0c82853369ba] إرسال إستجابة المصادقة (jwt length=1064، اتصال=64004556-faea-479f-aabe-691e1783aa 5)

مارس 18 14:24:01.133 local7.info cmscb3-1 56496041063b wb3_front: [auth:darmckin@brhuff.com، التتبع:7979f13c-d490-4f8b-899c-0c8285369ba] 10.10.8 - [18/MAR/2024:18:24:010 000] وضع 200 "POST /api/auth/sso/idpResponse HTTP/1.1" bytes_sent 0 http_reference https://adfs.brhuff.com/" http_user_agent "mozilla/5.0 (Windows NT 10.0؛ Win64؛ x64) AppleWebKit/537.36 (KHTML، مثل Gecko) Chrome/122.0.0. 0. Safari/537.36 إلى الخادم 192.0.2.2:9000: up_response_time 0.038 request_time 0.039 msec 1710786241.133 upstream_response_length 24 200

الأسئلة المتداولة (FAQ)

يسلط هذا القسم الضوء على الأسئلة أو الموضوعات المتعلقة ب WebApp SSO على خادم الاجتماعات من Cisco.

هل يمكن توسيع Webapp SSO JWT؟

الرمز المميز ل JSON (JWT) هو الرمز المميز الذي يتم توفيره بواسطة CallBridge لعميل WebApp الذي تمت مصادقته بنجاح (تمت مصادقته بنجاح إلى IdP)، مما يتيح لهم الوصول إلى خدمات WebApp. ضمن JWT توجد قيمة مؤقت انتهاء صلاحية تشير إلى مدة صلاحية JWT، والتي بمجرد الوصول إلى وقت انتهاء صلاحية JWT - تتم إعادة توجيه مستخدم WebApp مرة أخرى إلى صفحة تسجيل دخول WebBridge في الصفحة، مما يتطلب إعادة المصادقة من أجل الحصول على الوصول مرة أخرى. 

يكون انتهاء صلاحية JWT قابلا للتكوين باستخدام 'callbridge wc3jwt انتهاء صلاحية <1-24>(مضافا في 3.8 وفيما بعد - يمكن العثور على مزيد من التفاصيل في ملاحظات إصدار CMS 3.8 أو دليل CMS MMP) حيث تكون القيمة الرقمية لعدد الساعات التي تريد تعيين وقت انتهاء صلاحية JWT المتوفر لعملاء WebApp. ومع ذلك، كما هو موضح في الأمر، يمكن تعيين القيمة القصوى على 24 ساعة، مما يعني أن أطول وقت يمكن أن يبقى JWT صالحا ويمكن لمستخدم WebApp تسجيل الدخول هو 24 ساعة. عندما تنتهي صلاحية JWT يتم الوفاء بالوقت - يقوم المستعرض بإلغاء الرمز المميز الذي انتهت صلاحيته ويتم إجبار مستخدم WebApp على العودة إلى صفحة تسجيل الدخول إلى WebApp. 

في بعض البيئات، اعتمادا على معرف P وإعداد البيئة، يمكن تنفيذ خاصية SSO/Keep ME ثابتة موقعة في IDp - والتي من شأنها أن توفر للمستعرض أداة ثابتة مطهية من IDp، حيث يتم الاحتفاظ حتى بإغلاق المستعرض (ما لم يتم مسحها بوسائل أخرى). بغض النظر عن تكوين SSO/IdP - عند انتهاء صلاحية JWT (24 ساعة كحد أقصى)، يتم إجبار مستخدم WebApp على العودة إلى صفحة تسجيل الدخول إلى WebApp - ومع ذلك، في هذا السيناريو حيث يتم تمكين SSO المستمر على IdP - سيحتاج المستخدم فقط إلى إدخال <user@domain> الخاص به في صفحة تسجيل الدخول إلى WebApp ولن يحتاج إلى إعادة المصادقة إلى IdP الخاص به.

يتم فتح تحسين لتنفيذ آلية الرمز المميز للتحديث للسماح بالتفويض الموسع ل WebApp - معرف تصحيح الأخطاء من Cisco CSCwm28758.

هل أحتاج إلى إعادة المصادقة على WebApp إذا قمت بإغلاق المستعرض؟

سيكون تدفق هذا السيناريو:

1. يقوم المستخدم بتسجيل الدخول إلى WebApp (باستخدام أسلوب مصادقة SSO).
2. يقوم المستخدم بإغلاق المستعرض عند نقطة ما.
3. يفتح المستخدم المستعرض مرة أخرى ويتنقل إلى موقع WebApp. (سواء في الحال أو في وقت لاحق).

ما الذي يمكن أن يحدث في هذا السيناريو؟

بالنسبة لهذه الاجابة فهو يعتمد! يعتمد ذلك بالكامل على ما إذا كان JWT الذي توفره Callbridge قد انتهت صلاحيته عند الوصول إلى صفحة WebApp. ما دام JWT لا يزال صالحا وموجودا في التخزين، يمكنك الانتقال إلى صفحة WebApp (حتى إذا أغلقت المستعرض). تذكر أن الحد الأقصى لوقت صلاحية JWT هو 24 ساعة. 

• إذا كان JWT لا يزال صالحا (غير منتهي الصلاحية) وحاضرا، فيمكن للمستخدم الانتقال إلى صفحة WebApp مع مساحاتها وما إلى ذلك دون الحاجة إلى إعادة المصادقة.
• إذا كان JWT غير صالح (منتهي الصلاحية)، تتم إعادة توجيه المستخدم إلى صفحة تسجيل الدخول إلى WebApp، مما يحتاج إلى إعادة تسجيل الدخول إلى WebApp. يمكن أن يحتاج المستخدم أيضا إلى إعادة المصادقة إلى IdP الخاص به بناء على أسلوب مصادقة IdP الخاص به (على سبيل المثال إذا كان IdP يستخدم Session SSO أو SSO المستمر).

كيف يتم دعم المجالات المتعددة في WebApp SSO؟

يكون SSO ل WebApp قادرا على دعم البيئات التي تحتوي على مجالات متعددة وحتى البيئات حيث تشير هذه المجالات المختلفة إلى موفري هوية مختلفين (IdPs).  يرجى مراجعة أدلة نشر Cisco Meeting Server أو الاتصال ب Cisco TAC للحصول على الدعم على إستخدام مجالات متعددة.

معلومات ذات صلة

• الدعم الفني والتنزيلات من Cisco