W tym artykule
dropdown icon
Pojedyncze logowanie i koncentrator sterowania
    Profile
    Format nazwaID
    SingleLogout
Zintegruj Control Hub z Shibboleth
Pobierz metadane Webex do swojego systemu lokalnego
Skonfiguruj autoryzację w plikach Shibboleth
Konfigurowanie komponentów dostawcy usług Shibboleth do asercji SAML
Konfigurowanie atrybutów asercji
Importuj metadane IDP i włącz jednorazowe logowanie po teście
Skonfiguruj logowanie pojedyncze w Control Hub za pomocą Shibboleth
list-menuW tym artykule
list-menuOpinia?

Można skonfigurować integrację Single Sign-On (SSO) między centrum sterowania a wdrożeniem wykorzystującym Shibboleth jako dostawcę tożsamości (IDP).

Pojedyncze logowanie i koncentrator sterowania

Pojedyncze logowanie (SSO) to proces uwierzytelniania sesji lub użytkownika, który umożliwia użytkownikowi podanie danych uwierzytelniających w celu uzyskania dostępu do jednej lub więcej aplikacji. Proces uwierzytelnia użytkowników dla wszystkich aplikacji, do których przyznano im prawa. Eliminuje dalsze monity, gdy użytkownicy przełączają aplikacje podczas określonej sesji.

Protokół federacyjny Security Assertion Markup Language (SAML 2.0) służy do zapewnienia uwierzytelniania SSO między chmurą Webex a dostawcą tożsamości (IdP).

Profile

Aplikacja Webex obsługuje tylko profil SSO przeglądarki internetowej. W profilu SSO przeglądarki internetowej aplikacja Webex obsługuje następujące powiązania:

  • Powiązanie POST -> POST zainicjowane przez SP

  • SP zainicjował REDIRECT -> Wiązanie POST

Format nazwaID

Protokół SAML 2.0 obsługuje kilka formatów NameID do komunikowania się o określonym użytkowniku. Aplikacja Webex obsługuje następujące formaty 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

W metadanych ładowanych z identyfikatora IDP pierwszy wpis jest skonfigurowany do użytku w Webex.

SingleLogout

Aplikacja Webex obsługuje pojedynczy profil wylogowania. W aplikacji Webex użytkownik może wylogować się z aplikacji, która używa protokołu pojedynczego wylogowania SAML, aby zakończyć sesję i potwierdzić wylogowanie za pomocą Twojego IDP. Upewnij się, że Twój IdP jest skonfigurowany dla SingleLogout.

Zintegruj Control Hub z Shibboleth

Przewodniki konfiguracji przedstawiają konkretny przykład integracji SSO, ale nie zapewniają wyczerpującej konfiguracji dla wszystkich możliwości. Na przykład, etapy integracji nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transientsą udokumentowane. Inne formaty, takie jak, urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressbędą działać dla integracji SSO, ale są poza zakresem naszej dokumentacji.

Skonfiguruj tę integrację dla użytkowników w organizacji Webex (w tym aplikacji Webex i innych usług administ Webex Meetings rowanych w Control Hub). Jeśli witryna Webex jest zintegrowana z Control Hub, witryna Webex dziedziczy zarządzanie użytkownikami. Jeśli nie możesz uzyskać dostępu Webex Meetings w ten sposób i nie jest zarządzany w Centrum sterowania, musisz przeprowadzić oddzielną integrację, aby włączyć SSO dlaWebex Meetings.

Kroki integracji odnoszą się do Shibboleth 2.4.5 w CentOS 7 z Tomcat 7 jako serwerem WWW.

Zanim zaczniesz

W przypadku SSO i Control Hub IDP muszą być zgodne ze specyfikacją SAML 2.0. Ponadto IDP muszą być skonfigurowane w następujący sposób:

Pobierz metadane Webex do swojego systemu lokalnego

1

Zaloguj się do Control Hub.

2

