نشر تدفق منح رمز التخويل واستكشاف أخطائه وإصلاحها - تحسين المصادقة: حلول التعاون من Cisco، الإصدار 12.0

المقدمة

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

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

المتطلبات

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

• Cisco Unified Communications Manager (CUCM)، الإصدار 12.0
• الدخول الموحد (SSO)/SAML
• Cisco Jabber
• نظام التشغيل Microsoft ADFS
• موفر الهوية (IDp)

للحصول على مزيد من المعلومات حول هذه الموضوعات، ارجع إلى الروابط التالية:

• دليل نشر SAML SSO ل Cisco Unified Communications
• Unified Communications Manager SAML SSO تشكيل مثال:
• إعداد AD FS الإصدار 2.0 لمثال تكوين SAML SSO:

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

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

• Microsoft ADFS ( IdP)
• LDAP Active Directory
• عميل Cisco Jabber
• CUCM، الإصدار 12.0

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

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

واعتبارا من اليوم، يستند تدفق Jabber SSO مع البنية الأساسية إلى تدفق المنح الضمني حيث تقوم خدمة CUCM Authz بتخصيص رموز الوصول المميزة القصيرة الأجل.

انتهاء صلاحية الرمز المميز للوصول إلى البريد، يقوم CUCM بإعادة توجيه Jabber إلى IdP لإعادة المصادقة.

يؤدي ذلك إلى تجربة مستخدم سيئة، وخاصة مع Jabber على الجوال حيث يطلب من المستخدم إدخال بيانات الاعتماد بشكل متكرر.

يقترح حل إعادة هيكلة الأمان أيضا تدفق منح رمز التخويل (باستخدام نهج رموز التحديث المميزة (نقاط النهاية الممتدة/تطبيقات التعاون الأخرى)) لتوحيد تدفق تدفق سجل نقاط النهاية و Jabber لكل من سيناريوهين SSO و SSO.

المزايا الرئيسية

• يعتمد تدفق منح رمز التخويل على رمز التحديث المميز (القابل للتوسع إلى نقاط النهاية/تطبيقات التعاون الأخرى) لتحسين تجربة مستخدم Jabber عبر الأجهزة المختلفة، وخاصة ل Jabber على الأجهزة المحمولة.
• يدعم العلامات المميزة OAuth الموقعة والمشفرة ذاتيا للسماح لتطبيقات التعاون المختلفة بالتحقق من صحة طلبات موارد العميل والاستجابة لها.
• يتم الاحتفاظ بنموذج تدفق المنح الضمني مما يسمح بالتوافق مع الإصدارات السابقة. كما يتيح هذا الأمر مسارا سلسا للعملاء الآخرين (مثل RTMT) الذين لم ينتقلوا إلى تدفق منح رمز التخويل.

اعتبارات هامة

