Dziękujemy za opinię.
Integracja jednokrotnego logowania w Control Hub
Opinia?Przed wprowadzeniem funkcji logowania jednokrotnego (SSO) Webex domyślnie korzystał z uwierzytelniania podstawowego. Podstawowe uwierzytelnianie wymaga od użytkowników podawania nazwy użytkownika i hasła Webex przy każdym logowaniu. Jeśli w swojej organizacji masz własnego dostawcę tożsamości (IdP), możesz zintegrować go z usługą SSO w Control Hub. Dzięki logowaniu jednokrotnemu użytkownicy mogą korzystać z jednego, wspólnego zestawu danych uwierzytelniających dla aplikacji Webex w Twojej organizacji.
Jeśli wolisz używać uwierzytelniania podstawowego, nie musisz nic robić. Należy jednak pamiętać, że podstawowe uwierzytelnianie może być mniej bezpieczne i mniej wygodne dla użytkowników niż logowanie jednokrotne, zwłaszcza jeśli Twoja organizacja korzysta już z dostawcy tożsamości. Aby zapewnić większe bezpieczeństwo dzięki podstawowemu uwierzytelnianiu, zalecamy korzystanie z uwierzytelniania wieloskładnikowego (MFA) w Control Hub. Aby uzyskać więcej informacji, zobacz Włączanie integracji uwierzytelniania wieloskładnikowego w Control Hub.
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 jednokrotne (SSO) dla wielu dostawców tożsamości w swojej organizacji, zapoznaj się z artykułem Logowanie jednokrotne (SSO) z wieloma dostawcami tożsamości w usłudze 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.
Zalecamy uwzględnienie funkcji Single Log Out (SLO) w konfiguracji metadanych podczas konfigurowania federacji Webex SAML. Ten krok jest kluczowy, aby mieć pewność, że tokeny użytkownika zostaną unieważnione zarówno u Dostawcy Tożsamości (IdP), jak i u Dostawcy Usług (SP). Jeśli administrator nie wykona tej konfiguracji, Webex wyświetli użytkownikom alert o konieczności zamknięcia przeglądarki w celu unieważnienia wszelkich otwartych sesji.
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 Format NameID na urn:oasis:names:tc:SAML:2.0:nameid-format:przejściowy
-
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 udokumentowano kroki integracji dla nameid-format urn:oasis:names:tc:SAML:2.0:nameid-format:transient. 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 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 |
Zaloguj się do centrum sterowania. |
| 2 |
Przejdź do . |
| 3 |
Przejdź do zakładki Dostawca tożsamości i kliknij Aktywuj SSO. |
| 4 |
Wybierz Webex jako dostawcę tożsamości i kliknij Dalej. |
| 5 |
Zaznacz Przeczytałem i zrozumiałem, jak działa Webex IdP i kliknij Dalej. |
| 6 |
Skonfiguruj regułę routingu. Po dodaniu reguły routingu Twój dostawca tożsamości zostanie dodany i wyświetlony na karcie Dostawca tożsamości.
Aby uzyskać więcej informacji, zapoznaj się z artykułem Logowanie jednokrotne z wieloma dostawcami tożsamości w usłudze 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 dodatku SAML tracer dla przeglądarek Firefox, Chromelub Edge.
-
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.
|
