תודה על המשוב.
שילוב כניסה יחידה ב-Control Hub
משוב?לפני שילוב כניסה יחידה (SSO), Webex משתמש באימות בסיסי כברירת מחדל. אימות בסיסי דורש מהמשתמשים להזין את שם המשתמש והסיסמה שלהם ב-Webex בכל פעם שהם מתחברים. אם יש לך ספק זהויות (IdP) משלך בארגון שלך, תוכל לשלב אותו עם הארגון שלך ב-Control Hub עבור SSO. SSO מאפשר למשתמשים שלך להשתמש בקבוצה אחת ומשותפת של אישורים עבור יישומי Webex בארגון שלך.
אם אתה מעדיף להשתמש באימות בסיסי, אינך צריך לפעול. עם זאת, קחו בחשבון שאימות בסיסי עשוי להיות פחות מאובטח ופחות נוח למשתמשים מאשר SSO, במיוחד אם הארגון שלכם כבר משתמש ב-IdP. לקבלת אבטחה משופרת עם אימות בסיסי, אנו ממליצים להשתמש באימות רב-גורמי (MFA) במרכז הבקרה. למידע נוסף, ראה הפעלת שילוב אימות רב-גורמי ב-Control Hub.
הפתרונות הבאים לניהול גישה לאינטרנט ולביצוע איחוד נבדקו עבור ארגוני Webex. המסמכים המקושרים למטה מדריכים אותך כיצד לשלב את ספק הזהויות (IdP) הספציפי הזה עם ארגון Webex שלך.
מדריכים אלה סוקרים שילוב של SSO בשירותי Webex המנוהלים ב-Control Hub (https://admin.webex.com). אם אתה רוצה להגדיר שילוב SSO באתר Webex Meetings (מנוהל בניהול האתר), קרא את הגדרת כניסה יחידה לאתר Cisco Webex.
אם ברצונך להגדיר SSO עבור ספקי זהויות מרובים בארגון שלך, עיין ב- SSO עם ספקי זהויות מרובים ב-Webex.
אם אינך רואה את ה-IDP שלך רשום למטה, בצע את השלבים הכלליים בלשונית הגדרת SSO במאמר זה.
כניסה יחידה (SSO) מאפשרת למשתמשים להיכנס ל-Webex בצורה מאובטחת באמצעות אימות מול ספק הזהויות (IdP) המשותף של הארגון שלך. יישום Webex משתמש בשירות Webex כדי לתקשר עם שירות הזהויות של פלטפורמת Webex. שירות הזהויות מבצע אימות עם ספק הזהויות (IdP) שלך.
מגדירים את התצורה ב-Control Hub. סעיף זה מספק הנחיות לשלבים כלליים לשילוב IdP של צד שלישי.
כאשר אתה מגדיר SSO עם ה-IdP שלך, אתה יכול למפות כל תכונה ל-uid. לדוגמה, מפה את userPrincipalName, כינוי דוא"ל, כתובת דוא"ל חלופית או כל תכונה אחרת שמתאימה ל-uid. ה-IdP צריך להתאים לאחת מכתובות הדוא"ל של המשתמש ב-uid בעת הכניסה לחשבון. Webex תומך במיפוי של עד 5 כתובות דוא"ל ל-uid.
אנו ממליצים לכלול יציאה יחידה (SLO) בתצורת המטה-דאטה שלך בעת הגדרת איחוד SAML של Webex. שלב זה חיוני כדי להבטיח שאסימוני המשתמש יבוטלו הן אצל ספק הזהויות (IdP) והן אצל ספק השירות (SP). אם תצורה זו לא מבוצעת על ידי מנהל מערכת, Webex מתריע למשתמשים לסגור את הדפדפנים שלהם כדי לבטל כל הפעלה שנותרה פתוחה.
עבור SSO ו-Control Hub, ספקי הזהויות חייבים להתאים למפרט SAML 2.0. בנוסף, יש להגדיר ספקי IdP באופן הבא:
-
הגדר את התכונה פורמט NameID ל- urn:oasis:names:tc:SAML:2.0:nameid-format:חוֹלֵף
-
הגדר בעלות על ה-IdP בהתאם לסוג ה-SSO שאתה פורס:
-
SSO (עבור ארגון) – אם אתה מגדיר SSO מטעם ארגון, הגדר את הבעלות על ה-IDP כך שתכלול את ה-uid של שם התכונה עם ערך שממופה לתכונה שנבחרה במחבר ספר הטלפונים, או לתכונת המשתמש התואמת לזו שנבחרה בשירות הזהויות של Webex. (למשל, תכונה זו יכולה להיות כתובות דוא"ל או השם העיקרי של המשתמש (UPN).)
-
Partner SSO (עבור ספקי שירות בלבד) - אם אתה מנהל מערכת של ספק שירות שמגדיר את Partner SSO לשימוש על ידי ארגוני הלקוחות שספק השירות מנהל, הגדר את הבעלות על ה-IdP כך שתכלול את התכונה דואר (במקום uid). הערך חייב למפות לתכונה שנבחרה במחבר ספר הטלפונים, או לתכונת המשתמש התואמת את זו שנבחרה בשירות הזהויות של Webex.
למידע נוסף על מיפוי תכונות מותאמות אישית עבור SSO או Partner SSO, ראה https://www.cisco.com/go/hybrid-services-directory.
-
-
Partner SSO בלבד. ספק הזהויות חייב לתמוך במספר כתובות URL של שירות צרכן קביעה (ACS). לדוגמאות המציגות איך להגדיר מספר כתובות URL של ACS בספק זהויות, ראה:
-
השתמש בדפדפן נתמך: אנו ממליצים על הגרסה העדכנית ביותר של Mozilla Firefox או Google Chrome.
-
השבת את כל חוסמי החלונות הקופצים בדפדפן שלך.
מדריכי התצורה כוללים דוגמה ספציפית לשילוב SSO אך אינם מספקים הגדרות לקביעת תצורה לכל האפשרויות. לדוגמה, שלבי האינטגרציה עבור nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient מתועדים. פורמטים אחרים כגון urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress יעבדו לשילוב SSO אך הם מחוץ לתחום התיעוד שלנו.
עליך ליצור הסכם SAML בין שירות הזהויות של פלטפורמת Webex לבין ה-IdP שלך.
אתה צריך שני קבצים כדי ליצור הסכם SAML מוצלח:
-
קובץ מטה-נתונים מה-IdP, להעביר ל-Webex.
-
קובץ מטה-נתונים מ-Webex, להעביר ל-IdP.
זוהי דוגמה לקובץ מטה-נתונים של PingFederate עם מטה-נתונים מה-IdP.
קובץ מטה-נתונים משירות הזהויות.
להלן המידע שאתה מצפה לראות בקובץ המטה-נתונים משירות הזהויות.
-
EntityID - מספר זה משמש לזיהוי הסכם ה-SAML בתצורת IdP
-
אין דרישה לבקשת AuthN חתומה או להצהרות סימנים כלשהן, היא תואמת למה שה-IdP מבקש בקובץ המטה-נתונים.
-
קובץ מטה-נתונים חתום עבור ה-IdP כדי לאמת שהמטה-נתונים שייכים לשירות הזהות.
| 1 |
היכנס למרכז הבקרה. |
| 2 |
עבור אל . |
| 3 |
עבור אל הכרטיסייה ספק זהויות ולחץ על הפעל SSO. |
| 4 |
בחר Webex כ-IdP שלך ולחץ על הבא. |
| 5 |
סמן קראתי והבנתי כיצד Webex IdP פועל ולחץ על הבא. |
| 6 |
הגדר כלל ניתוב. לאחר שהוספת כלל ניתוב, ספק הזהויות שלך נוסף ומוצג תחת הכרטיסייה ספק זהויות.
למידע נוסף, עיין ב- SSO עם מספר IdPs ב-Webex.
|
בין אם קיבלת הודעה על תעודה שפג תוקפה ובין אם אתה רוצה לבדוק את תצורת ה-SSO הקיימת שלך, אתה יכול להשתמש בתכונות הניהול של כניסה יחידה (SSO) ב-Control Hub לניהול תעודות ולפעילויות תחזוקה כלליות של SSO.
אם אתה נתקל בבעיות בשילוב ה-SSO שלך, השתמש ברשימת הדרישות ובנוהל המפורטים בסעיף זה כדי לפתור בעיות בהעברת SAML בין ה-IdP שלך ל-Webex.
-
כדי לפתור בעיות, השתמש בדפדפן האינטרנט שבו התקנת את כלי המעקב של SAML לאיתור באגים ועבור לגרסת האינטרנט של Webex בכתובת https://web.webex.com.
להלן זרימת ההודעות בין יישום Webex, שירותי Webex, שירות הזהות של פלטפורמת Webex וספק הזהות (IdP).
| 1 |
עבור אל https://admin.webex.com וכאשר האפשרות SSO מופעלת, תופיע הודעה על המסך שמבקשת להזין כתובת דוא"ל.
 היישום שולח את המידע לשירות Webex אשר מאמת את כתובת הדוא"ל.
|
| 2 |
היישום שולח בקשת GET לשרת ההרשאה של OAuth לקבלת אסימון. הבקשה מועברת לשירות הזהויות ל-SSO או לתהליך של שם משתמש וסיסמה. כתובת ה-URL של שרת האימות מוחזרת. אתה יכול לראות את בקשת ה-GET בקובץ המעקב.
בקטע של הפרמטרים השירות מחפש קוד OAuth, דוא"ל של המשתמש ששלח את הבקשה ופרטי OAuth אחרים כגון ClientID, redirectURI ו-Scope.
|
| 3 |
יישום Webex מבקש הצהרת SAML מה-IdP באמצעות SAML HTTP POST.
כאשר אפשרות ה-SSO מופעלת, מנוע האימות בשירות הזהויות מפנה אל כתובת ה-URL של ה-IdP עבור SSO. כתובת ה-URL של ה-IdP שסופקה בעת החלפת המטה-נתונים.
בדוק בכלי המעקב אם מופיעה הודעת SAML POST. תוכל לראות הודעת HTTP POST ל-IdP שהתבקשה על ידי IdPbroker.
הפרמטר RelayState מציג את התשובה הנכונה מה-IdP.
בדוק את הגרסה המפוענחת של בקשת ה-SAML , שאין הרשאת AuthN ושיעד התשובה הוא כתובת היעד (URL) של ה-IdP. ודא שפורמט ה-nameid מוגדר כהלכה ב-IdP תחת ה-entityID הנכון (SPNameQualifier)
תבנית ה-IDP nameid מצוינת ושם ההסכם מוגדר כאשר הסכם SAML נוצר. |
| 4 |
האימות של היישום מתרחש בין משאבי האינטרנט של מערכת ההפעלה לבין ה-IdP.
בהתאם ל-IdP שלך ולמנגנוני האימות המוגדרים ב-IdP, תהליכים שונים מופעלים ב-IdP.
|
| 5 |
היישום שולח HTTP Post בחזרה לשירות הזהויות וכולל את התכונות שסופקו על ידי ה-IdP ואשר הוסכם עליהן בהסכם הראשוני.
כאשר האימות מצליח, היישום שולח את המידע בהודעת SAML POST לשירות הזהויות.
ה-RelayState זהה להודעת HTTP POST הקודמת שבה היישום אומר ל-IdP איזה EntityID מבקש את ההצהרה.
|
| 6 |
הצהרת SAML מ-IdP ל-Webex.
|
| 7 |
שירות הזהויות מקבל קוד הרשאה שמוחלף באסימון גישה ורענון של OAuth. אסימון זה משמש לגישה למשאבים מטעם המשתמש.
לאחר ששירות הזהויות מאמת את התשובה מה-IdP, הוא מנפיק אסימון OAuth המאפשר ליישום Webex לגשת לשירותי Webex השונים.
|