• تنفيذ بحيث يمكن لعميل Jabber القديم العمل مع CUCM الجديد (لأنه يدعم كلا من تدفقات منح كود التفويض والمنح الضمنية). أيضا، يمكن أن يعمل Jabber الجديد مع CUCM القديم. يمكن ل Jabber تحديد ما إذا كان CUCM يدعم تدفق منح رمز التخويل وما إذا كان يدعم هذا النموذج فقط، فإنه يقوم بالتحويل ويستخدم تدفق منح ضمني.
• يتم تشغيل خدمة AuthZ على خادم CUCM.
• يدعم AuthZ تدفق المنح الضمني فقط. هذا يعني عدم وجود رمز مميز للتحديث/رمز وصول غير متصل. في كل مرة كان العميل يريد رمزا مميزا جديدا للوصول، يحتاج المستخدم إلى إعادة المصادقة باستخدام المعرف.
• تم إصدار رموز الوصول المميزة فقط في حالة تمكين SSO لعملية النشر. لم تعمل عمليات النشر بخلاف SSO في هذه الحالة ولم يتم إستخدام رموز الوصول المميزة على جميع الواجهات بشكل ثابت.
• لم يتم الاحتفاظ برموز Access المميزة ذاتيا ولكنها بالأحرى محفوظة في ذاكرة الخادم الذي قام بإصدارها. إذا أصدر CUCM1 الرمز المميز للوصول، يمكن التحقق منه بواسطة CUCM1 فقط. إذا حاول العميل الوصول إلى الخدمة على CUCM2، فيجب على CUCM2 التحقق من صحة هذا الرمز المميز على CUCM1. تأخيرات الشبكة (وضع الوكيل).
• تعد تجربة المستخدم مع أجهزة الكمبيوتر المحمولة العميلة سيئة للغاية نظرا لأنه يتعين على المستخدم إعادة إدخال بيانات الاعتماد على لوحة مفاتيح أبجدية رقمية عندما يقوم المستخدم بإعادة المصادقة مع معرف المستخدم (الذي يعمل عادة من ساعة واحدة إلى 8 ساعات وهذا يتوقف على عدة عوامل).
• يحتاج العملاء الذين يتحدثون إلى تطبيقات متعددة عبر واجهات متعددة إلى الاحتفاظ بعدة بيانات اعتماد/كتل. لا يوجد دعم سلس لنفس تسجيل الدخول من إثنين من العملاء المماثلين. على سبيل المثال، يقوم المستخدم A بتسجيل الدخول من مثيلات Jabber التي تعمل على هواتف iPhone مختلفة.
• AuthZ لدعم كل من عمليات نشر SSO وعمليات النشر بخلاف SSO.
• AuthZ لدعم تدفق المنح الضمني + تدفق منح كود التخويل. ونظرا لأنه متوافق مع الإصدارات السابقة، فإنه يسمح للعملاء مثل RTMT بمواصلة العمل حتى يتأقلموا.
• باستخدام تدفق منح كود التخويل، يصدر AuthZ الرمز المميز للوصول والرمز المميز للتحديث. يمكن إستخدام الرمز المميز للتحديث للحصول على رمز مميز آخر للوصول دون الحاجة إلى المصادقة.
• رموز الوصول المميزة هي عبارة عن وحدات قائمة بذاتها وموقعة ومشفرة وتستخدم رمز JWT (رمز JSON المميز على الويب) القياسي (متوافق مع RFC).
• مفاتيح التوقيع والتشفير شائعة في نظام المجموعة. يمكن لأي خادم في نظام المجموعة التحقق من الرمز المميز للوصول. لا حاجة إلى المحافظة على الذاكرة.
• الخدمة التي تعمل على CUCM 12.0 هي خادم المصادقة المركزية في المجموعة.
• يتم تخزين رموز التحديث المميزة في قاعدة البيانات (DB). يجب أن يكون المسؤول قادرا على إبطاله، إذا لزم الأمر. يستند الإبطال إلى معرف المستخدم أو معرف المستخدم ومعرف العميل.
• تتيح رموز الوصول المميزة الموقعة للمنتجات المختلفة التحقق من رموز الوصول المميزة دون الحاجة إلى تخزينها. الرمز المميز للوصول القابل للتكوين وأوقات عمل الرمز المميز للتحديث (الافتراضي هو 1 ساعة و 60 يوما على التوالي).
• يتم محاذاة تنسيق JWT مع Spark الذي يسمح بأوجه التآزر في المستقبل مع خدمات Spark Hybrid.
• دعم نفس المستخدم يسجل الدخول من جهازين مماثلين. eg: يمكن للمستخدم A تسجيل الدخول من مثيلات Jabber التي تعمل على هواتف iPhone مختلفة.

عناصر تدفق منح كود التخويل

• خادم Auth Z
• مفاتيح التشفير
• مفاتيح التوقيع
• تحديث الرموز المميزة

التكوين

لا يتم تمكين هذه الميزة بشكل افتراضي.

الخطوة 1. لتمكين هذه الميزة، انتقل إلى نظام > معلمات المؤسسة.

الخطوة 2. قم بتعيين OAuth للحزم مع تمكين تدفق تسجيل الدخول للتحديث كما هو موضح في الصورة.

