SSO mit Okta einrichten

Diese Seite behandelt die Okta-Hälfte einer SSO-Verbindung. Die Bird-Hälfte (Domain verifizieren, testen, aktivieren und SSO erzwingen) ist bei jedem Anbieter gleich und steht unter SSO und Provisioning.

Okta und Bird benötigen jeweils Werte vom anderen. Wo Sie anfangen, hängt vom Protokoll ab. Halten Sie beide Seiten offen.

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 zu Supply the details zurück. SAML ohne Platzhalterwerte einrichten führt durch diesen Ablauf.

Oktas Feldnamen stimmen nicht mit denen von Bird überein. Zwei davon sind sich so ähnlich, dass sie leicht verwechselt werden. Eine Verwechslung schickt die Anmeldeantwort an eine URL, die sie nicht verarbeiten kann.

Oktas Single sign-on URL ist die Assertion Consumer Service URL von Bird, nicht die Anmelde-URL von Bird. Wenn Sie dort die Anmelde-URL einfügen, sendet Okta jede Antwort an den falschen Endpunkt und die Anmeldung schlägt fehl.

Mitglieder anhand ihrer E-Mail-Adresse identifizieren

Wählen Sie im Name ID format der SAML-App EmailAddress und setzen Sie Application username auf den Wert, den Bird als Schlüssel für jedes Konto verwenden soll. Bird lehnt Unspecified ab und lehnt eine Antwort ab, deren NameID-Format nicht mit dem von der Verbindung erwarteten Format übereinstimmt.

Lesen Sie Wie Mitglieder identifiziert werden, bevor Sie sich entscheiden: Der Bezeichner ist für alle, die sich über die Verbindung anmelden, dauerhaft. Deshalb ist ein opaker Application-Username, bei dem die Adresse separat als email-Attribut gesendet wird, die sicherere Wahl.

Gültigkeit der Assertion

Okta signiert Assertions mit einer Gültigkeit von fünf Minuten vor bis fünf Minuten nach dem Ausstellungszeitpunkt. Bird akzeptiert dieses Zeitfenster. Keine Konfiguration nötig.

OIDC

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

Erstellen Sie eine OIDC-Webanwendung in Okta und kopieren Sie deren Client-ID und Secret in Bird, mit Oktas Issuer als Issuer. Bird authentifiziert sich am Token-Endpunkt mit client_secret_basic.

Registrieren Sie die Redirect URI von Bird als Sign-in-Redirect-URI der App.

Oktas App-Kachel

Damit Mitglieder über ihr Okta-Dashboard starten können, setzen Sie:

• Login initiated by: Either Okta or App
• Application visibility: die Kachel, die Benutzern angezeigt wird
• Login flow: Redirect to app to initiate login (OIDC Compliant)
• Initiate login URI: die Initiate-Login-URI der Verbindung aus Bird

Wählen Sie den OIDC-konformen Flow. Oktas Send ID Token directly to app (Okta Simplified)-Flow sendet ein Token direkt an Bird statt umzuleiten, und Bird akzeptiert das nicht.

Anwendung zuweisen

Ein Mitglied, das der Bird-Anwendung in Okta nicht zugewiesen ist, wird von Okta abgelehnt, nicht von Bird. Bird meldet die Ablehnung als von Ihrem Identity Provider kommend. Prüfen Sie daher Zuweisungen und Conditional-Access-Richtlinien in Okta, bevor Sie die Verbindungseinstellungen selbst erneut prüfen.

Signaturzertifikat rotieren

Rotieren Sie zuerst in Okta, dann in Bird. Bird prüft gegen die Zertifikate, die in der Verbindung hinterlegt sind. Eine Bird-Verbindung, die nur das neue Zertifikat enthält, während Okta noch mit dem alten signiert, lehnt jede Anmeldung ab, bis Okta das neue aktiviert. Die Ablehnung ist ein Signaturfehler und verschwindet, sobald beide übereinstimmen.

Nächste Schritte

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