Przejdź do opcji Zarządz anie > Zabezpieczenia > U wierzytelnianie.

3

Przejdź do zakładki Dostawca tożsamości i kliknij Aktywuj SSO.

4

Wybierz IdP.

5

Wybierz typ certyfikatu dla swojej organizacji:

  • Samopodpisany przez Cisco — zalecamy ten wybór. Pozwól nam podpisać certyfikat, aby ś musiał go odnawiać tylko raz na pięć lat.
  • Pod@@ pisany przez publiczny organ certyfik acji — bezpieczniejszy, ale będziesz musiał często aktualizować metadane (chyba że dostawca usług IDP obsługuje zakotwiczenia zaufania).

Kotwice zaufania to klucze publiczne, które działają jako uprawnienia do weryfikacji certyfikatu podpisu cyfrowego. Aby uzyskać więcej informacji, zapoznaj się z dokument acją IDP.

6

Pobierz plik metadanych.

<org-ID>Nazwa pliku metadanych Webex to id b-meta- -SP.xml.

Skonfiguruj autoryzację w plikach Shibboleth

Po zainstalowaniu Shibboleth otrzymasz pliki konfiguracyjne z przykładami.

1

Przejdź do katalogu /opt/shibboleth -idp/conf, aby uzyskać dostęp do przykładowych plików.

2

Zdecyduj, którą metodę autoryzacji użyć — na przykład powiązać z LDAP. Active Directory

3

Edytuj plik handler.xml w następujący sposób:

Odrzuć komentarz

    <!--  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>

Komentarz

<ph:LoginHandler xsi:type="ph:RemoteUser"> 
<ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</ph:AuthenticationMethod>
    </ph:LoginHandler>
4

Wypełnij swoje dane, aby zezwo Active Directory lić na uwierzytelnianie. Podaj konfigurację pliku 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";
};

Konfigurowanie komponentów dostawcy usług Shibboleth do asercji SAML

1

Dodaj plik pobrany z Webex SP do katalog u /opt/shibboleth-idp/metadata.

2

Edytuj plik relying-party.xml; po tagu DefaultRelyingParty dodaj szczegóły asercji SAML dla 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>

W przypadku id należy użyć wartości EntityId z pliku metadanych Webex. Zastąp identyfikator przykładu identyfikatorem EntityID swojej organizacji.

3

Wewnątrz znacznika Metadata:MetadataProvider dodaj lokalizację pliku:

 <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>

Metadane SP pochodzą z pliku w systemie plików Shibboleth, w miejscu, w którym przesłano metadane dla organizacji Webex.

Konfigurowanie atrybutów asercji

1

W sekcji Łącznik danych określ, gdzie chcesz pobrać atrybuty użytkowników.

Active Directory, z identyfikatorem 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

W sekcji Definicja atrybutu zachowaj to, co jest już w konfiguracji dla programu TransientId.

3

Dodaj dodatkowy atrybut, którego oczekuje SP, i zdefiniuj, na co mapuje w źródle atrybutu.

