Єдиний вхід і центр керування

Єдиний вхід (SSO) – це процес автентифікації сеансу або користувача, який дає змогу надати облікові дані для доступу до однієї або кількох програм. Процес автентифікує користувачів для всіх додатків, на які їм надаються права. Він усуває подальші підказки, коли користувачі перемикають програми під час певного сеансу.

Протокол федерації «Мова розмітки тверджень безпеки» (SAML 2.0) використовується для забезпечення автентифікації SSO між хмарою Webex і вашим постачальником посвідчень (IdP).

Профілі

Webex App підтримує лише профіль SSO веб-браузера. У профілі SSO веб-браузера Webex App підтримує такі прив'язки:

  • ІП ініціював прив'язку POST -> POST

  • СП ініціював ПЕРЕНАПРАВЛЕННЯ -> прив'язка ПОСТ

Формат nameID

Протокол SAML 2.0 підтримує кілька форматів NameID для спілкування про конкретного користувача. Webex App підтримує такі формати NameID.

  • urn: oasis: names: tc: SAML: 2. 0: назва- формат: transient

  • urn: oasis: names: tc: SAML: 1. 1: назва- формат: не заданий

  • urn:oasis:names:tc:SAML:1. 1:ім’я- формат:електронна адреса

У метаданих, які ви завантажуєте зі свого IdP, перший запис налаштовується для використання в Webex.

SingleLogout

Webex App підтримує єдиний профіль виходу. У Webex Appкористувач може вийти з програми, яка використовує протокол єдиного виходу SAML для завершення сеансу та підтвердження виходу за допомогою idP. Переконайтеся, що ваш IdP налаштовано для SingleLogout.

Інтегруйте Control Hub із Shibboleth.

Посібники з конфігурації показують конкретний приклад інтеграції 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, але виходить за рамки нашої документації.

Налаштуйте цю інтеграцію для користувачів у вашій організації Webex (включаючи Webex App, Webex Meetingsта інші служби, що адмініструються в Control Hub). Якщо ваш вебекс-сайт інтегровано в Control Hub, веб-сайт успадковує керування користувачами. Якщо ви не можете отримати доступ до вебекс-зустрічей таким чином, а керування ними не здійснюється в Центрікерування, необхідно виконати окрему інтеграцію, щоб увімкнути єдиний вхід для вебекс-зустрічей. (Див. Налаштуйте єдиний вхід для Webex для отримання додаткової інформації про інтеграцію єдиного входу в адміністрування сайту.)

Кроки інтеграції відносяться до Shibboleth 2.4.5 у CentOS 7 з Tomcat 7 як веб-сервер.

Перш ніж почати

У разі використання SSO й Control Hub IdP мають відповідати вимогам специфікації SAML 2.0. Крім того, потрібно виконати налаштування IdP з урахуванням наведеного нижче.

Завантажте метадані Webex у свою локальну систему

1

У поданні клієнта перейдіть https://admin.webex.comдо розділу Керування > Параметриорганізації, а потім прокрутіть до пункту Автентифікація, а потім перемкніть параметр Єдиний вхід , щоб запустити майстер настроювання.

2

Виберіть тип сертифіката для своєї організації:

  • Самопідписаний Cisco — ми рекомендуємо цей вибір. Дозвольте нам підписати сертифікат, тому вам потрібно продовжувати його лише раз на п'ять років.
  • Підписано загальнодоступним центром сертифікації. Більш безпечний, але вам доведеться часто оновлювати метадані (якщо ваш постачальник IdP не підтримує прив’язки довіри).

Прив'язки довіри – це відкриті ключі, які діють як орган перевірки сертифіката цифрового підпису. Для отримання додаткової інформації зверніться до документації 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=Адміністратор,cn=Користувачі,dc=cisco,dc=net" bindCredential="Пароль"; };

Налаштування компонентів постачальника послуг 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" provider="https://shib9a.cisco.net/idp/shibboleth" за замовчуваннямПідписуванняCredentialRef="IdPCredential"> <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" includeAttributeStatement="true" assertionLifetime="PT5M" assertionProxyCount="0" signResponses="never" signAssertions="always" encryptAssertions="conditional" encryptNameIds="never" includeConditionsNotBefore="true"/>

Для ідентифікатора потрібно використовувати значення ідентифікатора запису з файлу метаданих Webex. Замініть ідентифікатор прикладу на ідентифікатор запису вашої організації.

3

