Единичен вход и контролен център

Единичен вход (SSO) е процес на удостоверяване на сесия или потребител, който позволява на потребителя да предостави идентификационни данни за достъп до едно или повече приложения. Процесът удостоверява потребителите за всички приложения, за които са им дадени права. Той елиминира допълнителни подкани, когато потребителите превключват приложения по време на определена сесия.

Протоколът за маркиране на езика за потвърждаване на сигурността (SAML 2.0) се използва за осигуряване на SSO удостоверяване между облака на Webex и вашия доставчик на идентичност (IdP).

Профили

Приложението Webex поддържа само SSO профила на уеб браузъра. В SSO профила на уеб браузъра, приложението Webex поддържа следните обвързвания:

  • SP инициира POST -> POST свързване

  • SP инициира 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.

SingleLogout

Приложението Webex поддържа единичен профил за излизане. В приложението Webex потребителят може да излизам от приложението, което използва SAML протокол за еднократно излизане, за да прекрати сесията и да потвърди това излизам с вашия IdP. Уверете се, че вашият IdP е конфигуриран за SingleLogout.

Интегрирайте 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 поддържа доверителни котви).

 

Доверените котви са публични ключове, които действат като орган за проверка на сертификата на цифров подпис. За повече информация вижте документацията на вашия IdP.

3

Изтеглете файла с метаданни.

Името на файла с метаданни на Webex е idb-meta-<org-ID> -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 споразумение в атрибут-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>

Правилото, което сте създали в атрибут-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), така че трябва да използвате SSO теста на Control Hub за тази интеграция.

1

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

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

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

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

Във всички останали случаи трябва да използвате По-малко сигурен опция. Това включва, ако метаданните не са подписани, самоподписани или подписани от частен 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 .

Използвайте процедурите в Синхронизирайте потребителите на Azure Active Directory в Cisco Webex Control Hub ако искате да направите обезпечаване на потребители извън Azure AD в облака на Webex .

Можете да следвате процедурата в Потискайте автоматизирани имейли за да деактивирате имейли, които се изпращат до нови потребители на Webex App във вашата организация. Документът също така съдържа най-добри практики за изпращане на съобщения до потребители във вашата организация.