Wymienione poniżej rozwiązania do zarządzania dostępem przez WWW i rozwiązania federacyjne zostały przetestowane pod kątem działania w organizacjach Webex. Dokumenty, do których prowadzą poniższe łącza, zawierają instrukcje integracji poszczególnych dostawców tożsamości z organizacją Webex.


 

Te przewodniki obejmują integrację logowania SSO w przypadku usług Webex zarządzanych w Control Hub (https://admin.webex.com). Jeśli chcesz zintegrować logowanie SSO w witrynie Webex Meetings (zarządzanej za pomocą portalu Administrowanie witryną), przeczytaj artykuł Konfigurowanie jednokrotnego logowania w witrynie Cisco Webex.

Jeśli chcesz skonfigurować logowanie SSO dla wielu dostawców tożsamości w organizacji, zapoznaj się z logowaniem SSO z wieloma dostawcami tożsamości w Webex.

Jeśli na poniższej liście nie widzisz swojego dostawcy tożsamości, wykonaj ogólne czynności opisane na karcie Konfiguracja logowania SSO w tym artykule.

Jednokrotne logowanie (SSO) umożliwia użytkownikom bezpieczne logowanie się do usługi Webex poprzez uwierzytelnienie się przy użyciu wspólnego dostawcy tożsamości (IdP) organizacji. Aplikacja Webex używa usługi Webex do komunikowania się z usługą tożsamości platformy Webex. Usługa tożsamości uwierzytelnia się u wybranego dostawcy tożsamości.

Konfiguracja rozpoczyna się w Control Hub. W tej sekcji opisano ogólne czynności związane z integracją zewnętrznego dostawcy tożsamości.


 
W przypadku konfigurowania logowania SSO przy użyciu dostawcy tożsamości można wykonać mapowanie dowolnego atrybutu na identyfikator użytkownika (uid). Przykładowo można na identyfikator uid zamapować nazwę główną użytkownika (userPrincipalName), alias adresu e-mail, alternatywny adres e-mail lub dowolny inny odpowiedni atrybut. Dostawca tożsamości musi dopasować jeden z adresów e-mail użytkownika do identyfikatora uid podczas logowania. Usługa Webex obsługuje mapowanie do 5 adresów e-mail na jeden identyfikator użytkownika.

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:

  • Ustaw atrybut formatu identyfikatora nazwy na urn:oasis:names:tc:SAML:2.0:nameid-format:transient

  • Skonfiguruj zgłoszenie u dostawcy tożsamości zgodnie z typem wdrażanego logowania SSO:

    • Logowanie SSO (dla organizacji) — jeśli konfigurujesz logowanie SSO w imieniu organizacji, skonfiguruj zgłoszenie dostawcy tożsamości tak, aby zawierało nazwę atrybutu uid z wartością zamapowaną na atrybut wybrany w Łączniku usług katalogowych lub na atrybut użytkownika zgodny z atrybutem wybranym w usłudze tożsamości Webex. (Tym atrybutem może być na przykład adres e-mail lub nazwa główna użytkownika).

    • Logowanie SSO partnera (tylko w przypadku dostawców usług) — jeśli jesteś administratorem dostawcy usługi, który konfiguruje logowanie SSO partnera do użytku przez organizacje klientów zarządzane przez tego dostawcę usługi, skonfiguruj zgłoszenie dostawcy tożsamości tak, aby zawierało atrybut mail (zamiast uid). Wartość ta musi być mapowana na atrybut wybrany w Łączniku usług katalogowych lub na atrybut użytkownika zgodny z atrybutem wybranym w usłudze tożsamości Webex.


     

    Aby uzyskać więcej informacji na temat mapowania atrybutów niestandardowych w przypadku logowania SSO lub logowania SSO partnera, zobacz https://www.cisco.com/go/hybrid-services-directory.

  • Tylko logowanie SSO partnera. Dostawca tożsamości musi obsługiwać wiele adresów URL usługi konsumenta potwierdzenia (ACS). Aby zapoznać się z przykładami konfigurowania wielu adresów URL usługi ACS u dostawcy tożsamości, zobacz:

  • Użyj obsługiwanej przeglądarki: zalecamy najnowszą wersję przeglądarki Mozilla Firefox lub Google Chrome.

  • Wyłącz w przeglądarce blokowanie okienek wyskakujących.


 

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.

Należy ustanowić umowę SAML między usługą tożsamości platformy Webex a dostawcą tożsamości.

Do pomyślnego ustanowienia umowy SAML potrzebne są dwa pliki:

  • Plik metadanych od dostawcy tożsamości, który należy przekazać do usługi Webex.

  • Plik metadanych z usługi Webex, który należy przekazać dostawcy tożsamości.

To jest przykład pliku metadanych usługi PingFederate z metadanymi od dostawcy tożsamości.

Plik metadanych z usługi tożsamości.

Poniżej przedstawiono elementy, które można zobaczyć w pliku metadanych z usługi tożsamości.

  • EntityID — służy do identyfikowania umowy SAML w konfiguracji dostawcy tożsamości.

  • Podpisane żądanie AuthN ani potwierdzenia podpisu nie są wymagane, ponieważ element jest zgodny z żądaniami dostawcy tożsamości w pliku metadanych.

  • Podpisany plik metadanych dla dostawcy tożsamości w celu zweryfikowania, czy metadane należą do usługi tożsamości.

1

Z widoku klienta w Control Hub ( https://admin.webex.com) przejdź do Zarządzanie > Ustawienia organizacji, przewiń do uwierzytelniania i kliknij Aktywuj ustawienie SSO , aby uruchomić kreatora konfiguracji.

2

Wybierz Webex jako IdP i kliknij Dalej .

3

Sprawdź Znam i rozumiem, jak działa Webex IdP i kliknij Dalej .

4

Skonfiguruj regułę routingu.

Po dodaniu reguły routingu Twój dostawca tożsamości zostanie dodany i będzie wyświetlany w obszarze Dostawca tożsamości kartę.
Aby uzyskać więcej informacji, zapoznaj się z SSO z wieloma dostawcami tożsamości w Webex.

W przypadku otrzymania powiadomienia o wygaśnięciu certyfikatu lub konieczności sprawdzenia istniejącej konfiguracji logowania SSO można użyć funkcji zarządzania jednokrotnym logowaniem (SSO) w Control Hub, które pozwalają zarządzać certyfikatami i wykonywać ogólne działania dotyczące obsługi logowania SSO.

Jeśli wystąpią problemy z integracją logowania SSO, odnieś się do wymagań i procedury opisanych w tej sekcji, aby rozwiązać problem z przepływem SAML między dostawcą tożsamości a platformą Webex.

  • Użyj rozszerzenia do monitorowania danych SAML dla przeglądarki Firefox lub Chrome.

  • Aby rozwiązać problem, użyj przeglądarki internetowej, w której zainstalowano narzędzie do debugowania i monitorowania danych SAML i przejdź do internetowej wersji usługi Webex pod adresem https://web.webex.com.

Poniżej przedstawiono przepływ komunikatów między aplikacją Webex, usługami Webex, usługą tożsamości platformy Webex a dostawcą tożsamości (IdP).

1

Przejdź do strony https://admin.webex.com. W przypadku włączonego logowania SSO aplikacja wyświetla monit o podanie adresu e-mail.

Aplikacja wysyła informacje do usługi Webex, która weryfikuje adres e-mail.

2

Aplikacja wysyła żądanie GET do serwera autoryzacji OAuth w celu uzyskania tokenu. Żądanie jest przekierowywane do usługi tożsamości za pomocą przepływu logowania SSO lub nazwy użytkownika i hasła. Zwracany jest adres URL serwera uwierzytelniania.

Żądanie GET jest widoczne w pliku monitorowania.

W sekcji parametrów usługa szuka kodu OAuth, adresu e-mail użytkownika, który wysłał żądanie, a także innych szczegółów uwierzytelniania OAuth, takich jak ClientID, redirectURI i Scope.

3

Aplikacja Webex żąda potwierdzenia SAML od dostawcy tożsamości przy użyciu żądania SAML HTTP POST.

Gdy logowanie SSO jest włączone, mechanizm uwierzytelniania w usłudze tożsamości przekierowuje na adres URL dostawcy tożsamości dla logowania SSO. Adres URL dostawcy tożsamości to adres dostarczony podczas wymiany metadanych.

Sprawdź w narzędziu do monitorowania komunikat SAML POST. Widoczny jest komunikat HTTP POST do dostawcy tożsamości zażądany przez brokera dostawcy tożsamości.

Parametr RelayState pokazuje poprawną odpowiedź od dostawcy tożsamości.

Sprawdź wersję dekodowania żądania SAML. Nie ma upoważnienia AuthN, a miejsce docelowe odpowiedzi powinno być przekierowywane na docelowy adres URL dostawcy tożsamości. Upewnij się, że format identyfikatora nazwy (nameid-format) jest poprawnie skonfigurowany u dostawcy tożsamości pod poprawnym identyfikatorem EntityID (SPNameQualifier).

Format identyfikatora nazwy dostawcy tożsamości został określony, a nazwa umowy została skonfigurowana podczas tworzenia umowy SAML.

4

Uwierzytelnianie aplikacji odbywa się między zasobami sieci WWW systemu operacyjnego a dostawcą tożsamości.

W zależności od dostawcy tożsamości i mechanizmów uwierzytelniania skonfigurowanych u dostawcy tożsamości rozpoczynane są różne przepływy od dostawcy tożsamości.

5

Aplikacja wysyła żądanie HTTP POST z powrotem do usługi tożsamości, dołączając atrybuty dostarczone przez dostawcę tożsamości i uzgodnione w początkowej umowie.

Po pomyślnym uwierzytelnieniu aplikacja wysyła informacje w komunikacie SAML POST do usługi tożsamości.

Wartość RelayState jest taka sama jak w poprzednim komunikacie HTTP POST, w którym aplikacja informuje dostawcę tożsamości o tym, który identyfikator EntityID żąda potwierdzenia.

6

Potwierdzenie SAML od dostawcy tożsamości do Webex.

7

Usługa tożsamości otrzymuje kod uwierzytelnienia, który jest zastępowany tokenem dostępu i odświeżania OAuth. Token ten służy do uzyskiwania dostępu do zasobów w imieniu użytkownika.

Gdy usługa tożsamości zweryfikuje poprawność odpowiedzi od dostawcy tożsamości, wystawi token OAuth, który umożliwia aplikacji Webex dostęp do poszczególnych usług Webex.