SSO mit Google Workspace einrichten

Diese Seite behandelt die Google-Workspace-Seite einer SSO-Verbindung. Die Bird-Seite (Domain verifizieren, testen, aktivieren und SSO erzwingen) ist bei jedem Anbieter gleich und befindet sich unter SSO und Provisioning.

Google und Bird benötigen jeweils Werte vom anderen. Wo Sie beginnen, hängt vom Protokoll ab. Halten Sie beide Seiten offen, während Sie arbeiten.

Zwei Verhaltensweisen von Google verursachen die meisten fehlgeschlagenen Ersttests, und keine davon meldet etwas an Bird:

• Aktivieren Sie den Nutzerzugriff, bevor Sie testen. Eine neue benutzerdefinierte SAML-App ist standardmäßig für alle deaktiviert. Solange Sie sie nicht für die Personen aktivieren, die sich anmelden sollen, lehnt Google auf seiner Seite ab und das Testfenster zeigt nichts an.
• Warten Sie nach dem Speichern einige Minuten. Google übernimmt Änderungen an einer SAML-App (Response-Signierung, Name-ID-Format, Nutzerzugriff) mit einer Verzögerung von etwa zwei bis vier Minuten. Ein Testlauf innerhalb dieses Zeitfensters meldet die vorherige Konfiguration, was wie ein Bird-Problem aussieht, aber keines ist.

SAML

Beginnen Sie für SAML in Bird. Entity ID und Assertion Consumer Service URL einer SAML-Verbindung leiten sich aus der Verbindung selbst ab. Erstellen Sie sie daher mit I have not set up my provider yet, registrieren Sie die angezeigten Werte und kehren Sie dann zu Supply the details zurück. SAML ohne Platzhalterwerte einrichten beschreibt diesen Ablauf.

Google veröffentlicht keine Metadaten-URL für eine benutzerdefinierte SAML-App. Laden Sie die Metadaten-Datei aus der Google Admin-Konsole herunter und fügen Sie ihren Inhalt in Supply the details auf der Bird-Verbindung ein. Wählen Sie dabei die Metadaten-Dokument-Option.

Die Feldnamen von Google stimmen nicht mit denen von Bird überein:

Signed response deaktivieren

Lassen Sie Signed response deaktiviert. Ist die Option aktiviert, signiert Google die Response und lässt die darin enthaltene Assertion unsigniert. Bird prüft die Signatur der Assertion selbst, sodass jede Anmeldung mit einem Signaturfehler abgelehnt wird, der wie ein Zertifikatsproblem aussieht. Durch Deaktivieren wird die Assertion wieder signiert und die Anmeldungen funktionieren.

Mitglieder anhand ihrer E-Mail-Adresse identifizieren

Setzen Sie Name ID format auf EMAIL. Googles andere Formate funktionieren nicht mit Bird:

• UNSPECIFIED wird direkt abgelehnt.
• PERSISTENT wird abgelehnt, weil das Format nicht mit dem übereinstimmt, das die Verbindung erwartet. Google sendet trotzdem die E-Mail-Adresse des Mitglieds als Wert, sodass es sich nicht um den opaken, nie wiedervergebenen Bezeichner handelt, den ein persistentes Format eigentlich liefern soll.

Google bietet keinen opaken Bezeichner für die NameID. Daher ist EMAIL hier die einzige verwendbare Wahl. Damit wird die Adresse für alle, die sich über diese Verbindung anmelden, dauerhaft: Wenn Ihre Organisation sie jemals neu vergibt, erbt die nächste Person das Bird-Konto. Lesen Sie Wie Mitglieder identifiziert werden, bevor Sie sich darauf verlassen.

Gültigkeit der Assertion und Zertifikate

Google signiert Assertions mit einer Gültigkeit von fünf Minuten vor bis fünf Minuten nach der Ausstellung. Bird akzeptiert das.

Google verwaltet das Signaturzertifikat und sein Ablaufdatum und bietet Ihnen bei einer benutzerdefinierten SAML-App keine Kontrolle über die Rotation. Notieren Sie sich das auf der Bird-Verbindung angezeigte Ablaufdatum und planen Sie, die Metadaten vorher zu ersetzen, denn am Tag des Ablaufs schlagen alle Anmeldungen über die Verbindung fehl.

OIDC

Beginnen Sie für OIDC in der Google Cloud Console. Bird benötigt Issuer, Client-ID und Client Secret, um eine OIDC-Verbindung zu erstellen. Registrieren Sie die Anwendung daher zuerst bei Google. Die Redirect URI von Bird ist für jede Verbindung gleich und wird in Add connection angezeigt, bevor Sie etwas erstellen, sodass Sie sie vorab registrieren können.

Erstellen Sie OAuth-Client-Credentials in der Google Cloud Console für das Projekt, das Ihre Workspace-Nutzer bedient, und kopieren Sie Client-ID und Secret in Bird mit https://accounts.google.com als Issuer. Bird liest das Discovery-Dokument von dort und authentifiziert sich am Token-Endpunkt mit client_secret_basic.

Registrieren Sie die Redirect URI von Bird als autorisierte Redirect-URI auf dem Client.

Googles OIDC-Pfad hat keinen App-Kachel-Schritt: Ein benutzerdefinierter OAuth-Client erscheint nicht im Google-Apps-Launcher. Mitglieder starten daher über die Anmeldeseite von Bird oder über einen Link, den Sie ihnen geben.

Nächste Schritte

• SSO und Provisioning: Domain verifizieren, Verbindung testen und SSO erzwingen
• SSO mit Okta einrichten
• SSO mit Microsoft Entra ID einrichten