تسجيل الدخول الأحادي ومركز التحكم

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

يستخدم بروتوكول اتحاد لغة ترميز تأكيد الأمان (SAML 2.0) لتوفير مصادقة الدخول الموحد (SSO) بين سحابة Webex وموفر الهوية ( IdP).

ملفات التعريف

يدعم تطبيق Webex ملف تعريف الدخول الموحد (SSO) لمتصفح الويب فقط. في ملف تعريف الدخول الموحد (SSO) في مستعرض الويب، يدعم Webex App الروابط التالية:

  • SP بدأت آخر -> آخر ملزمة

  • SP بدأت إعادة توجيه -> بعد الربط

تنسيق معرف الاسم

يدعم بروتوكول SAML 2.0 العديد من تنسيقات NameID للتواصل حول مستخدم معين. يدعم تطبيق Webex تنسيقات NameID التالية.

  • urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • urn:oasis:names:tc:SAML:1.1:nameid-format:غير محدد

  • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

في بيانات التعريف التي تقوم بتحميلها من موفر الهوية، يتم تكوين الإدخال الأول للاستخدام في Webex.

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

يدعم Webex App ملف تعريف تسجيل الخروج الفردي. في تطبيقWebex، يمكن للمستخدم تسجيل الخروج من التطبيق، والذي يستخدم بروتوكول تسجيل الخروج الفردي من SAML لإنهاء الجلسة وتأكيد تسجيل الخروج باستخدام موفر الهوية. تأكد من تكوين موفر الهوية لتسجيل الخروج الفردي.

دمج Control Hub مع Shibboleth

تعرض أدلة التهيئة مثالا محددا لتكامل الدخول الموحد (SSO) ولكنها لا توفر تكوينا شاملا لجميع الاحتمالات. على سبيل المثال، يتم توثيق خطوات التكامل الخاصة بتنسيق nameid-formaturn:oasis:names:tc:SAML:2.0:nameid-format:transient . ستعمل التنسيقات الأخرى مثل urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified أو urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress على تكامل الدخول الموحد (SSO) ولكنها خارج نطاق وثائقنا.

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

تشير خطوات الدمج إلى Shibboleth 2.4.5 في CentOS 7 مع Tomcat 7 كخادم ويب.

قبل البدء

فيما يتعلَّق بتسجيل الدخول الفردي وControl Hub، يجب أن يتوافق موفرو التعريف مع مواصفات لغة توصيف تأكيد الأمان 2.0 (SAML). بالإضافة إلى ذلك، يجب تكوين موفري التعريف بالطريقة التالية:

قم بتنزيل البيانات الوصفية Webex إلى نظامك المحلي

1

من طريقة عرض العميل في https://admin.webex.com، انتقل إلى إعدادات الإدارة > المؤسسة، ثم قم بالتمرير إلى المصادقة، ثم قم بالتبديل إلى إعداد تسجيل الدخول الموحد لبدء تشغيل معالج الإعداد.

2

اختر نوع الشهادة لمؤسستك:

  • موقعّة ذاتيًا بواسطة Cisco— نوصي بهذا الخيار. دعنا نوقع على الشهادة بحيث تحتاج فقط إلى تجديدها مرة واحدة كل خمس سنوات.
  • موقعة بواسطة سلطة اعتماد عامة— أكثر أمانًا ولكنك ستحتاج إلى تحديث بيانات التعريف بصورة متكررة (ما لم يدعم موفر IdP لديك نقاط إرساء الثقة).

مراسي الثقة هي مفاتيح عامة تعمل كسلطة للتحقق من شهادة التوقيع الرقمي. لمزيد من المعلومات، راجع وثائق موفر الهوية.

3

قم بتنزيل ملف البيانات الوصفية.

اسم ملف بيانات تعريف Webex هو idb-meta--SP.xml.

تكوين التفويض في ملفات Shibboleth

بعد تثبيت Shibboleth، يتم توفير ملفات التكوين مع أمثلة.

1

انتقل إلى الدليل /opt/shibboleth-idp/conf للوصول إلى ملفات المثال.

2

تحديد طريقة المصادقة التي تريد استخدامها - على سبيل المثال، يرتبط LDAP بدليل Active Directory.

3

قم بتحرير ملف handler.xml كما يلي:

إلغاء التعليق

   urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

تعليق

 urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
4

املأ تفاصيل Active Directory الخاص بك للسماح بالمصادقة. قم بتوفير التكوين إلى الملف login.config.

ShibUserPassAuth { edu.vt.middleware.ldap.jaas.LdapLoginModule required ldapUrl="ldap://ad0a.cisco.net:389" ssl="false" tls="false" baseDn="cn=Users,dc=cisco,dc=net" subtreeSearch="true" userFilter="sAMAccountName={0}" bindDn="cn=Administrator,cn=Users,dc=cisco,dc=net" bindCredential="ThePassword"; };

تكوين مكونات موفر خدمة Shibboleth لتأكيد SAML

1

أضف الملف الذي قمت بتنزيله من Webex SP إلى الدليل /opt/shibboleth-idp/بيانات التعريف.

2

قم بتحرير ملف relying-party.xml ؛ بعد علامة DefaultRelyingParty، أضف تفاصيل تأكيد SAML لـ Webex.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8- 22de53230d1e" موفر ="https://shib9a.cisco.net/idp/shibboleth" defaultSigningCredentialRef="IdPCredential"> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/>

