Logowanie jednokrotne (SSO)

Logowanie jednokrotne (SSO) umożliwia użytkownikom logowanie się do wielu firmowych aplikacji w chmurze za pomocą jednego zestawu danych logowania. Workspace (i Google Cloud Platform) obsługują logowanie jednokrotne od zewnętrznych dostawców tożsamości.

Workspace obsługuje protokoły SSO oparte zarówno na SAML, jak i na OIDC. Logowanie jednokrotne przez SAML obsługuje dowolnego dostawcę tożsamości. Obecnie OIDC obsługuje tylko Microsoft Entra ID.

Aby korzystać z logowania jednokrotnego, skonfiguruj profile SSO, a następnie przypisz je do grup użytkowników lub jednostek organizacyjnych. Umożliwia to obsługę wielu dostawców tożsamości i testowanie konfiguracji logowania jednokrotnego. Jest to zalecany system logowania jednokrotnego. Dostępny jest też starszy profil SSO dla organizacji (tylko dla protokołu SAML).

Logowanie jednokrotne jest też dostępne na urządzeniach z Chrome. Więcej informacji znajdziesz w artykule Konfigurowanie logowania jednokrotnego przez SAML na urządzeniach z Chrome OS.

Dodatkowa weryfikacja po logowaniu jednokrotnym

Po skonfigurowaniu logowania jednokrotnego użytkownicy, którzy logują się do zewnętrznego dostawcy tożsamości, mogą korzystać z aplikacji Google bez dodatkowej weryfikacji, z tymi wyjątkami:

  • Nawet jeśli użytkownicy są już zalogowani do dostawcy tożsamości, Google czasami prosi o potwierdzenie tożsamości w ramach dodatkowych zabezpieczeń. Więcej informacji (także na temat tego, jak w razie potrzeby wyłączyć to dodatkowe sprawdzanie tożsamości) znajdziesz w artykule Omówienie bezpiecznego logowania przez SAML.
  • Możesz skonfigurować dodatkową weryfikację dwuetapową dla użytkowników korzystających z usług Google. Weryfikacja dwuetapowa jest zwykle pomijana po włączeniu SSO. Więcej informacji znajdziesz w sekcji Włączanie testów zabezpieczających logowanie przy użyciu SSO artykułu o weryfikowaniu tożsamości użytkownika przy użyciu dodatkowych zabezpieczeń.
Omówienie obsługiwanej przez parnera usługi logowania jednokrotnego opartej na standardzie SAML

Rysunek 1 przedstawia proces logowania się użytkownika w aplikacji Google, takiej jak Gmail, przy użyciu obsługiwanej przez partnera usługi logowania jednokrotnego opartej na standardzie SAML. Szczegółowe wyjaśnienie każdego kroku zawiera lista numerowana pod rysunkiem.

Ważne: przed rozpoczęciem tej procedury partner musi przekazać Google adres URL swojej usługi logowania jednokrotnego oraz klucz publiczny, którego firma Google powinna używać do weryfikowania odpowiedzi SAML.

Rysunek 1 przedstawia proces logowania się w Google przy użyciu usługi logowania jednokrotnego opartej na standardzie SAML.

Ten rysunek przedstawia poniższe kroki.

  1. Użytkownik próbuje połączyć się z aplikacją hostowaną Google, na przykład z Gmailem, Kalendarzem Google lub inną usługą Google.
  2. Google generuje żądanie uwierzytelnienia SAML, które zostaje zakodowane i umieszczone w adresie URL dla usługi logowania jednokrotnego partnera. W adresie URL logowania jednokrotnego jest też umieszczony parametr RelayState zawierający zakodowany URL aplikacji Google, z którą chce się połączyć użytkownik. Parametr RelayState to niejednoznaczny identyfikator, który jest przekazywany z powrotem bez modyfikacji i bez sprawdzania.
  3. Google wysyła przekierowanie do przeglądarki użytkownika. Przekierowanie zawiera zakodowane żądanie uwierzytelnienia SAML, które powinno zostać przekazane do usługi logowania jednokrotnego partnera.
  4. Przeglądarka przekierowuje do adresu URL logowania jednokrotnego.
  5. Partner dekoduje żądanie SAML i wyodrębnia URL zarówno dla usługi konsumenta potwierdzenia Google (Assertion Consumer Service, ACS), jak i docelowego URL-a użytkownika (parametr RelayState).
  6. Partner następnie uwierzytelnia użytkownika. Partnerzy mogą uwierzytelniać użytkowników, prosząc o prawidłowe dane logowania lub sprawdzając, czy istnieją prawidłowe pliki cookie sesji.
  7. Partner generuje odpowiedź SAML zawierającą nazwę uwierzytelnionego użytkownika. Zgodnie ze specyfikacją SAML 2.0 ta odpowiedź zostaje cyfrowo podpisana przy użyciu publicznych i prywatnych kluczy DSA/RSA partnera.
  8. Partner koduje odpowiedź SAML i parametr RelayState, a następnie zwraca te informacje do przeglądarki użytkownika. Partner udostępnia mechanizm, dzięki któremu przeglądarka może przekazać te informacje do usługi Google ACS. Partner może na przykład umieścić w formularzu odpowiedź SAML i docelowy adres URL oraz udostępnić przycisk, który użytkownik może kliknąć, aby przesłać formularz do Google. Partner może też umieścić na stronie kod JavaScript, który przesyła formularz do Google.
  9. Przeglądarka wysyła odpowiedź na adres URL usługi ACS. Google ACS weryfikuje odpowiedź SAML przy użyciu klucza publicznego partnera. Jeśli odpowiedź zostanie zweryfikowana, ACS przekierowuje użytkownika do docelowego adresu URL.
  10. Użytkownik jest zalogowany w aplikacji Google.

Synchronizacja kont użytkowników między dostawcą tożsamości a Google

Aby uprościć zarządzanie cyklem życia użytkowników, większość organizacji korzystających z logowania jednokrotnego synchronizuje katalog użytkowników od dostawcy tożsamości z Google. Po włączeniu synchronizacji nowi (lub usunięci) użytkownicy po stronie dostawcy tożsamości są automatycznie dodawani lub usuwani jako użytkownicy Workspace. Directory Sync od Google obsługuje Active Directory i Entra ID. Większość dostawców tożsamości obsługuje synchronizację z Google. Instrukcje konfiguracji znajdziesz w dokumentacji dostawcy tożsamości.

Logowanie jednokrotne i bezpieczny LDAP

Bezpieczny LDAP wymaga hasła Google i jest niezgodny z logowaniem jednokrotnym.

Czy to było pomocne?

Jak możemy ją poprawić?
Szukaj
Wyczyść wyszukiwanie
Zamknij wyszukiwanie
Menu główne
7227811799183205915
true
Wyszukaj w Centrum pomocy
true
true
true
true
true
73010
false
false
false