• تم توقيع الرمز المميز للوصول وتشفيره. مفتاح التوقيع والتشفير شائع في نظام المجموعة. وهذا يعني أنه يمكن لأي عقدة في نظام المجموعة التحقق من صحة الرمز المميز للوصول.
• الرمز المميز للوصول موجود بتنسيق JWT (RFC 7519).
• تقوم رموز الوصول المميزة بإعادة إستخدام معلمة المؤسسة (مؤقت انتهاء صلاحية الرمز المميز للوصول إلى OAuth)، والتي يتم تطبيقها لكل من تنسيقات الرموز المميزة القديمة والجديدة.
• القيمة الافتراضية - 60 دقيقة.
• الحد الأدنى للقيمة - دقيقة واحدة.
• الحد الأقصى للقيمة - 1440 دقيقة

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMjpjMjc3MGM5N2JkYTlkMzRmZDA1YTdlYTFhZWQzZTU0Y2E4MGJkZDdlZTM1ZDk3MDNiNjBiNTQ5MTBiZDQ0ODRiIn0.eyJwcml2YXRlIjoiZXlKaGJHY2lPaUprYVhJaUxDSmpkSGtpT2lKS1YxUWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySWl3aWEybGtJam9pT0dRd1pEVXpNalF0WmpSbU1DMDBZakJpTFRneE1XVXROR0UxT1daa1lqWmlOekl5T21Vd1ptUm1ZMk16WlRRMU5ERTFOV0ZpTkRJek5tRTJOMlV4T0RCbU1qWmxZMkl3WXpJeE56SXlOREJtWlRFellXWXlOak14TkRkalpHVXpNR1l3TjJJaWZRLi5xQWd6aGdRaTVMMkdlaDl5V2RvN25nLmdMTHNpaTRjQk50c1NEUXRJTE51RWRnWTl4WkJVczJ4YzBaeTFGQjZQNmNzWWJfZkRnaDRZby04V1NaNjUzdXowbnFOalpXT1E1dGdnYW9qMlp6ZFk2ZzN2SWFHbF9JWUtNdkNIWWNscmt4YUFGTk5MWExLQlJmaTA2LVk2V3l1dUdxNmpNWk5DbnlKX1pTbUpkVFQwc1Z4RTdGTXVxaUJsMElrRGdyVDdvOFNXMEY5cXFadndEZDJSaDdqNkRJWGdkS3VtOWltU2xNU1pjejhueVdic01Udk5yMWY0M25VenJzMHk5WWN6NnBDX0czZmlWYjJsX2VWLVFkcFh4TUo2bnZodXcydjRiUGVkM3VMQlpaVW1oQ3B6TUVDdW5NMlh1TVBrTGdlS1NqWG44aGhPRFNVcW1WQ0Uta3RZdnRBc2Q0RnJxcGNxWlZiS0ZiVTFRbU0wV2pMYVJtUk9IVllQVkc0a3FBdTRWalVMUzVCRWszNnZ4Nmp3U3BMUy1IdTcwbVRNcmR3dmV5Q2ZOYkhyT0FlVmVvekFIR3JqdGlmaFpmSFVUTWZiNkMtX2tOQVJGQWdDclZTZy0wUzlxb1JvTWVkUENETEE4MDJiaWwtNDJjOC15MWo4X1FVaC02UUtCV2dodVd4VWtBODRpekFFaWl0QTlsSHFKM3Nxd2JFNURkZmhIay05bTJfTTN5MWlWVkdoRVQ3ZW9XVDBqWllnRGRBQjFzUGwxLTlaSFNYYmsydTE3SkJVRV9FOXI0V0tWMnBqWGtiN0lQSWgtQ3JWQTZkcVdQRHVIbmx1V19wblNLYnYtTkZVbGQ0WEY3cmZLYmQySlg4eUhhX05pOVVVUnUwZVdsNWxGRUVabklubmFKZEdHLUZrb3VuN2xHSFlwSE4ydXVudmRnOHZVZzZsa0JPbmozeUFjc1ZTMGxKc1NWdUxFYldwd2c4YjdBdDM3d3AtMWt2Y1ZQaWpCQ1lCV181d2JzbTFYd2k4MVc2WHVpNzMzQVg3cEJVQnBfT2VRNzQ2ZXJJekNUUFZCYUpZUGJuZWEtdFhsU3RmZzBGeVRmbnhnX1Vzazl3QXJkemE4c204T0FQaWMxZmFQOG0uUTdFN0FVX2xUVnNmZFI2bnkydUdhQSJ9.u2fJrVA55NQC3esPb4kcodt5rnjc1o-5uEDdUf-KnCYEPBZ7t2CTsMMVVE3nfRhM39MfTlNS-qVOVpuoW_51NYaENXQMxfxlU9aXp944QiU1OeFQKj_g-n2dEINRStbtUc3KMKqtz38BFf1g2Z51sdlnBn4XyVWPgGCf4XSfsFIa9fF051awQ0LcCv6YQTGer_6nk7t6F1MzPzBZzja1abpm--6LNSzjPftEiexpD2oXvW8Vl0Z9ggNk5Pn3Ne4RzqK09J9WChaJSXkTTE5G39EZcePmVNtcbayq-L2pAK5weDa2k4uYMfAQAwcTOhUrwK3yilwqjHAamcG-CoiPZQ

 