Всередині метаданих:Тег постачальника метаданих, додайте розташування файлу:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:MetadataProvider id="IdPMD" 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="FilesystemMetadata  <!-- Конфігурація 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) з uid (UserID у Webex).

4

Визначте, який атрибут надати кожній угоді SP у файлі attribute-filter.xml .

Надайте атрибут uid Webex, який зіставляється з адресою електронної пошти користувача.

Відпустіть uid атрибута в угоді 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> <afp:AttributeRule xsi:type="basic:ANY" /> </afp:AttributeFilterPolicy>

Правило, створене у attribute-resolver.xml , має мати політику щодо випуску атрибута mail-attr для EntityID, який відповідає Webex.

5

Завантажте файл метаданих із сервера Shibboleth у форматі /opt/shibboleth-idp/метадані. Ім’я файлу — idp-metadata.xml.

Імпорт метаданих IdP та ввімкнення єдиного входу після тесту

Після експорту метаданих Webex , настроювання ідентифікатора та завантаження метаданих IdP до локальної системи можна імпортувати їх до своєї організації Webex із Центрукерування.

Перш ніж почати

Не тестуйте інтеграцію SSO з інтерфейсу постачальника посвідчень (IdP). Ми підтримуємо потоки, ініційовані лише постачальником послуг (ініційовані SP), тому для цієї інтеграції необхідно використовувати тест SSO Control Hub .

1

Виберіть один із варіантів:

  • Поверніться на сторінку вибору сертифіката в браузері, а потім клацніть Далі.
  • Якщо Control Hub більше не відкривається в вкладці браузера, з подання клієнта в https://admin.webex.com перейдіть до Керування > Налаштування організації, прокрутіть до Автентифікація, а потім виберіть Дії > Імпорт метаданих.
2

На сторінці "Імпорт метаданих idP" перетягніть файл метаданих IdP на сторінку або скористайтеся параметром файлового браузера, щоб знайти та завантажити файл метаданих. Клацніть Далі.

Ви повинні використовувати опцію «Більш безпечний », якщо можете. Це можливо лише в тому випадку, якщо ваш IdP використовував загальнодоступний ЦС для підпису своїх метаданих.

У всіх інших випадках необхідно використовувати опцію «Менш безпечний ». Це стосується випадків, коли метадані не підписані, не підписані самостійно або не підписані приватним ЦС.

Okta не підписує метадані, тому ви повинні вибрати Менш безпечний для інтеграції Okta SSO.

3

Виберіть Тестове налаштування SSO й, коли відкриється нова вкладка браузера, автентифікуйтеся за допомогою IdP, увійшовши.

Якщо з'являється повідомлення про помилку автентифікації, можливо, виникла проблема з обліковими даними. Перевірте ім'я користувача та пароль і повторіть спробу.

Помилка Webex App зазвичай означає проблему з налаштуванням єдиного входу. У цьому випадку виконайте кроки ще раз, особливо кроки, за допомогою яких ви копіюєте та вставляєте метадані Центру керування в налаштування IdP.

Для безпосереднього спостереження за процесом SSO також можна клацнути Скопіювати URL у буфер обміну на цьому екрані й вставити в приватне вікно браузера. Після цього можна виконати вхід за допомогою SSO. Цей крок зупиняє помилкові спрацьовування через маркер доступу, який може бути в наявному сеансі від входу.

4

Поверніться на вкладку браузера Control Hub .

  • Якщо тест пройшов успішно, виберіть Успішний тест. Увімкніть єдиний вхід і натисніть Кнопку Далі.
  • Якщо тест виявився невдалим, виберіть Невдалий тест. Вимкніть єдиний вхід і натисніть кнопку Далі.

Конфігурація єдиного входу не набирає чинності у вашій організації, якщо не вибрати першу перемикач і не активувати єдиний вхід.

Що далі

Використовуйте процедури, описані в розділі Синхронізація користувачів Okta з Cisco Webex Control Hub, якщо ви хочете виконати підготовку користувачів з Okta в хмару Webex.

Використовуйте процедури, описані в розділі Синхронізація користувачів Azure Active Directory з Cisco Webex Control Hub, якщо потрібно виконати підготовку користувачів з Azure AD у хмарі Webex.

Щоб вимкнути електронні листи, які надсилаються новим користувачам програми Webex у вашій організації, можна виконати процедуру в розділі Блокувати автоматизовані електронні листи . Документ також містить практичні поради щодо надсилання повідомлень користувачам у вашій організації.