Logowanie jednokrotne i Control Hub

Jednokrotne logowanie (SSO) to proces uwierzytelniania sesji lub użytkownika, który umożliwia użytkownikowi podanie poświadczeń w celu uzyskania dostępu do jednej lub większej liczby aplikacji. Proces uwierzytelnia użytkowników we wszystkich aplikacjach, do których mają uprawnienia. Eliminuje dalsze monity, gdy użytkownicy przełączają aplikacje podczas określonej sesji.

Protokół federacyjny języka SAML 2.0 (Security Assertion Markup Language) służy do zapewniania 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 App obsługuje następujące powiązania:

  • SP zainicjował test POST -> wiązanie testu POST

  • SP zainicjował PRZEKIEROWANIE -> wiązanie POST

Format identyfikatora nazwy

Protokół SAML 2.0 obsługuje kilka formatów NameID do komunikacji z określonym użytkownikiem. 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 od dostawcy tożsamości pierwszy wpis jest skonfigurowany do użycia w aplikacji Webex.

SingleLogout

Aplikacja Webex obsługuje profil jednokrotnego wylogowania. W aplikacji Webex użytkownik może wylogować się z aplikacji, która korzysta z pojedynczego protokołu SAML, aby zakończyć sesję i potwierdzić wylogowanie za pomocą dostawcy tożsamości. Upewnij się, że usługa IdP jest skonfigurowana dla funkcji SingleLogout.

Integracja Control Hub z Shibboleth


 

Przewodniki konfiguracyjne przedstawiają konkretny przykład integracji logowania SSO, ale nie zawierają wyczerpującej konfiguracji obejmującej wszystkie możliwości. Na przykład etapy integracji dotyczące formatu nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient zostały 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:emailAddress będą działać w przypadku integracji logowania SSO, ale wykraczają poza zakres naszej dokumentacji.

Skonfiguruj tę integrację dla użytkowników w organizacji Webex (w tym aplikacji Webex , Webex Meetings i innych usług administrowanych 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 do Webex Meetings w ten sposób i nie jest to zarządzane w Control Hub, musisz przeprowadzić oddzielną integrację, aby włączyć SSO dla Webex Meetings. (Patrz Konfigurowanie jednokrotnego logowania dla Webex Aby uzyskać więcej informacji na temat integracji SSO w administracji witryny).

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

Przed rozpoczęciem

W przypadku logowania SSO i korzystania z Control Hub dostawcy tożsamości muszą być zgodni ze specyfikacją SAML 2.0. Ponadto dostawców tożsamości należy skonfigurować w następujący sposób:

Pobierz metadane Webex do systemu lokalnego

1

Z widoku klienta whttps://admin.webex.com , przejdź do Zarządzanie > Ustawienia organizacji , a następnie przewiń do Uwierzytelnianie , a następnie włącz Jednokrotne logowanie ustawienia, aby uruchomić kreatora konfiguracji.

2

Wybierz typ certyfikatu dla swojej organizacji:

  • Z podpisem własnym Cisco — Zalecamy ten wybór. Pozwól nam podpisać certyfikat, abyś mógł go odnawiać tylko raz na pięć lat.
  • Podpisane przez publiczny urząd certyfikacji — Bezpieczniejsze, ale konieczne jest częste aktualizowanie metadanych (chyba że dostawca dostawcy tożsamości obsługuje kotwice zaufania).

 

Kotwice zaufania to klucze publiczne, które pełnią funkcję autoryzacji weryfikacji certyfikatu podpisu cyfrowego. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją dostawcy tożsamości.

3

Pobierz plik metadanych.

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

Konfigurowanie autoryzacji w plikach Shibboleth

Po zainstalowaniu Shibboleth, pliki konfiguracyjne są dostarczane z przykładami.

1

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

2

Zdecyduj, której metody autoryzacji użyć — na przykład LDAP wiąże się z usługą Active Directory.

3

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

Bez komentarza

    <!--  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 szczegóły usługi Active Directory, aby umożliwić 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";
};

Skonfiguruj komponenty dostawcy usług Shibboleth dla potwierdzenia SAML

1

Dodaj plik pobrany z Webex SP do katalogu/opt/shibboleth-idp/metadanych.

2

Edytuj relying-party.xml plik; po znaczniku DefaultRelyingParty dodaj szczegóły potwierdzenia 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 identyfikatora należy użyć wartości EntityID z pliku metadanych Webex. Zastąp identyfikator przykładu identyfikatorem EntityID swojej organizacji.

3

Wewnątrz metadanych:Znacznik 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 lokalizacji, w której zostały przesłane metadane dla organizacji Webex.

Skonfiguruj atrybuty potwierdzenia

1

W sekcji Data Connector określ, gdzie należy pobrać atrybuty dotyczące 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 definicji atrybutu zachowaj to, co jest już w konfiguracji dla identyfikatora transientID.

