Інтеграція єдиного входу в Control Hub
Наведені далі рішення федерації та керування вебдоступом було протестовано для організацій Webex. У документах, посилання на які наведено нижче, описано способи інтеграції конкретних постачальників посвідчень (IdP) з вашою організацією Webex.
У цих посібниках розглянуто питання інтеграції SSO для служб Webex, якими керують у Control Hub (https://admin.webex.com). Якщо вам потрібна інтеграція SSO для вебсайту Webex Meetings (яким керують у службі адміністрування вебсайту), прочитайте статтю Налаштування єдиного входу для вебсайту Cisco Webex.
Щоб налаштувати SSO для кількох постачальників посвідчень у своїй організації, див. розділ SSO з кількома IdP у Webex.
Якщо ваш IdP не зазначено в списку нижче, виконайте загальні інструкції, описані на вкладці Налаштування SSO в цій статті.
Єдиний вхід (SSO) дає змогу користувачам безпечно входити до Webex за допомогою автентифікації загального постачальника посвідчень (IdP) вашої організації. Для зв’язку зі службою ідентифікації платформи Webex програма Webex використовує службу Webex. Служба ідентифікації виконує автентифікацію за допомогою постачальника посвідчень (IdP).
Налаштування конфігурації починається в Control Hub. У цьому розділі описано загальні дії для інтеграції стороннього IdP.
Під час налаштування SSO з IdP з uid можна зіставити будь-який атрибут. Наприклад, з uid можна зіставити userPrincipalName, псевдонім електронної пошти, альтернативну адресу електронної пошти або будь-який інший відповідний атрибут. Під час входу IdP має зіставити одну з адрес електронної пошти користувача з uid. Webex підтримує зіставлення uid максимум із 5 адресами електронної пошти.
Ми рекомендуємо включити єдиний вихід (SLO) у конфігурацію метаданих під час налаштування федерації SAML Webex. Цей крок має вирішальне значення, щоб переконатися, що токени користувача є неприпустимими як для постачальника посвідчень (IdP), так і для постачальника послуг (SP). Якщо цю конфігурацію не виконує адміністратор, тоді Webex попереджає користувачів закрити свої браузери, щоб скасувати будь-які сеанси, які залишилися відкритими.
У разі використання SSO й Control Hub IdP мають відповідати вимогам специфікації SAML 2.0. Крім того, потрібно виконати налаштування IdP з урахуванням наведеного нижче.
-
Установіть атрибут формату ідентифікатора імені для urn:oasis:names:tc:SAML:2.0:nameid-format:тимчасовий
-
Налаштуйте запит IdP відповідно до типу SSO, що розгортається.
-
SSO (для організації). У разі налаштування SSO від імені організації налаштуйте запит IdP так, щоб він містив ім’я атрибута uid зі значенням, зіставленим з атрибутом, вибраним у з’єднувачі каталогів, або атрибутом користувача, що відповідає вибраному атрибуту в службі ідентифікації Webex. (Наприклад, таким атрибутом може бути E-mail-Addresses або User-Principal-Name.)
-
Партнерський SSO (лише для постачальників послуг). Адміністратору постачальника послуг у разі налаштування партнерського SSO для використання клієнтськими організаціями, якими керує цей постачальник послуг, потрібно налаштувати запит IdP так, щоб він містив атрибут mail (а не uid). Значення має бути зіставлено з атрибутом, вибраним у з’єднувачі каталогів, або з атрибутом користувача, який відповідає атрибуту, вибраному в службі ідентифікації Webex.
Додаткову інформацію про зіставлення користувацьких атрибутів для SSO або партнерського SSO див. на вебсайті https://www.cisco.com/go/hybrid-services-directory.
-
-
Тільки для партнерського SSO. Постачальник посвідчень повинен підтримувати використання кількох URL служби підтвердження користувачів (ACS). Приклади налаштування кількох URL ACS для постачальника посвідчень див. в наведених далі документах.
-
Скористайтеся підтримуваним браузером. Рекомендовано використовувати останню версію Mozilla Firefox або Google Chrome.
-
Вимкніть блокування спливаючих вікон у браузері.
У посібниках із налаштування не описується налаштування всіх можливих конфігурацій, а наведено лише конкретний приклад інтеграції SSO. Наприклад, задокументовані кроки інтеграції для іменного формату urn:oasis:names:tc:SAML:2.0:nameid-format:transient
. Інші формати, такі як урна:oasis:names:tc:SAML:1.1:nameid-format:unspecified або 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) перейдіть до , прокрутіть до Автентифікація та клацніть Активувати налаштування SSO , щоб запустити майстер конфігурації. |
2 |
Виберіть Webex як свого IdP і клацніть Далі. |
3 |
Перевірте, як я прочитав(-ла) і зрозумів(-ла), як працює IdP Webex , і клацніть Далі. |
4 |
Налаштуйте правило маршрутизації. Після додавання правила маршрутизації ваш IdP буде додано й відображено на вкладці Постачальник посвідчень .
Додаткову інформацію див. в SSO з кількома IdP у Webex.
|
Для керування сертифікатами й виконання загальних дій з обслуговування SSO використовуйте функції керування єдиним входом (SSO) у Control Hub. Це може знадобитися в разі отримання повідомлення про закінчення терміну дії сертифіката або за потреби перевірити наявну конфігурацію SSO.
У разі виникнення проблем з інтеграцією SSO скористайтесь описаними в цьому розділі вимогами й процедурою, щоб виправити неполадки, пов’язані з виконанням процесу SAML між вашим IdP та службою Webex.
-
Використовуйте додатковий модуль трасування SAML для Firefox, Chrome або Edge.
-
Для виправлення неполадок скористайтеся веббраузером, у якому встановлено інструмент налагодження трасування 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, як-от ідентифікатор клієнта, ідентифікатор URI для переспрямування та область. |
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) Визначення формату NameID IdP й налаштування назви угоди виконується під час створення угоди SAML. |
4 |
Автентифікація програми відбувається між вебресурсами операційної системи й IdP.
Залежно від IdP й налаштованих ним механізмів автентифікації постачальник посвідчень запускає різні процеси. |
5 |
Програма надішле повідомлення HTTP Post назад до служби ідентифікації і додасть атрибути, надані IdP й узгоджені в початковій угоді.
У разі успішної автентифікації програма надішле до служби ідентифікації інформацію в повідомленні SAML POST. Параметр RelayState збігається з попереднім повідомленням HTTP POST, у якому програма повідомляє IdP про те, який ідентифікатор EntityID запитує підтвердження. |
6 |
Підтвердження SAML, надіслане IdP до Webex. |
7 |
Код авторизації, отриманий службою ідентифікації, замінюється маркером доступу й оновлення OAuth. Цей маркер використовується для доступу до ресурсів від імені користувача.
Після того як служба ідентифікації перевірить відповідь від IdP, буде випущено маркер OAuth, завдяки якому програма Webex матиме доступ до різних служб Webex. |