הפתרונות הבאים לניהול גישה לאינטרנט ולביצוע איחוד נבדקו עבור ארגוני Webex. המסמכים המקושרים למטה מדריכים אותך כיצד לשלב את ספק הזהויות (IdP) הספציפי הזה עם ארגון Webex שלך.


 

מדריכים אלה סוקרים שילוב של SSO בשירותי Webex המנוהלים ב-Control Hub ‏(https://admin.webex.com). אם אתה רוצה להגדיר שילוב SSO באתר Webex Meetings (מנוהל בניהול האתר), קרא את הגדרת כניסה יחידה לאתר Cisco Webex.

אם אינך רואה את ה-IDP שלך רשום למטה, בצע את השלבים הכלליים בלשונית הגדרת SSO במאמר זה.

כניסה יחידה (SSO) מאפשרת למשתמשים להיכנס ל-Webex בצורה מאובטחת באמצעות אימות מול ספק הזהויות (IdP) המשותף של הארגון שלך. יישום Webex משתמש בשירות Webex כדי לתקשר עם שירות הזהויות של פלטפורמת Webex. שירות הזהויות מבצע אימות עם ספק הזהויות (IdP) שלך.

מגדירים את התצורה ב-Control Hub. סעיף זה מספק הנחיות לשלבים כלליים לשילוב IdP של צד שלישי.


 
כאשר אתה מגדיר SSO עם ה-IdP שלך, אתה יכול למפות כל תכונה ל-uid. לדוגמה, מפה את userPrincipalName, כינוי דוא"ל, כתובת דוא"ל חלופית או כל תכונה אחרת שמתאימה ל-uid. ה-IdP צריך להתאים לאחת מכתובות הדוא"ל של המשתמש ב-uid בעת הכניסה לחשבון. Webex תומך במיפוי של עד 5 כתובות דוא"ל ל-uid.

עבור SSO ו-Control Hub, ספקי הזהויות חייבים להתאים למפרט SAML 2.0. בנוסף, יש להגדיר ספקי IdP באופן הבא:

  • הגדר את התכונה תבנית NameID באופן הבא urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • הגדר בעלות על ה-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

מתצוגת הלקוח ב-Control Hub ( https://admin.webex.com), עבור אל ניהול > הגדרות ארגון, גלול אל אימות והפעל את ההגדרה כניסה יחידה כדי להפעיל את אשף התצורה.

2

בחר את סוג התעודה:

  • בחתימה עצמית של Cisco - אנו ממליצים שתבחר באפשרות זו כדי לאפשר לנו להפוך לספק השירות (SP). כמו כן, תצטרך לחדש את התעודה רק אחת לחמש שנים.
  • נחתם על ידי רשות אישורים (Certificate Authority) ציבורית - אפשרות זו מאובטחת ומומלצת אם אתה מקבל תעודות מרשות אישורים (CA) ציבורית כגון Hydrant או Godaddy. עם זאת, עליך לחדש את התעודה אחת לשנה.
3

לחץ על הורדת מטה-נתונים ולחץ על הבא.

4

שירות הזהויות של פלטפורמת Webex מאמת את קובץ המטה-נתונים מה-IdP.

ישנן שתי דרכים אפשריות לאמת את קובץ המטה-נתונים מה-IdP של הלקוח:

  • ה-IdP של הלקוח מספק חתימה בקובץ המטה-נתונים החתום על ידי CA ציבורית המהווה בסיס.

  • ה-IdP של הלקוח מספק CA פרטית בחתימה עצמית או שאינו מספק חתימה עבור קובץ המטה-נתונים שלו. אפשרות זו פחות מאובטחת.

5

בדוק את חיבור ה-SSO לפני שתפעיל אותו. שלב זה פועל כמו הרצה יבשה ואינו משפיע על הגדרות הארגון שלך עד שתפעיל את האפשרות SSO בשלב הבא.


 

כדי לנסות בעצמך את חוויית הכניסה עם SSO, אתה יכול גם ללחוץ על העתקת URL ללוח ממסך זה ולהדביק אותו בחלון דפדפן פרטי. משם תוכל לפעול על פי השלבים לכניסה באמצעות SSO. הליך זה עוזר להסיר מידע השמור בדפדפן האינטרנט שלך שעלול לספק תוצאה חיובית שגויה בעת בדיקת התצורה של ה-SSO.

6

אם הבדיקה מצליחה, הפעל את ה-SSO ושמור את השינויים.

עליך לשמור את השינויים כדי שהשימוש ב-SSO ייכנס לתוקף בארגון שלך.

בין אם קיבלת הודעה על תעודה שפג תוקפה ובין אם אתה רוצה לבדוק את תצורת ה-SSO הקיימת שלך, אתה יכול להשתמש בתכונות הניהול של כניסה יחידה (SSO) ב-Control Hub לניהול תעודות ולפעילויות תחזוקה כלליות של SSO.

אם אתה נתקל בבעיות בשילוב ה-SSO שלך, השתמש ברשימת הדרישות ובנוהל המפורטים בסעיף זה כדי לפתור בעיות בהעברת SAML בין ה-IdP שלך ל-Webex.

  • השתמש בתוסף המעקב של SAML עבור Firefox או Chrome.

  • כדי לפתור בעיות, השתמש בדפדפן האינטרנט שבו התקנת את כלי המעקב של 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 השונים.