Zmapuj atrybut mail (atrybut adresu e-mail wActive Directory) na uid (userId w 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

Określ atrybut, który należy dostarczyć każdej umowie SP w pliku attribute-filter.xml.

Podaj atrybut uid do Webex, który odwzorowuje się na adres e-mail użytkownika.

Zwolnij atrybut uid do umowy SP z 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>

Reguła utworzona w pliku attribute-resolver.xml powinna zawierać zasadę zwalniania atrybutu mail-attr do identyfikatora entityID, który pasuje do Webex.

5

Pobierz plik metadanych z serwera Shibboleth w /opt/shibboleth-idp/metadata. Nazwa pliku to idp-metadata.xml.

Importuj metadane IDP i włącz jednorazowe logowanie po teście

Po wyeksportowaniu metadanych Webex, skonfigurowaniu IDP i pobraniu metadanych IdP do systemu lokalnego, możesz je zaimportować do organizacji Webex z Centrum sterowania.

Zanim zaczniesz

Nie należy testować integracji SSO z interfejsu dostawcy tożsamości (iDP). Obsługujemy tylko przepływy inicjowane przez Usługodawcę (inicjowane przez SP), dlatego do tej integracji należy użyć testu SSO Control Hub.

1

Wybierz jeden:

  • Wróć do strony Control Hub — wybór certyfikatów w przeglądarce, a następnie kliknij przycisk Dalej.
  • Otwórz ponownie Control Hub, jeśli nie jest już otwarty na karcie przeglądarki. W widoku klienta w Centrum sterowania przejdź do menu Zarządzanie > Zab ezpieczenia > U wierzytelnianie, wybierz identyfikator identyfikacyjny, a następnie wybierz polecenie A kcje > Importuj metadane.
2

Na stronie Importuj metadane IdP przeciągnij i upuść plik metadanych Id P na stronę lub użyj opcji przeglądarki plików, aby zlokalizować i przesłać plik metadanych . Kliknij przycisk Dalej.

Powinieneś skorzystać z opcji Bardziej bezpieczne, jeśli możesz. Jest to możliwe tylko wtedy, gdy Twój identyfikator użył publicznego urzędu urzędowego do podpisania swoich metadanych.

We wszystkich innych przypadkach należy użyć opcji M niej bezpieczne. Dotyczy to sytuacji, gdy metadane nie są podpisane, podpisane samodzielnie lub podpisane przez prywatny urząd urzędowy.

Okta nie podpisuje metadanych, więc musisz wybrać opcję Mniej bezpieczne dla integr acji Okta SSO.

3

Wybierz opcję Testuj konfigurację SSO, a gdy otworzy się nowa karta przeglądarki, uwierzytelnij się za pomocą IDP, logując się.

Jeśli pojawi się błąd uwierzytelniania, może wystąpić problem z po świadczeniami. Sprawdź nazwę użytkownika i hasło i spróbuj ponownie.

Błąd aplikacji Webex zwykle oznacza problem z konfiguracją SSO. W takim przypadku ponownie przejdź przez kroki, zwłaszcza kroki, w których skopiujesz i wkle jasz metadane Control Hub do konfiguracji IDP.

Aby bezpośrednio wyświetlić obsługę logowania SSO, możesz również kliknąć Kopiuj adres URL do schowka z tego ekranu i wklej go w prywatnym oknie przeglądarki. Stamtąd możesz przejść przez logowanie się za pomocą SSO. Ten krok zatrzymuje fałszywe alarmy z powodu tokena dostępu, który może znajdować się w istniejącej sesji po zalogo waniu się.

4

Wróć do karty przeglądarki Control Hub.

  • Jeśli test zakończył się sukcesem, wybierz Test pomyślny. Włącz SSO i kliknij Dal ej.
  • Jeśli test się nie powiódł, wybierz opcję Test nieudany. Wyłącz SSO i kliknij Dal ej.

Konfiguracja SSO nie wchodzi w życie w Twojej organizacji, chyba że wybierz esz pierwszy przycisk radiowy i aktywujesz SSO.

Co robić dalej

Użyj procedur w Synchronizuj użytkowników Okta w, Cisco Webex Control Hub jeśli chcesz przeprowadzić udostępnianie użytkowników z Okta do chmury Webex.

Użyj procedur w sekcji Synchronizuj użytkowników identyfikatora Microsoft Entra ID, Cisco Webex Control Hub jeśli chcesz przeprowadzić udostępnianie użytkownika z Entra ID do chmury Webex.

Aby wyłączyć wiadomości e-mail wysyłane do nowych użytkowników aplikacji Webex w Twojej organizacji, możesz postępować zgodnie z procedurą Wyłącz automat yczne wiadomości e-mail. Dokument zawiera również najlepsze praktyki dotyczące wysyłania wiadomości do użytkowników w organizacji.

Czy ten artykuł był pomocny?
Czy ten artykuł był pomocny?