3

Dodaj dodatkowy atrybut oczekiwany przez SP i określ, do czego mapuje w źródle atrybutu.

Mapuj adres e-mail atrybutu (atrybut adresu e-mail w usłudze Active Directory) na identyfikator uid (UserID w usłudze 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

Zdefiniuj, który atrybut ma być dołączany do każdej umowy SP w pliku attribute-filter.xml .

Podaj atrybut uid Webex, który jest mapowany na adres e-mail użytkownika.

Zwolnij identyfikator atrybutu 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ć zasady zwalniania atrybutu mail-attr z identyfikatora EntityID, który jest zgodny z Webex.

5

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

Zaimportuj metadane dostawcy tożsamości i włącz jednokrotne logowanie po teście

Po wyeksportowaniu metadanych Webex , skonfigurowaniu dostawcy tożsamości i pobraniu metadanych dostawcy tożsamości do systemu lokalnego możesz zaimportować je do swojej organizacji Webex z Control Hub.

Przed rozpoczęciem

Nie należy testować integracji SSO z interfejsu dostawcy tożsamości (IdP). Obsługujemy tylko przepływy zainicjowane przez dostawcę usług (inicjowane przez dostawcę usług), dlatego w przypadku tej integracji należy użyć testu SSO w usłudze Control Hub.

1

Wybierz jedną z nich:

  • Wróć do Control Hub — strona wyboru certyfikatu w przeglądarce, a następnie kliknij Dalej .
  • Jeśli Control Hub nie jest już otwarty na karcie przeglądarki, w widoku klienta whttps://admin.webex.com , przejdź do Zarządzanie > Ustawienia organizacji , przewiń do Uwierzytelnianie , a następnie wybierz Działania > Importuj metadane .
2

Na stronie Importowanie metadanych dostawcy tożsamości przeciągnij i upuść plik metadanych dostawcy tożsamości na stronę lub użyj opcji przeglądarki plików, aby zlokalizować i przesłać plik metadanych. Kliknij przycisk Dalej.

Należy użyć Bardziej bezpieczne opcję, jeśli możesz. Jest to możliwe tylko wtedy, gdy dostawca tożsamości używał publicznego urzędu certyfikacji do podpisywania metadanych.

We wszystkich innych przypadkach należy użyć przycisku Mniej bezpieczne opcja. Dotyczy to również sytuacji, w których metadane nie są podpisane, samopodpisane ani podpisane przez prywatny urząd certyfikacji.


 

Okta nie podpisuje metadanych, więc należy wybrać Mniej bezpieczne dla integracji Okta SSO .

3

Wybierz Przetestuj konfigurację SSO , a po otwarciu nowej karty przeglądarki uwierzytelnij się u dostawcy tożsamości, logując się.


 

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

Błąd aplikacji Webex zwykle oznacza problem z konfiguracją SSO . W takim przypadku ponownie wykonaj kroki, zwłaszcza te, w których kopiujesz i wklejasz metadane usługi Control Hub do konfiguracji dostawcy tożsamości.


 

Aby bezpośrednio wyświetlić środowisko logowania SSO, można również kliknąć na tym ekranie opcję Skopiuj adres URL do schowka i wkleić skopiowany adres w oknie przeglądarki w trybie prywatnym. W tym oknie można przejść przez proces logowania SSO. Ten krok zatrzymuje fałszywe alarmy z powodu tokenu dostępu, który może znajdować się w istniejącej sesji po zalogowaniu.

4

Wróć do karty przeglądarki Control Hub.

  • Jeśli test zakończył się pomyślnie, wybierz Test zakończony powodzeniem. Włącz SSO i kliknij Dalej .
  • Jeśli test zakończył się niepowodzeniem, wybierz Test nie powiódł się. Wyłącz SSO i kliknij Dalej .

 

Konfiguracja SSO nie zacznie obowiązywać w organizacji, chyba że wybierzesz pierwszy przycisk radiowy i aktywujesz SSO.

Co zrobić dalej

Skorzystaj z procedur opisanych w Synchronizuj użytkowników Okta z Cisco Webex Control Hub jeśli chcesz przeprowadzić obsługę administracyjną użytkowników z Okta do chmury Webex .

Skorzystaj z procedur opisanych w Synchronizowanie użytkowników usługi Azure Active Directory z Cisco Webex Control Hub jeśli chcesz przeprowadzić inicjowanie obsługi administracyjnej użytkowników z usługi Azure AD do chmury Webex .

Możesz postępować zgodnie z procedurą w Wyłącz automatyczne wiadomości e-mail aby wyłączyć wiadomości e-mail wysyłane do nowych użytkowników aplikacji Webex w organizacji. Dokument zawiera również najważniejsze wskazówki dotyczące wysyłania wiadomości do użytkowników w organizacji.