تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند كيفية تكوين تنفيذ تطبيق ويب الخاص بتسجيل الدخول الأحادي (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 الأساسية غير ممكنة.
يستخدم سيناريو النشر هذا Microsoft Active Directory Federation Services (ADFS) كموفر الهوية (IdP)، وبالتالي، يقترح أن يكون ADFS (أو IdP المقصود) مثبتا ومشغلا قبل هذا التكوين.
للحصول على مصادقة صالحة للمستخدمين، يجب تعيينهم في واجهة برمجة التطبيقات (API) للحقل المترابط الذي تم توفيره بواسطة IdP. الخيار المستخدم لهذا هو authenationIdMapping في ldapMapping من واجهة برمجة التطبيقات.
1. انتقل إلى التكوين > API على واجهة المستخدم الرسومية (GUI) لإدارة الويب ل CMS
CO
2. تحديد موقع تخطيط LDAP الحالي (أو إنشاء تخطيط جديد) تحت API/V1/ldapMappings/<GUID-of-LDAP-Mapping>.
3. في الكائن ldapMapping المحدد، قم بتحديث authenticationIdMapping إلى سمة LDAP التي يتم تمريرها من IdP. في المثال، يتم إستخدام الخيار $sAMAccountNameis كسمة LDAP للتعيين.
ملاحظة: يتم إستخدام AuthenticationIdMapping من قبل CallBridge/قاعدة البيانات للتحقق من صحة المطالبة التي تم إرسالها من IdP في SAMLResonse وتوفير رمز JSON Web Token (JWT) للمستخدم.
4. قم بإجراء مزامنة LDAP على ldapSource المقترنة ب ldapMapping الذي تم تعديله مؤخرا:
على سبيل المثال:
5. بعد اكتمال مزامنة LDAP، قم بالتنقل في واجهة برمجة تطبيقات CMS في التكوين > API/V1/user وحدد مستخدم تم إستيراده، وتحقق من ملء معرف المصادقة بشكل صحيح.
يسمح ADFS من Microsoft باستيراد ملف XML لبيانات التعريف كجهة اعتماد موثوق بها لتعريف مزود الخدمة الذي يتم إستخدامه. هناك عدة طرق لإنشاء ملف بيانات التعريف XML لهذا الغرض، على أي حال، هناك بعض الخصائص التي يجب أن تكون موجودة في الملف:
مثال على بيانات Webbridge الأولية بالقيم المطلوبة:
ملاحظة: في حالة وجود العديد من WebBridges باستخدام عنوان URL واحد، يجب أن يكون هذا عنوان موازنة حمل.
مثال على بيانات تعريف WebBridge التي سيتم إستيرادها إلى IdP مع بيانات مفتاح عام (ترخيص) إختيارية:
بمجرد إنشاء XML لبيانات التعريف باستخدام السمات المناسبة، يمكن إستيراد الملف إلى خادم Microsoft ADFS لإنشاء جهة اعتماد.
1. سطح المكتب البعيد في Windows Server الذي يستضيف خدمات ADFS
2. افتح وحدة التحكم الإدارية AD FS، والتي يمكن الوصول إليها عادة من خلال "إدارة الخوادم".
3. بمجرد أن تصل إلى وحدة تحكم إدارة ADFS، انتقل إلى ADFS > علاقات الثقة > ثقة الطرف في الجزء الأيسر.
4. في الجزء الأيمن من وحدة التحكم الإدارية ل ADFS، حدد Add Relying Party Trust... خيار.
5. بعد إجراء هذا التحديد، يتم فتح معالج "إضافة ثقة طرف الاعتماد". حدد خيار البدء.
6. في صفحة تحديد مصدر البيانات، حدد الزر التبادلي لاستيراد البيانات حول الطرف المعول من ملف وحدد إستعراض وانتقل إلى موقع ملف Webbridge MetaData.
7. في صفحة تحديد اسم العرض، ضع اسما ليتم عرضه للكيان في ADFS (اسم العرض ليس غرض الخادم للاتصال ADFS وهو إعلامي محض).
8. في تكوين المصادقة متعددة العوامل الآن؟ صفحة، أترك كافتراضي وحدد التالي.
9. في صفحة إختيار قواعد ترخيص الإصدار، أترك كما هو محدد للسماح لجميع المستخدمين بالوصول إلى الطرف المعول هذا.
10. في صفحة جاهز لإضافة الثقة، يمكن مراجعة التفاصيل المستوردة الخاصة بجهة الاعتماد على WebBridge من خلال علامات التبويب. تحقق من المعرفات ونقاط النهاية لتفاصيل عنوان URL الخاص بموفر خدمة WebBridge.
11. في صفحة إنهاء ، حدد خيار إغلاق لإغلاق المعالج ومتابعة تحرير قواعد المطالبة.
الآن بعد إنشاء "ثقة الطرف المعول" ل WebBridge، يمكن إنشاء قواعد المطالبة لمطابقة سمات LDAP المحددة لأنواع المطالبات الصادرة التي سيتم توفيرها إلى WebBridge في إستجابة SAML.
1. في وحدة تحكم إدارة ADFS، ركز على ثقة الطرف المعول في WebBridge وحدد تحرير قواعد المطالبة في الجزء الأيمن.
2. في صفحة تحرير قواعد المطالبات ل <DisplayName>، حدد قاعدة الإضافة....
3. في صفحة معالج إضافة قاعدة مطالبة التحويل، حدد إرسال سمات LDAP كمطالبات لخيار قالب قاعدة المطالبة وحدد التالي.
4. في صفحة تكوين قاعدة المطالبة، قم بتكوين قاعدة المطالبة لثقة الطرف المعول باستخدام هذه القيم:
هذا التكوين هو ما يشير إليه WebBridge للتحقق من تكوين SSO للمجالات المدعومة وتخطيط المصادقة وما إلى ذلك. يجب مراعاة هذه القواعد لهذا الجزء من التكوين:
تتكون محتويات ملف 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 |
هذا هو المفتاح الخاص لمفتاح التشفير العام الذي تم تكوينه على موفر التحديد. مطلوب فقط لتأمين البيانات المشفرة |
لا |
2. في مستعرض ويب، أدخل URL: https://<ADFSFQDN>/FederationMetadata/2007-06/FederationMetadata.xml (يمكنك أيضا إستخدام مضيف محلي بدلا من FQDN إذا كنت محليا على خادم ADFS). يؤدي هذا إلى تنزيل الملف FederationMetadata.xml.
3. انسخ الملف الذي تم تنزيله إلى موقع يتم فيه إنشاء الملف zip وإعادة تسميته إلى idp_config.xml.
يحتوي config.json على السمات الثلاث هذه ويجب أن تكون موجودة داخل أقواس، { }:
يجب أن يحتوي هذا الملف على المفتاح الخاص للشهادة المستخدمة للتوقيع في بيانات تعريف Webbridge التي تم إستيرادها إلى IdP. يمكن تعيين الشهادة المستخدمة للتوقيع أثناء إستيراد بيانات تعريف Webbridge في ADFS عن طريق ملء شهادة X509 بمعلومات الشهادة ضمن قسم <KeyDescriptor use=signature>. كما يمكن عرضه (واستيراده) على ADFS في WebBridge الاعتماد على جهة الثقة ضمن الخصائص > التوقيع.
في المثال التالي، يمكنك رؤية شهادة CallBridge (CN=cmscb3.brhuff.local)، والتي تمت إضافتها إلى بيانات تعريف Webbridge قبل إستيرادها إلى ADFS. المفتاح الخاص المدرج في sso_sign.key هو المفتاح الذي يطابق شهادة cmscb3.brhuff.local.
هذا تكوين إختياري ولا يلزم إلا إذا كنت تنوي تشفير استجابات SAML.
يجب أن يحتوي هذا الملف على المفتاح الخاص للشهادة المستخدمة للتشفير في بيانات تعريف 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.
2. انقر بزر الماوس الأيمن فوق ملفات الإبراز وحدد مجلد إرسال إلى > مضغوط (مضغوط).
3. بعد سحب الملفات، قم بإعادة تسميتها إلى الاسم المرغوب باستخدام البادئة sso_:
افتح عميل SFTP/SCP، في هذا المثال يتم إستخدام WinSCP، واتصل بالخادم الذي يستضيف WebBridge3.
1. في الجزء الأيسر، انتقل إلى الموقع الذي يوجد فيه ملف SSO ZIP وانقر بزر الماوس الأيمن فوق تحديد تحميل أو سحب الملف وإسقاطه.
2. بمجرد تحميل الملف بالكامل إلى خادم WebBridge3، افتح جلسة SSH وقم بتشغيل الأمر webbridge3 restart.
3. في syslog، تشير هذه الرسائل إلى أن تمكين SSO كان ناجحا:
إن البطاقة المشتركة هي عبارة عن بطاقة ذكية تعمل كهوية قياسية للأفراد العسكريين في الخدمة الفعلية، والموظفين المدنيين في وزارة الدفاع، والموظفين المتعهدين المؤهلين.
فيما يلي عملية تسجيل الدخول بالكامل للمستخدمين الذين يستخدمون بطاقات CAC:
قم بتكوين jidMapping (هذا هو اسم تسجيل الدخول للمستخدمين) في Ldapmapping بنفس ما يستخدمه ADFS لبطاقة CAC. $UserPrincipalName$ على سبيل المثال (حساس لحالة الأحرف)
قم أيضا بتعيين نفس سمة LDAP ل authenticationIdMapping لمطابقة السمة المستخدمة في قاعدة المطالبة في ADFS.
هنا، تظهر قاعدة المطالبة أنها ستقوم بإرسال $userPrincipalName$ مرة أخرى إلى CMS ك UID.
الآن بعد تكوين SSO، يمكنك إختبار الخادم:
2. يقدم للمستخدم خيار إدخال اسم المستخدم (لاحظ لا يوجد خيار كلمة مرور في هذه الصفحة).
3. تتم بعد ذلك إعادة توجيه المستخدم إلى صفحة ADFS (بعد إدخال تفاصيل المستخدم) حيث يجب على المستخدم إدخال بيانات الاعتماد الخاصة به للمصادقة على IDp.
4. تتم إعادة توجيه المستخدم، بعد إدخال بيانات الاعتماد والتحقق من صحتها باستخدام الرمز المميز للوصول إلى الصفحة الرئيسية ل Web App:
فيما يتعلق باستكشاف أي مشكلة متعلقة بالمسوحات وإصلاحها بشكل أساسي:
وسيكون من المثالي أيضا محاولة أستكشاف المشكلات وحلها من منظور السجل:
في بعض الأحيان، يكون هناك فشل لعملية SSO قد يؤدي إلى فشل تكوين IDp أو إتصاله بالمعرف. إذا كنت تستخدم ADFS، فسيكون من المثالي مراجعة الارتباط التالي لتأكيد الفشل الذي يظهر واتخاذ إجراء الإصلاح:
مثال على ذلك:
client_backend: الخطأ : برنامج SamlManager : فشل طلب مصادقة SAML _e135ca12-4b87-4443-abe1-30d396590d58 لسبب: urn:oasis:الأسماء:tc:saml:2.0:status:المستجيب
يشير هذا الخطأ إلى أنه وفقا للوثائق السابقة، حدث الفشل بسبب IdP أو ADFS وبالتالي يجب معالجته من قبل مسؤول ADFS لحل المشكلة.
يمكن أن يكون هناك مثيلات أثناء تبادل SAMLResonse مرة أخرى من IdP، يمكن ل WebBridge عرض رسالة الخطأ هذه في السجلات مع فشل في تسجيل الدخول عبر SSO:
client_backend: معلومات : برنامج 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
لحل هذه المشكلة، هناك طريقتان محتملتان لمحاولة:
في بعض الأحيان، أثناء تبادل 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 مباشرة، فلن تحتاج إلى إستيرادها مرة أخرى.)
أيضا، انتبه إلى الشرط NotBefore و NotONOrAfter: <الشرط noBefore=2021-03-30T19:35:37.071z NotOnOrAfter=2021-03-30T19:36:37.071Z>
إذا كان وقت الخادم غير صحيح، فقد يؤدي ذلك إلى انهيار الوقت من فترة الصلاحية المحددة في الشروط. ستحتاج إلى التحقق من خوادم NTP عبر واجهة سطر الأوامر باستخدام قائمة خوادم NTP لمراجعة خوادم NTP التي تم تكوينها وحالة NTP للتحقق من حالة خوادم NTP التي تم تكوينها. أستخدم تاريخ الأمر للتحقق من وقت الخوادم.
تلميح: إذا كنت تستخدم خادم NTP محلي/داخلي، فحاول تكوين خادم NTP عام مثل time.google.com (تأكد من تكوين خادم DNS عام من قبل).
فشل تسجيل الدخول
لا يمكن الوصول إلى 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)
18 مارس 54:52.698 user.err cmscb3-1 client_backend: الخطأ : برنامج SamlManager : محاولة تسجيل دخول SSO غير صالحة
18 مارس 54:52.698 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [3f93fd14-f4c9-4e5e-94d5-49bf643319e] فشل العثور على SSO في طلب رمز SAML المميز
18 مارس 54:52.698 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [3f93fd14-f4c9-4e5e-94d5-49bf643319e] محاولة العثور على SSO في طلب رمز SAML المميز
قام المستخدم بإدخال اسم المستخدم الصحيح وعرض صفحة تسجيل الدخول إلى SSO. يدخل المستخدم اسم المستخدم وكلمة المرور الصحيحين هنا أيضا، ولكن لا يزال يحصل على فشل في تسجيل الدخول
مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)
مارس 19:39:17.714 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [ef8fe67f-685c-4a81-9240-f76239379806] تطابق SSO_2024.zip في طلب رمز SAML المميز
مارس 19:39:17.714 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [ef8fe67f-685c-4a81-9240-f76239379806] محاولة العثور على SSO في SAML Idp Response
مارس 19:39:17.720 user.err cmscb3-1 client_backend: الخطأ : برنامج SamlManager : لم يتم العثور على عنصر معين ل AuthenticationId في تأكيدات SAML الموقعة
مارس 19:39:17.720 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [ef8fe67f-685c-4a81-9240-f76239379806] فشل الحصول على معرف المصادقة
سبب السيناريو 3 هو إستخدام قاعدة المطالبة في IdP لنوع مطالبة لا تتطابق مع AuthenticationIdMapping في ملف config.json المستخدم في ملف SSO zip الذي تم تحميله إلى WebBridge. يبحث WebBridge في إستجابة SAML ويتوقع أن يطابق اسم السمة ما تم تكوينه في config.json.
قاعدة المطالبة في ADFS
مثال config.json
قام المستخدم بتسجيل الدخول باسم مستخدم غير صحيح (يتطابق المجال مع ما هو موجود في ملف SSO zip الذي تم تحميله إلى WebBridge3، ولكن المستخدم غير موجود)
لم يتم التعرف على اسم المستخدم
مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)
18 مارس 58:47.777:user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] تطابق SSO_2024.zip في طلب رمز SAML المميز
18 مارس 58:47.777:user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] محاولة العثور على SSO في طلب رمز SAML المميز
18 مارس 58:47.780 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] رمز SAML المميز الذي تم إنشاؤه بنجاح
18 مارس 58:48.072 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] تطابق SSO_2024.zip في طلب رمز SAML المميز
18 مارس 58:48.072 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] محاولة العثور على SSO في SAML Idp Response
18 مارس 58:48.077:user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] تم الحصول على المصادقةID بنجاح:darmckin@brhuff.com
18 مارس 14:58:48.078 user.info cmscb3-1 host:الخادم: معلومات : WB3Cmgr: [79e9a87e-0fa4-44df-a914-bbcabb6c87c6] AuthRequestReceived لمعرف الاتصال=64004556-faea-479f-aabe-691e17783aa5 التسجيل=40a4026c-0272-42a1-b125-136fdf5612a5 (user=steve@brhuff.com)
18 مارس 14:58:48.092 user.info cmscb3-1 host:الخادم: معلومات : لم يتم العثور على أي مستخدم للتخويل
18 مارس 14:58:48.092 user.info cmscb3-1 host:الخادم: معلومات : طلب تسجيل دخول غير ناجح من steve@brhuff.com
قام المستخدم بإدخال معلومات تسجيل الدخول الصحيحة في تطبيق ويب، كما قام بإدخال بيانات الاعتماد الصحيحة للمصادقة على LDAP في صفحة SSO الخاصة به، ولكنه فشل في تسجيل الدخول، ولم يتم التعرف على اسم المستخدم.
لم يتم التعرف على اسم المستخدم
مسارات WebBridge ل CMS (بينما يتم إستخدام +trace=true)
مارس 18:08:52.114 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] تطابق SSO_2024.zip في طلب رمز SAML المميز
مارس 18:08:52.114 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] محاولة العثور على SSO في طلب رمز SAML المميز
مارس 18:08:52.117 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] رمز SAML المميز الذي تم إنشاؤه بنجاح
مارس 18:08:52.386 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] تطابق SSO_2024.zip في طلب رمز SAML المميز
مارس 18:08:52.386 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] محاولة العثور على SSO في SAML Idp Response
مارس 18:08:52.391 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [d626bbaf-80c3-4286-8284-fac6f71eb140] تم الحصول على المصادقةID بنجاح:darmckin@brhuff.com
18 مارس:08:52.391 user.info cmscb3-1 host:الخادم: معلومات : WB3Cmgr: [d626bbaf-80c3-4286-8284-fac6f71eb140] AuthRequestReceived لمعرف الاتصال=64004556-faea-479f-aabe-691e17783aa5 التسجيل=40a4026c-0272-42a1-b125-136fdf566666612a2a0a0user0a6a0a6a6a6a6a6a6adarmckin@brhuff.com0user6a6a6a6a6a6a6a6a6a0user6a6a6a6a6a6a6a6a66a6a6a66a6a6a6a6a6a6a6a6user6a66a6a6a6a6a6a6a6a6
18 مارس 15:08:52.399 user.تحذير cmscb3-1 host:server: تحذير: رفض محاولة تسجيل الدخول من المستخدم 'darmckin@brhuff.com' — معرف المصادقة غير صحيح
18 مارس:08:52.412 user.info cmscb3-1 host:الخادم: معلومات : طلب تسجيل دخول غير ناجح من darmckin@brhuff.com
لا يتطابق AuthenticationIdMapping في CMS LDAPMAPPING مع سمة LDAP التي تم تكوينها والتي تستخدم لقاعدة المطالبة في ADFS. يشير السطر الذي يقول تم الحصول على مصادقةID:darmckin@brhuff.com" بنجاح إلى أن ADFS لديه قاعدة مطالبة تم تكوينها بسمة تحصل على darmckin@brhuff.com من خدمة Active Directory، ولكن AuthenticationID في CMS API > Users يظهر أنه يتوقع الدرك. في CMS LDAPmappings، يتم تكوين AuthenticationID ك $sAMAccountName$، ولكن يتم تكوين قاعدة المطالبة في ADFS لإرسال عناوين البريد الإلكتروني، لذلك لا يتطابق ذلك.
كيفية إصلاح هذا:
قم بأي من الخيارين للتقليل:
API LDAPMapping
مثال مستخدم API
قاعدة المطالبة من ADFS
مارس 18 14:24:01.096 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [7979f13c-d490-4f8b-899c-0c82853369ba] تطابق SSO_2024.zip في طلب رمز SAML المميز
مارس 18 14:24:01.096 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [7979f13c-d490-4f8b-899c-0c82853369ba] محاولة العثور على SSO في SAML Idp Response
مارس 18 14:24:01.101 user.info cmscb3-1 client_backend: معلومات : برنامج SamlManager : [7979f13c-d490-4f8b-899c-0c82853369ba] تم الحصول على المصادقة بنجاح المعرف:darmckin@brhuff.com
مارس 18 14:24:01.102 user.info cmscb3-1 host:الخادم: معلومات : WB3Cmgr: [7979f13c-d490-4f8b-899c-0c8285369ba] AuthRequestReceived لمعرف الاتصال=64004556-faea-479f-aabe-691e17783aa5 register=40a4026c-0272-42a1-b125-136fdf5612a5a5a5f5a5-a5a5-a5f55565a5a516f61a56f165a5a5a5a5a5a5a5a5a5a5a5a5a6f5a5a5a5f5f5a5f5f5-a5a5a5-a5-a5-a5-15-15-1156f6f6(مستخدم=darmckin@brhuff.com)
مارس 18 14:24:01.130 user.info cmscb3-1 host:الخادم: معلومات : طلب تسجيل دخول ناجح من darmckin@brhuff.com
مارس 18 14:24:01.130 user.info cmscb3-1 host:الخادم: معلومات : WB3Cmgr: [7979f13c-d490-4f8b-899c-0c82853369ba] إصدار JWT ID e2a860ef-f4ef-4391-b5d5-9abdfa89ba0f
18 مارس 14:24:01.132 user.info cmscb3-1 host:الخادم: معلومات : WB3Cmgr: [7979f13c-d490-4f8b-899c-0c82853369ba] إرسال إستجابة المصادقة (jwt length=1064، الاتصال=64004556-faea-479f-aabe-691e17783aa5)
مارس 18 14:24:01.133 local7.info cmscb3-1 56496041063b wb3_front: [auth:darmckin@brhuff.com، التتبع:7979f13c-d490-4f8b-899c-0c8285369ba] 10.10.10.8 - [18/Mar/2024:18:24:000] وضع 200 "POST/API/AUTH/SSO/IdpResponse HTTP/1.1" bytes_0 http_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. Safari/537. 36 بوصة إلى الخادم 192. 0.2. 2:9000: upstream_response_time 0.038 request_time 0.039 msec 1710786241.133 upstream_response_length 24 200
يسلط هذا القسم الضوء على الأسئلة أو الموضوعات المتعلقة ب WebApp SSO على خادم الاجتماعات من Cisco.
الرمز المميز ل 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.
في بعض البيئات، اعتمادا على IDp وإعداد البيئة، يمكن تنفيذ SSO/Keep I تسجيل الدخول على ميزات IdP - التي من شأنها أن توفر للمستعرض طهية مطهية باستمرار من IdP، حيث يتم حتى إغلاق المستعرض، يتم الاحتفاظ ب cookie (ما لم يتم مسحها بوسائل أخرى). بغض النظر عن تكوين SSO/IdP - عند انتهاء صلاحية JWT (24 ساعة كحد أقصى)، يتم إجبار مستخدم WebApp على العودة إلى صفحة تسجيل الدخول إلى WebApp - ومع ذلك، في هذا السيناريو حيث يتم تمكين SSO المستمر على IdP - سيحتاج المستخدم فقط إلى الإدخال <user@domain> صفحة تسجيل الدخول إلى WebApp وليس بحاجة إلى إعادة المصادقة إلى IdP الخاص بهم.
يتم فتح تحسين لتنفيذ آلية الرمز المميز للتحديث للسماح بالتفويض الموسع ل WebApp - معرف تصحيح الأخطاء من Cisco CSCwm28758.
سيكون تدفق هذا السيناريو:
ما الذي يمكن أن يحدث في هذا السيناريو؟
بالنسبة لهذه الاجابة فهو يعتمد! يعتمد ذلك بالكامل على ما إذا كان JWT الذي توفره Callbridge قد انتهت صلاحيته عند الوصول إلى صفحة WebApp. ما دام JWT لا يزال صالحا وموجودا في التخزين، يمكنك الانتقال إلى صفحة WebApp (حتى إذا أغلقت المستعرض). تذكر أن الحد الأقصى لوقت صلاحية JWT هو 24 ساعة.
يكون SSO ل WebApp قادرا على دعم البيئات التي تحتوي على مجالات متعددة وحتى البيئات حيث تشير هذه المجالات المختلفة إلى موفري هوية مختلفين (IdPs). يرجى مراجعة أدلة نشر Cisco Meeting Server أو الاتصال ب Cisco TAC للحصول على الدعم على إستخدام مجالات متعددة.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
3.0 |
02-Oct-2024
|
سيناريوهات أستكشاف الأخطاء وإصلاحها متعددة |
1.0 |
21-Jan-2024
|
الإصدار الأولي |