Система единого входа и Control Hub

Система единого входа (SSO) – это процесс аутентификации сеанса или пользователя, благодаря которому пользователь может предоставлять учетные данные для доступа к одному или нескольким приложениям. В ходе процесса выполняется аутентификация пользователей для всех приложений, на которые им предоставлены права. В дальнейшем, когда пользователь будет переключаться между приложениями во время определенного сеанса, подсказки не будут отображаться.

Протокол федерации языка разметки подтверждения безопасности (SAML 2.0) используется для обеспечения аутентификации SSO между облаком Webex и поставщиком удостоверений (idP).

Профили

Приложение Webex поддерживает только профиль SSO веб-браузера. В профиле SSO веб-браузера приложение Webex поддерживает следующие привязки.

  • Поставщик услуг инициировал привязку POST -> POST.

  • Поставщик услуг инициировал привязку REDIRECT -> POST.

Формат NameID

Протокол 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. Проверьте, заданы ли настройки поставщика удостоверений для единого выхода из системы.

Интеграция Control Hub и Shibboleth


 

В руководствах по настройке не предоставлены исчерпывающие сведения о настройке всевозможных конфигураций, а показан только отдельный пример интеграции системы единого входа. Например, описаны шаги для интегрирования 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, Webex Meetings и другие службы, администрирование которых осуществляется в Control Hub). Если веб-сайт Webex интегрирован в Control Hub, веб-сайт Webex унаследует способ управления пользователями. Если таким способом не удается получить доступ к Webex Meetings и управление осуществляется не в Control Hub, то для того, чтобы включить SSO для Webex Meetings, необходимо выполнить отдельную интеграцию. (Дополнительная информация об интеграции системы единого входа со службой администрирования веб-сайта в статье: Настройка системы единого входа для Webex.)

На этапах интеграции предполагается наличие Shibboleth 2.4.5 в CentOS 7 с Tomcat 7 в качестве веб-сервера.

Перед началом работы

При использовании SSO и Control Hub поставщики удостоверений должны соответствовать требованиям спецификации SAML 2.0. Кроме того, настройка поставщиков удостоверений должна быть выполнена с учетом приведенного ниже.

Скачивание метаданных Webex в локальную систему

1.

В окне просмотра информации о клиенте в https://admin.webex.com перейдите к параметру Управление > Настройки организации, затем прокрутите страницу до параметра Аутентификация и перейдите к настройкам Системы единого входа, чтобы запустить мастер настройки.

2.

Выберите тип сертификата для своей организации.

  • Самоподписанный сертификат Cisco – рекомендуем выбрать этот тип сертификата. Мы самостоятельно подпишем этот сертификат, и вам нужно будет продлевать его только один раз в пять лет.
  • Сертификат, подписанный центром сертификации, – более безопасный вариант, но вам придется чаще обновлять метаданные (за исключением случаев, когда ваш поставщик удостоверений поддерживает точки доверия).

 

Точки доверия – это открытые ключи, которые служат для проверки сертификата цифровой подписи. Дополнительные сведения см. в документации поставщика удостоверений.

3.

Скачайте файл метаданных.

Имя файла метаданных Webex: idb-meta--SP.xml.<org-ID>

Настройка авторизации в файлах 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>

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

3.

В тег metadata:MetadataProvide добавьте расположение файла:

 <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 дополнительный атрибут и определите, с чем он сопоставляется, с помощью источника атрибутов.

Сопоставьте адрес электронной почты атрибута (атрибут адреса электронной почты в 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 в файле 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.

Импорт метаданных поставщика удостоверений и активация системы единого входа после тестирования

После экспорта метаданных Webex, настройки idP и скачивания метаданных idP на локальную систему можно импортировать их в свою организацию Webex из Control Hub.

Перед началом работы

Не тестируйте интеграцию SSO в интерфейсе поставщика удостоверений (IdP). Поддерживаются только процессы, инициированные поставщиками услуг, поэтому для этой интеграции необходимо использовать тестирование SSO в Control Hub.

1.

Выберите один из вариантов.

  • Вернитесь в Control Hub на страницу выбора сертификатов в браузере и щелкните Далее.
  • Если Control Hub не открыт во вкладке браузера, в окне просмотра информации о клиенте в перейдите в раздел Управление > Настройки организации, прокрутите страницу до раздела Аутентификация и выберите Действия > Импорт метаданных.https://admin.webex.com
2.

На странице импорта метаданных IdP перетащите файл метаданных IdP на страницу либо воспользуйтесь параметром "Браузер файлов", чтобы найти и загрузить файл метаданных. Щелкните Далее.

По возможности используйте параметр Более безопасный. Это возможно только в том случае, если ваш поставщик удостоверений использовал общедоступный ЦС для подписи своих метаданных.

Во всех остальных случаях необходимо использовать параметр Менее безопасный. Он также используется, если метаданные не подписаны, являются самоподписанными или подписаны частным ЦС.


 

В Okta метаданные не подписываются, поэтому для интеграции SSO Okta необходимо выбрать параметр Менее безопасный.

3.

Выберите Настройка тестирования SSO и в открывшейся новой вкладке браузера выполните аутентификацию с помощью поставщика удостоверений посредством входа в систему.


 

Если вы получаете сообщение об ошибке аутентификации, возможно, возникла проблема с учетными данными. Проверьте имя пользователя и пароль и повторите попытку.

Ошибка в приложении Webex обычно означает, что настройки 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 Active Directory в облаке Webex.

Для деактивации отправки сообщений по электронной почте новым пользователям приложения Webex в вашей организации выполните процедуру Запрет автоматической рассылки по электронной почте. В документе также содержатся рекомендации по отправке коммуникаций пользователям вашей организации.