В тази статия
dropdown icon
Център за единично влизане и управление
    Профили
    НаименованиеID формат
    Единично записване
Интегрирайте контролния център с Shibboleth
Изтеглете метаданните на Webex във вашата локална система
Конфигурирайте оторизация във файловете на Shibboleth
Конфигурирайте компонентите на доставчика на услуги на Shibboleth за твърдение на SAML
Конфигурирайте атрибутите за твърдение
Импортирайте метаданните на IDP и активирайте еднократно влизане след тест
Конфигурирайте еднократно влизане в Control Hub с Shibboleth
list-menuВ тази статия
list-menuОбратна връзка?

Можете да конфигурирате интеграция за еднократно влизане (SSO) между Control Hub и внедряване, което използва 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 App потребителят може да излезе от приложението, което използва протокола за единично излизане 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 е интегриран в Control Hub, сайтът Webex наследява управлението на потребителите. Ако не можете да получите достъп Webex Meetings по този начин и той не се управлява в Control Hub, трябва да направите отделна интеграция, за да активирате SSO заWebex Meetings.

Стъпките за интеграция се отнасят до Shibboleth 2.4.5 в CentOS 7 с Tomcat 7 като уеб сървър.

Преди да започнете

За SSO и контролния център IDP трябва да отговарят на спецификацията на 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

В секцията Data Connector посочете къде да извлечете атрибути за вашите потребители.

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 очаква, и дефинирайте какво се картографира в източника на атрибути.

Картирайте атрибута mail (атрибут на имейл адрес в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 от Control Hub.

Преди да започнете

Не тествайте интеграцията на SSO от интерфейса на доставчика на идентичност (IDP). Ние поддържаме само инициирани от доставчика на услуги (инициирани от SP-инициирани) потоци, така че трябва да използвате теста Control Hub SSO за тази интеграция.

1

Изберете един:

  • Върнете се на страницата Control Hub — избор на сертификат във вашия браузър и след това щракнете върху Напред.
  • Отворете отново Control Hub, ако вече не е отворен в раздела на браузъра ви. От изгледа на клиента в Control Hub отидете на Управ ление > Защита > У дост оверяване, изберете IDP и след това изберете Дей ствия > Импортиране на метаданни.
2

На страницата Импортиране на метаданни на IDP плъзнете и пуснете файл а с метаданни на IdP на страницата или използвайте опцията на браузъра на файлове, за да намерите и качите файла с метаданни . Щракнете върху На пред.

Трябва да използвате оп цията По- сигурна, ако можете. Това е възможно само ако вашият IdP използва публичен CA, за да подпише своите метаданни.

Във всички останали случаи трябва да използвате опцията По-малко сигур на. Това включва, ако метаданните не са подписани, самоподписани или подписани от частен сертификат.

Okta не подписва метаданните, така че трябва да изберете По-малко сигурно за интегра ция на Okta SSO.

3

Изберете Т естване на настройката на SSO и когато се отвори нов раздел на браузъра, удостоверявайте се с IDP, като влезете.

Ако получите грешка при удостоверяване, може да има проблем с идентификационните данни. Проверете потребителското име и паролата и опитайте отново.

Грешка в приложението Webex обикновено означава проблем с настройката на SSO. В този случай преминете отново през стъпките, особено стъпките, при които копирате и поставяте метаданните на Control Hub в настройката на 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 App във вашата организация. Документът съдържа и най-добрите практики за изпра щане на съобщения до потребители във вашата организация.

Беше ли полезна тази статия?
Беше ли полезна тази статия?