У цій статті
dropdown icon
Єдиний вхід і центр управління
    Профілі
    Формат іменіID
    Одиночний вихід
Інтегруйте центр управління з Shibboleth
Завантажте метадані Webex у свою локальну систему
Налаштування авторизації у файлах Shibboleth
Налаштування компонентів постачальника послуг Shibboleth для твердження SAML
Налаштування атрибутів твердження
Імпортуйте метадані IdP та увімкніть єдиний вхід після тестування
Налаштування єдиного входу в Контрольному центрі за допомогою Shibboleth
list-menuУ цій статті
list-menuНадіслати відгук?

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

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

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

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

Профілі

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

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

  • SP ініціював ПЕРЕАДРЕСАЦІЮ -> POST прив'язка

Формат іменіID

Протокол SAML 2.0 підтримує кілька форматів NameID для спілкування про конкретного користувача. Додаток Webex підтримує наступні формати 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 налаштований для SingleLogout.

Інтегруйте центр управління з 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 інтегрований у Центр керування, сайт Webex успадковує управління користувачами. Якщо ви не можете отримати доступ Webex Meetings таким чином і ним не керується в Control Hub, вам потрібно зробити окрему інтеграцію, щоб увімкнути SSO дляWebex Meetings.

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

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

Для SSO та Центру керування внутрішньо переміщеними особами повинні відповідати специфікації SAML 2.0. Крім того, ВПО повинні бути налаштовані таким чином:

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

1

Увійдіть до центру керування.

2

Перейдіть до меню Керування > Безпека > Ау тентифікація.

3

Перейдіть на вкладку Постачальник іденти фікації та натисніть Активувати SSO.

4

Виберіть IdP.

5

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

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

Довірчі анкери — це відкриті ключі, які виконують функцію авто ритету для перевірки сертифіката цифрового підпису. Для отримання додаткової інформації зверніться до документації IdP.

6

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

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

Налаштування авторизації у файлах Shibboleth

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

1

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

2

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

3

Відредагуйте файл handler.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

Відредагуйте файл 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"
              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>

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

3

Всередині тегу metadata:metadataProvider додайте розташування файлу:

 <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

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

3

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

Зіставте атрибут пошти (атрибут адреси електронної пош Active Directory ти в) на uid (UserId у 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 у файлі attribute-filter.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>

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

5

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

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

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

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

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

1

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

  • Поверніться на сторінку вибору сертифіката Control Hub у вашому браузері, а потім натисніть кнопку Далі.
  • Повторно відкрийте Центр керування, якщо він більше не відкритий на вкладці браузера. У поданні клієнта в Центрі керування перейдіть до розділу Керування > Без пека > Ау тентифікація, виберіть IdP, а потім виберіть Дії > Імпор тувати метадані.
2

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

Ви повинні використовувати параме тр Більш безпе чний, якщо можете. Це можливо лише в тому випадку, якщо ваш Ідентифікатор використовував загальнодоступну CA для підписання метаданих.

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

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

3

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

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

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

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

4

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

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

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

Що робити далі

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

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

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

Чи була ця стаття корисною?
Чи була ця стаття корисною?