OAuth Refresh Token Expiry Timer” parameter in enterprise parameters page in CUCM.
Path: System -> Enterprise parameters
Values are integers ranging from 1 – 90
Minimum lifetime = 1 Day
Default lifetime = 60 days
Maximum lifetime = 90 days

يتم إصدار رمز مميز للوصول جديد في كل مرة يطلب فيها العميل الحصول على رمز مميز. لا يزال القديم صالحا طالما:

• لم يتم تغيير مفاتيح التوقيع/التشفير
• فواصل الصلاحية (المخزنة داخل الرمز المميز).
• وحدات JSON المميزة على الويب: تتكون من ثلاثة أجزاء، يفصل بينها نقاط، وهي: الرأس والحمولة والتوقيع.

نموذج الرمز المميز للوصول:

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

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

فيما يلي نظرة عامة عالية المستوى على تدفق المكالمات المعني:

تحديث الرموز المميزة

• تم توقيع الرمز المميز للتحديث.
• يتم تخزين الرمز المميز للتحديث في جدول RefreshTokenDetails في قاعدة البيانات كقيمة تجزئة خاصة بها. الغرض من هذا هو منع النسخ المتماثل بواسطة قاعدة البيانات حيث يمكن أن يقوم شخص ما باختياره. لمراجعة الجدول يمكنك تشغيله:

  run sql select * from refreshtokendetails

  أو بتاريخ صلاحية قابل للقراءة:
  

  run sql select pkid,refreshtokenindex,userid,clientid,dbinfo('utc_to_datetime',validity) as validity,state from refreshtokendetails

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

Sample refresh token:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMjpjMjc3MGM5N2JkYTlkMzRmZDA1YTdlYTFhZWQzZTU0Y2E4MGJkZDdlZTM1ZDk3MDNiNjBiNTQ5MTBiZDQ0ODRiIn0.eyJleHAiOjE1MDI2MjAwNTIsImlzcyI6IjhkMGQ1MzI0LWY0ZjAtNGIwYi04MTFlLTRhNTlmZGI2YjcyMiIsInR5cCI6InVzZXIiLCJ0aWQiOiJiOTkxMjIxZi1mNDJlLTRlNTItODg3MS1jODc2ZTYzNWRkNWIiLCJjdHlwIjoicmVmcmVzaCIsImNjaWQiOiJDM2IwYWZmZWZlMTQzOTA0MTY4M2U5YzJjMzdkMzZmNDM4ZWYwZWYyN2MwOTM4YWRjNjIyNmUwYzAzZDE2OWYyYSJ9.creRusfwSYAMAtttS2FIPAgIVvCiREvnzlouxeyGVndalJlMa-ZpRqv8FOBrsYwqEyulrl-TeM8XGGQCUvFaqO9IkhJqSYz3zvFvvySWzDhl_pPyWIQteAhL1GaQkue6a5ZegeHRp1sjEczKMLC6H68CHCfletn5-j2FNrAUOX99Vg5h4mHvlhfjJEel3dU_rciAIni12e3LOKajkzFxF6W0cXzzujyi2yPbY9gZsp9HoBbkkfThaZQbSlCEpvB3t7yRfEMIEaHhEUU4M3-uSybuvitUWJnUIdTONiWGRh_fOFR9LV3Iv9J54dbsecpsncc369pYhu5IHwvsglNKEQ

 

إبطال رموز التحديث المميزة

للمسؤول القدرة على إبطال جميع رموز التحديث المميزة للمستخدم أو الجهاز فقط من خلال معرف المستخدم أو معرف المستخدم ومعرف العميل.

لإبطال RTs المستندة إلى جهاز لمستخدم:

• إبطال RT للمستخدم xyz والجهاز المحدد بواسطة client_id abc.
• https://cucm-193:8443/ssosp/token/revoke?user_id=xyz&client_id=abc

مفاتيح التوقيع والتشفير

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