بالنسبة للمعرف، يجب عليك استخدام قيمة EntityID من ملف بيانات تعريف Webex. استبدل معرف المثال بـ EntityID الخاص بمؤسستك.

3

داخل بيانات التعريف:علامة MetadataProvider، أضف موقع الملف:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini ngMetadataProvider" xsi:type="metadata:FilesystemMetadataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />  <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metadata/ucxn9a-single-agreement.xml" />  <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="ur  <!-- تكوين Cisco CI <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m ace:shibboleth:2.0:metadata" id="CI" metadataFile="/opt/shibboleth-idp/metadata/ idb-meta-ea7c1420-711d-4916-95f8-22de53230d1e-SP.xml" />

تأتي بيانات تعريف SP من ملف في نظام ملفات Shibboleth، في الموقع الذي قمت فيه بتحميل بيانات التعريف لمؤسسة Webex الخاصة بك.

تكوين سمات التأكيد

1

في قسم "موصل البيانات"، حدد مكان استرداد السمات المتعلقة بالمستخدمين لديك.

Active Directory، مع معرّف MyLDAP.

  <![CDATA[ (sAMAccountName=$requestContext.principalName) ]]>

2

في قسم تعريف السمة، احتفظ بما هو موجود بالفعل في التكوين من أجل transientID.

3

أضف السمة الإضافية التي تتوقعها SP، وحدد ما ترتبط به في مصدر السمة.

يمكنك ربط بريد السمة (سمة عنوان البريد الإلكتروني في Active Directory) بمعرف المستخدم (معرف المستخدم في Webex).

4

حدد السمة التي سيتم توفيرها لكل اتفاقية SP في ملف attribute-filter.xml .

قم بتوفير سمة معرف المستخدم إلى Webex التي ترتبط بعنوان البريد الإلكتروني للمستخدم.

حرر معرف السمة لاتفاق SP مع Webex.

 <afp:AttributeFilterPolicy id="ReleaseToCI"> <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-22de53230d1e" /> <afp:AttributeRule attributeID="transientId"> <afp:PermitValueRule xsi:type="basic:ANY"/> </afp:AttributeRule xsi:type="basic:ANY" /> </afp:AttributeFilterPolicy>

يجب أن تحتوي القاعدة التي قمت بإنشائها في attribute-resolver.xml على سياسة لتحرير سمة البريد-attr إلى EntityID التي تتطابق مع Webex.

5

قم بتنزيل ملف بيانات التعريف من خادم Shibboleth في /opt/shibboleth-idp/بيانات التعريف. اسم الملف هو idp-metadata.xml.

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

بعد تصدير بيانات تعريف Webex وتكوين موفر الهوية وتنزيل بيانات تعريف موفر الهوية إلى نظامك المحلي، تصبح جاهزا لاستيرادها إلى مؤسسة Webex من مركزالتحكم.

قبل البدء

لا تختبر تكامل الدخول الموحد (SSO) من واجهة موفر الهوية (IdP). نحن ندعم فقط عمليات التدفقات التي بدأها موفر الخدمة (التي بدأها مزود الخدمة)، لذلك يجب عليك استخدام اختبار الدخول الموحد (SSO) لمركز التحكم لهذا التكامل.

1

اختر واحدا:

  • ارجع إلى صفحة تحديد الشهادة في متصفحك، ثم انقر على التالي.
  • إذا لم يعد Control Hub مفتوحًا في علامة تبويب المستعرض، من عرض العميل في https://admin.webex.com، انتقل إلى الإدارة > إعدادات المؤسسة، وقم بالتمرير إلى المصادقة، ثم اختر الإجراءات > استيراد بيانات التعريف.
2

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

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

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

لا يوقع Okta على بيانات التعريف، لذا يجب عليك اختيار أقل أمانًا لدمج Okta SSO.

3

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

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

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

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

4

ارجع إلى علامة التبويب مستعرض مركز التحكم.

  • إذا كان الاختبار ناجحا، فحدد اختبار ناجح. فعل الدخول الموحد (SSO) وانقر على التالي.
  • إذا لم ينجح الاختبار، فحدد اختبار غير ناجح. أوقف الدخول الموحد (SSO ) وانقر على التالي.

لا يسري تهيئة الدخول الموحد (SSO) في مؤسستك إلا إذا اخترت زر الاختيار الأول وقمت بتنشيط الدخول الموحد (SSO).

التصرف التالي

استخدم الإجراءات الموجودة في مزامنة مستخدمي Okta في Cisco Webex Control Hub إذا كنت ترغب في توفير المستخدمين من Okta إلى Webex على السحابة.

استخدم الإجراءات الموجودة في مزامنة مستخدمي Azure Active Directory في Cisco Webex Control Hub إذا كنت ترغب في توفير المستخدمين من Azure AD في Webex على السحابة.

يمكنك اتباع الإجراء الموجود في منع رسائل البريد الإلكتروني التلقائية لتعطيل رسائل البريد الإلكتروني التي يتم إرسالها إلى مستخدمي تطبيق Webex الجدد في مؤسستك. يحتوي المستند أيضا على أفضل الممارسات لإرسال المراسلات إلى المستخدمين في مؤسستك.