المحتويات

المقدمة

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

المتطلبات

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

معلومات أساسية

شرح النموذج الأساسي للتفاعل لوضع SSO

تكوين gadgets.io.makerequest لوضع SSO و NONSSO

المقدمة

يوضح هذا المستند ما يلزم لتكامل أدوات ذكية من إنتاج جهات خارجية مع Finesse أثناء تشغيل النظام في وضع تسجيل الدخول الأحادي (SSO). كما يتم تقديم مثال لوضع NON SSO.

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

المتطلبات

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

- Cisco Finesse

- سو

- أدوات Finesse من إنتاج جهات خارجية

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

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

- Cisco Finesse، الإصدار 11.6

- سو

- أداة من طرف ثالث

- خدمة راحة الطرف الثالث.

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

معلومات أساسية

هذه هي الخطوات الأولية أثناء محاولة العميل تسجيل الدخول والمصادقة مع SSO أو NONSSO.

وتصف الخطوة الثانية ما يجب مراعاته بعد المصادقة الناجحة في حالة SSO و NONSSO.

1. في وقت تسجيل الدخول إلى سطح المكتب، تقوم Finesse باكتشاف وضع مصادقة النظام (SSO/NONSSO) واستنادا إلى وضع المصادقة، يتم عرض صفحة تسجيل الدخول المناسبة. يرى المستخدمون صفحة تسجيل دخول IDP في حالة وضع SSO وصفحة تسجيل الدخول Finesse في حالة وضع NONSSO.

2. بعد المصادقة الناجحة، تتم مصادقة جميع الطلبات استنادا إلى وضع مصادقة النظام. بالنسبة لعمليات نشر SSO، تحمل جميع الطلبات إلى Finesse الرمز المميز للوصول كجزء من رأس الطلب. تم التحقق من صحة الرمز المميز مقابل خادم IDP للمصادقة الناجحة. ومع ذلك، بالنسبة للطلبات الخاصة بخدمات الويب التابعة لجهات خارجية، يجب تعيين رأس المصادقة استنادا إلى مخطط المصادقة الذي تنفذه خدمة ويب التابعة لجهات خارجية.  في حالة نشر NONSSO، تحمل جميع الطلبات رأس المصادقة الأساسية مع اسم مستخدم وكلمة مرور مرمزين للقاعدة 64. يتم التحقق من صحة جميع الطلبات في هذه الحالة مقابل قاعدة البيانات المحلية ل Finesse.

شرح النموذج الأساسي للتفاعل لوضع SSO

تعرض هذه الصورة النموذج الأساسي للتفاعل بين الأداة الذكية من جهة خارجية ومجموعة أدوات Finesse والمعرفات وخدمة REST من جهة أخرى، عندما يكون النظام في وضع SSO.

صورة

فيما يلي وصف لكل خطوة يتم عرضها في الصورة.

1. يقوم الوكيل/المشرف بالوصول إلى عنوان URL الخاص بسطح المكتب Finesse. (مثال: https://finesse.com:8445/desktop)

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

3. يقوم المستعرض بإرسال طلب إعادة توجيه التخويل إلى IDS. عند هذه النقطة، يكتشف IDS ما إذا كان لدى المستخدم رمز وصول صالح أم لا. إذا لم يكن لدى المستخدم رمز مميز للوصول صالح، فإن IDS يعيد التوجيه إلى موفر الهوية (IdP).

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

5. يتم إرسال تأكيد SAML من IDp إلى المعرفات، والتي تعيد التوجيه إلى سطح مكتب Finesse.

6. يقوم المستعرض بتحديد صفحة Finesse لسطح المكتب.

7. تحصل Finesse على الرمز المميز للوصول من معرفات الهوية باستخدام رمز مصادقة SAML.

8. يحصل سطح المكتب على الرمز المميز للوصول المراد إستخدامه لمصادقة واجهات برمجة تطبيقات REST اللاحقة.

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

10. تتحقق خدمة REST الخاصة بجهة خارجية من الرمز المميز باستخدام المعرفات.

11. تم إرجاع إستجابة REST الخاصة بجهة خارجية إلى الأداة الذكية.

تكوين gadgets.io.makerequest لوضع SSO و NONSSO

الخطوة 1. بالنسبة لمكالمات Finesse REST API التي يتم إجراؤها عبر Shindig ، تحتاج الأدوات الذكية إلى إضافة رأس تخويل "Bearer" في رؤوس gadgets.io.makeRequest.

الخطوة 2. تحتاج الأدوات الذكية إلى إجراء المكالمات الأصلية gadgets.io.makeRequest لكافة طلبات REST، ويجب تعيين رأس التخويل داخل حزم الطلب.

بالنسبة لعمليات النشر بخلاف SSO، هذا هو رأس المصادقة.

"Basic " + base64.encode(username : password)

لعمليات نشر SSO، هذا هو رأس المصادقة.

"Bearer "  + access_token

يمكن إسترداد الرمز المميز للوصول من الكائن finesse.gadget.config.

access_token = finesse.gadget.Config.authToken

يجب إضافة رأس التخويل الجديد إلى حزم الطلبات.

params[gadgets.io.RequestParameters.HEADERS].Authorization = "Basic " + base64.encode(username : password);

params[gadgets.io.RequestParameters.HEADERS].Authorization = "Bearer "  + access_token;

الخطوة 3. تمت إضافة أسلوب أداة مساعدة getAuthHeaderString داخل utilities.Utilities. يأخذ أسلوب الأداة المساعدة هذا كائن التكوين كوسيطة ويرجع سلسلة رأس التخويل. يمكن للأدوات الذكية إستخدام أسلوب الأداة المساعدة هذا لتعيين رأس التخويل في حزم الطلب.

params[gadgets.io.RequestParameters.HEADERS].Authorization= finesse.utilities.Utilities.getAuthHeaderString(finesse.gadget.config);

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