Najczęstsze pytania na temat logowania jednokrotnego przez SAML

Którą wersję protokołu SAML obsługuje interfejs API logowania jednokrotnego?

Obecnie obsługujemy SAML 2.0. Szczegółowe informacje na temat standardu SAML 2.0 znajdziesz na stronie http://www.oasis-open.org/specs/index.php#samlv2.0.

Czy logowanie jednokrotne przez SAML obsługuje protokoły POP3 i IMAP?

Nie. SAML działa tylko w aplikacjach internetowych Google Workspace.

Czy dla logowania jednokrotnego przez SAML obsługiwany jest kanał Atom w Gmailu?

Nie. Kanał Atom w Gmailu używa podstawowego uwierzytelniania HTTP.

Czy logowanie jednokrotne przez SAML obsługuje AuthSub?

Tak. SAML działa z AuthSub.

Czy mogę użyć szyfrowania RSA zamiast algorytmu DSA do wdrożenia logowania jednokrotnego?

Tak. Możesz wybrać algorytm szyfrowania RSA lub DSA. Oba są obsługiwane.

Jak wygenerować certyfikat weryfikacji wymagany do używania logowania jednokrotnego?

Certyfikaty X509 możesz wygenerować przy użyciu polecenia openssl. Więcej informacji znajdziesz w artykule Generowanie kluczy i certyfikatów do logowania jednokrotnego.

Czy po wdrożeniu logowania jednokrotnego w domenie użytkownicy nadal będą mogli logować się bezpośrednio w usługach Google?

Nie. Po wdrożeniu logowania jednokrotnego użytkownicy w domenie nie mogą logować się bezpośrednio w usługach Google. Superadministratorzy nadal mogą logować się w panelu sterowania Google (np.http://www.google.com/a/example.com).

W jaki sposób nietrwały plik cookie sesji, który identyfikuje użytkownika podczas sesji przeglądarki, może zostać usunięty (na przykład po wylogowaniu)?

Po pomyślnym uwierzytelnieniu przez SAML Google ustawia plik cookie sesji, aby zidentyfikować sesję użytkownika. Gdy użytkownik się wyloguje, na przykład przez kliknięcie przycisku wylogowania, taki plik cookie musi zostać zniszczony. Jeśli Twoje wdrożenie obejmuje zarządzanie trwałymi sesjami (funkcja zapamiętywania użytkowników na komputerze), konieczna może być kontrola czasu usuwania plików cookie sesji. Gdy użytkownik się wylogowuje, Google przekierowuje go do programu servlet wylogowania. W tym programie możesz udostępnić użytkownikowi kilka opcji, które określają, czy plik cookie sesji ma zostać usunięty.

Dlaczego adres URL zmiany hasła nie działa?

Zastosowanie aktualizacji adresu URL zmiany hasła w ustawieniach logowania jednokrotnego trwa około godziny.

Dlaczego formularz HTML odpowiedzi SAML działa w przeglądarce Firefox, ale nie w Internet Explorerze?

Przyczyną może być błędna interpretacja atrybutu RelayState w Internet Explorerze, który odczytuje „&ltmpl” jako „<mpl”. Aby temu zapobiec, musisz zmienić specjalne znaki XML w parametrze RelayState. Znaki { &, <, >, ', " } zastąp odpowiednio ciągami { &amp;, <, >, &apos;, &quot; }.

Jak umożliwić użytkownikom wyświetlanie strony startowej partnera bez uwierzytelniania?

W tym temacie grupy dyskusyjnej znajdziesz przykładową odpowiedź SAML.

Co to jest atrybut Recipient (Odbiorca), który jest wymagany w odpowiedzi SAML?

Zgodnie z sekcją 4.1.4.2 specyfikacji profilów SAML 2.0 atrybut Recipient powinien zawierać adres URL usługi ACS (Assertion Consumer Service – usługa konsumenta potwierdzenia). Znajduje się tutaj:

<samlp:Response ...>
  <saml:Assertion ...>
    <saml:Subject>
      <saml:NameID ...>user@domain.com</saml:NameID>
      <saml:SubjectConfirmation ...>
        <saml:SubjectConfirmationData Recipient="https://www.google.com/a/domain.com/acs" .../>
      </saml:SubjectConfirmation>
    </saml:Subject>
  </saml:Assertion>
</samlp:Response>

W odpowiedziach na poniższe pytania opisaliśmy sposób dodawania atrybutu Recipient do odpowiedzi SAML.

Jak mogę się upewnić, że mój dostawca tożsamości innej firmy określi odpowiedni atrybut Recipient?

Jeśli Twój dostawca tożsamości (komercyjny lub open source) obsługuje SAML 2.0, to powinien określić prawidłowy atrybut Recipient. Jeśli jednak widzisz jeden z poniższych komunikatów o błędzie, oznacza to, że atrybut Recipient jest ustawiony nieprawidłowo. W takim przypadku skontaktuj się z dostawcą lub administratorem oprogramowania i przekaż link to tej strony.

Czy w przypadku korzystania z logowania jednokrotnego użytkownicy mogą się uwierzytelniać, korzystając z adresu URL logowania konsoli administracyjnej?

Tak. Logowanie jednokrotne przez SAML umożliwia przeniesienie urzędu logowania Google Workspace do własnego oprogramowania dostawcy tożsamości, takiego jak istniejący portal logowania. W takiej sytuacji oprogramowanie kontroluje uwierzytelnianie kont użytkowników i zarządza nim, a Google Workspace przekierowuje próby uzyskania dostępu do portalu logowania jednokrotnego. Warto jednak pamiętać, że administratorzy mogą zarządzać tymi usługami przy użyciu adresu URL logowania w konsoli administracyjnej Google (https://www.google.com/a/example.com). Daje to więcej możliwości, gdy występują problemy z portalem logowania jednokrotnego lub wymagana jest jego aktualizacja.

Co oznacza komunikat o błędzie „Nie można uzyskać dostępu do tej usługi, ponieważ Twoje żądanie logowania nie zawierało żadnych informacji o adresacie”?

Oznacza to, że w odpowiedzi SAML nie ma wymaganego atrybutu Recipient.

Co oznacza komunikat o błędzie „Nie można uzyskać dostępu do tej usługi, ponieważ Twoje żądanie logowania zawierało nieprawidłowe informacje o adresacie”?

Oznacza to, że atrybut Recipient w odpowiedzi SAML nie jest zgodny z adresem URL usługi ACS.

Co oznacza komunikat o błędzie „Nie można uzyskać dostępu do tego konta, ponieważ nie można potwierdzić danych logowania”?

Zazwyczaj oznacza to, że klucz prywatny używany do podpisywania odpowiedzi SAML nie pasuje do certyfikatu klucza publicznego zapisanego w danych Google Workspace. W takim przypadku zaimportuj certyfikat w panelu sterowania logowania jednokrotnego i spróbuj jeszcze raz.