يتم إعادة إنشاء شهادات AUTHZ (مفتاح التوقيع) من صفحة إدارة نظام التشغيل الموحد من Cisco على CUCM كما هو موضح في الصورة.

يتم إستعادة مفتاح توقيع Authz باستخدام أمر CLI كما هو موضح في الصورة.

يمكن للمسؤول عرض مفاتيح التوقيع والتشفير باستخدام CLI. يتم عرض تجزئة المفتاح بدلا من المفتاح الأصلي.

الأمر الخاص بعرض المفاتيح هو:

مفتاح التوقيع: إظهار توقيع المفتاح وكما هو موضح في الصورة.

مفتاح التشفير: show key authz encryption وكما هو موضح في الصورة.

ملاحظة: دائما ما يكون كل من مصادقة التوقيع والتشفير مختلفين.

التحقق من الصحة

استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.

عندما يراد إستخدام OAuth على خادم Cisco Unity Connection (CUC)، يجب على مسؤول الشبكة تنفيذ خطوتين.

الخطوة 1. قم بتكوين خادم Unity Connection لجلب توقيع رمز OAuth المميز ومفاتيح التشفير من CUCM.

الخطوة 2. قم بتمكين خدمات OAuth على خادم CUC.

ملاحظة: لجلب مفاتيح التوقيع والتشفير، يجب تكوين الوحدة باستخدام تفاصيل مضيف CUCM وحساب مستخدم تم تمكينه للوصول إلى CUCM AXL. في حالة عدم تكوين هذا، يتعذر على خادم Unity إسترداد رمز OAuth المميز من CUCM ولا يمكن توفير سجل دخول البريد الصوتي للمستخدمين.

انتقل إلى إدارة Cisco Unity Connection Administration > إعدادات النظام > خوادم Authz

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

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

ملاحظة: إذا تم إستخدام OAuth وتعذر على مستخدمي Cisco Jabber تسجيل الدخول، راجع دائما مفاتيح التوقيع والتشفير من خوادم CUCM و Instant Messaging و Presence (IM&P).

يحتاج مسؤولو الشبكة إلى تشغيل هذين الأمرين على جميع عقد CUCM و IM&P:

• إظهار توقيع مصادقة المفتاح
• show key authz encryption

إذا لم تتطابق مخرجات مصادقة التوقيع والتشفير عبر جميع العقد، فإنها تتطلب إعادة الإنشاء. لتنفيذ ذلك، يلزم تشغيل هذين الأمرين على جميع عقد CUCM و IM&P:

• تعيين تشفير مرجع المفتاح
• تعيين توقيع مرجع المفتاح

بعد ذلك، يلزم إعادة تشغيل خدمة Cisco Tomcat على جميع العقد.

مع عدم تطابق المفاتيح، يمكن العثور على سطر الخطأ هذا على سجلات Cisco Jabber:

2021-03-30 14:21:49,631 WARN  [0x0000264c] [vices\impl\system\SingleSignOn.cpp(1186)] [Single-Sign-On-Logger] [CSFUnified::SingleSignOn::Impl::handleRefreshTokenFailure] - Failed to get valid access token from refresh token, maybe server issue.

يتم إنشاء سجلات تطبيق SSO في هذه المواقع:

• عملية عرض الملف platform/log/ssoApp.log لا يتطلب هذا أي تكوين تتبع لمجموعة السجلات. في كل مرة يتم فيها تنفيذ عملية تطبيق SSO، يتم إنشاء إدخالات سجل جديدة في ملف ssoApp.log.

• سجلات SSOSP: قائمة الملفات ActiveModel/log/ssosp/log4j
  في كل مرة يتم تمكين SSO، يتم إنشاء ملف سجل جديد في هذا الموقع باسم، ssosp00xx.log. كما يتم تسجيل دخول هذا الملف لأي عملية SSO أخرى وكل عمليات OAUTH.

• سجلات الشهادات: قائمة الملفات نشط النظام الأساسي/log/certMgmt*.log
  في كل مرة يتم فيها إنشاء شهادة AuthZ (UI أو CLI)، يتم إنشاء ملف سجل جديد لهذا الحدث.
  لإعادة إنشاء مفتاح تشفير Authz، يتم إنشاء ملف سجل جديد لهذا الحدث.

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

نشر OAuth مع حل التعاون من Cisco، الإصدار 12.0