Центр єдиного входу та керування

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

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

Профілі

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

  • SP ініціював ПОСТ -> зв 'язування ПОСТІВ

  • SP ініціював ПЕРЕНАПРАВЛЕННЯ -> прив 'язка до ПУБЛІКАЦІЇ

Формат NameID

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

  • urn: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

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

Єдиний вихід

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

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


 

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

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

Кроки інтеграції стосуються версії 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 не підтримує якорі довіри).

 

Якоря довіри - це відкриті ключі, які діють як повноваження для перевірки сертифіката цифрового підпису. Щоб отримати додаткову інформацію, зверніться до документації свого призначеного лікаря.

3.

Завантажте файл метаданих.

Назва файлу метаданих Webex - idb-meta-<org-ID>-SP.xml.

Налаштуйте авторизацію у файлах Shibboleth

Після встановлення Shibboleth ви отримаєте файли конфігурації з прикладами.

1.

Перейдіть до каталогу /opt/shibboleth-idp/conf щоб отримати доступ до файлів прикладів.

2.

Вирішіть, який метод авторизації використовувати, наприклад, прив’язку LDAP до Active Directory.

3.

Змініть обробник.xml файл у такий спосіб:

Скасуйте коментар

    <!--  Username/password login handler -->
    <ph:LoginHandler xsi:type="ph:UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config">  
  <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</ph:AuthenticationMethod>
    </ph:LoginHandler>

Коментар

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
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/metadata .

2.

Змініть довірена сторона.xml файл; після тегу DefaultRelyingParty додайте відомості твердження SAML для Webex.

 <rp:RelyingParty id="https://idbroker.webex.com/ea7c1420-711d-4916-95f8-
22de53230d1e"
              provider="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"/>
        </rp:RelyingParty>

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

3.

Усередині тегу метаданих:провайдер метаданих додайте розташування файлу:

 <metadata:MetadataProvider id="ShibbolethMetadata" xsi:type="metadata:Chaini
ngMetadataProvider">
        <metadata:MetadataProvider id="IdPMD" xsi:type="metadata:FilesystemMetad
ataProvider" metadataFile="/opt/shibboleth-idp/metadata/idp-metadata.xml" maxRefreshDelay="P1D" />
    <!--     Cisco UCXN Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="ucxn9a" metadataFile="/opt/shibboleth-idp/metad
ata/ucxn9a-single-agreement.xml" />
    <!--     Cisco CUCM Configuration               -->
   <metadata:MetadataProvider xsi:type="FilesystemMetadataProvider" xmlns="urn:m
ace:shibboleth:2.0:metadata" id="cucm9a" metadataFile="/opt/shibboleth-idp/metad
ata/cucm9a.cisco.net-single-agreement.xml" />
    <!--     Cisco CI Configuration               
   <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" />
    </metadata:MetadataProvider>

Метадані SP надходять із файлу у файловій системі Shibboleth у розташуванні, куди ви передали метадані для вашої організації Webex.

Налаштуйте атрибути твердження

1.

У розділі з’єднувача даних укажіть, де отримати атрибути користувачів.

Active Directory з ідентифікатором MyLDAP.

<resolver:DataConnector id="MyLDAP" xsi:type="dc:LDAPDirectory"
      ldapURL="ldap://ad0a.cisco.net:389"
      baseDN="cn=Users,dc=cisco,dc=net"
      principal="Administrator@cisco.net"
      principalCredential="ThePassword">
        <dc:FilterTemplate>
            <![CDATA[
                (sAMAccountName=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>
2.

У розділі Визначення атрибута збережіть те, що вже є в конфігурації для ідентифікатора переходу.

3.

Додайте додатковий атрибут, який очікує SP, і визначте, з чим він зіставляється у джерелі атрибута.

Зіставте атрибут mail (атрибут адреси електронної пошти в Active Directory) з uid (ідентифікатор користувача у Webex).

<resolver:AttributeDefinition id="mail-attr" xsi:type="ad:Simple" 
sourceAttributeID="mail">
        <resolver:Dependency ref="MyLDAP" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String" name="uid" />
     </resolver:AttributeDefinition>
4.

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

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

Відпустіть атрибут uid для угоди SP із Webex.

<!--  Release the attributes to cisco CI Cloud  -->
    <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 attributeID="mail-attr">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>

Правило, яке ви створили в атрибут-роздільник.xml має мати політику для вивільнення атрибута mail-attr для ідентифікатора запису, який збігається з Webex.

5.

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

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

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

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

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

1.

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

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

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

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

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


 

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

3.

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


 

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

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


 

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

4.

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

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

 

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

Що далі

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

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

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