SSO und Bereitstellung

Single Sign-on (SSO) ermöglicht Mitgliedern, sich über Ihren Identity Provider bei Bird anzumelden, statt ein separates Bird-Passwort zu verwenden. Bird unterstützt SAML 2.0- und OpenID Connect (OIDC)-Verbindungen.

Die Einrichtung ist Aufgabe eines Organisation-Owners, und die Steuerungselemente befinden sich auf der Single-Sign-on-Seite Ihrer Organisation. Ein Mitglied mit der SSO-Berechtigung kann Verbindungen verwalten, ohne Owner zu sein.

Die persönliche Anmeldung über Google oder GitHub ist von der SSO-Konfiguration der Organisation getrennt. Siehe Login, Passwort & MFA.

Wie SSO funktioniert

Eine SSO-Verbindung deckt eine oder mehrere verifizierte E-Mail-Domains ab, zum Beispiel yourcompany.com. Mitglieder auf diesen Domains authentifizieren sich über Ihren Identity Provider. Ihre Bird-Berechtigungen ergeben sich weiterhin aus ihren Organisations- und Workspace-Rollen.

Was die Einrichtung umfasst

Ein Organisation-Owner und ein Identity-Provider-Administrator führen die Einrichtung gemeinsam durch:

1. Bestätigen Sie den Besitz der Domain. Bird stellt Ihnen einen DNS-Eintrag bereit, den Sie für jede von der Verbindung abgedeckte E-Mail-Domain veröffentlichen. Die Erzwingung kann erst aktiviert werden, wenn die Domain verifiziert ist.
2. Konfigurieren Sie die Verbindung. Geben Sie für SAML die Identity-Provider-Metadaten oder die Anmelde-URL und die Signaturzertifikate an. Geben Sie für OIDC den Issuer und die Client-Credentials an. Kopieren Sie die Service-Provider- oder Redirect-Details von Bird in Ihren Identity Provider.
3. Testen Sie die Verbindung. Führen Sie eine Testanmeldung durch, bevor Sie die Verbindung aktivieren. Unabhängig vom gewählten Protokoll wird ein Entwurf, dessen Test bestanden ist, automatisch aktiviert, sofern Ihre Organisation eine verifizierte Domain hat und das Limit aktiver Verbindungen nicht überschritten ist.
4. Entscheiden Sie, ob SSO verpflichtend sein soll. Wenn SSO optional ist, können Mitglieder SSO oder eine andere verfügbare Anmeldemethode verwenden. Wenn SSO verpflichtend ist, müssen Mitglieder SSO durchlaufen, um auf die Organisation zuzugreifen. Die Erzwingung von SSO erfordert eine aktive Verbindung und mindestens eine verifizierte Domain.

Die SSO-Pflicht greift sofort bei jeder Anfrage und nicht erst bei der nächsten Anmeldung. Ein Mitglied, dessen aktuelle Sitzung nicht über Ihren Identity Provider aufgebaut wurde, verliert den Zugriff auf die Organisation, bis es sich erneut über diesen anmeldet. Planen Sie die Umstellung daher passend zum Arbeitsalltag Ihres Teams, statt sie nachträglich anzukündigen. Organisation-Owner sind die Ausnahme: Ein Owner behält den Zugriff mit seinem Bird-Passwort, was verhindert, dass eine fehlerhafte Verbindung alle aussperrt.

Ihren Identity Provider einrichten

Schritt 2 ist die Hälfte, die sich je nach Provider unterscheidet: Derselbe Wert hat in jedem Provider einen anderen Namen, und jeder hat eine Einstellung, die bei falschem Wert jede Anmeldung ablehnt. Die Feldnamen von Bird finden Sie auf der Verbindungsseite unter Register these with your identity provider.

• SSO mit Okta einrichten
• SSO mit Google Workspace einrichten
• SSO mit Microsoft Entra ID einrichten

Für jeden anderen SAML 2.0- oder OpenID Connect-Provider sind die vier obigen Schritte die gesamte Vereinbarung.

SAML ohne Platzhalterwerte einrichten

Entity ID und Assertion Consumer Service URL einer SAML-Verbindung werden aus der Verbindung selbst abgeleitet und existieren daher erst, wenn Sie sie erstellen. Das ergibt einen Zirkel: Ihr Identity Provider braucht diese Werte, und sie benötigen die Verbindung.

Erstellen Sie zuerst die Verbindung. Wählen Sie in Add connection SAML und dann I have not set up my provider yet. Die Verbindung wird als Entwurf ohne Identity-Provider-Details erstellt, und beim Öffnen werden die zu registrierenden Werte unter Register these with your identity provider angezeigt. Konfigurieren Sie Ihren Provider mit diesen Werten, kehren Sie dann zurück und verwenden Sie Supply the details bei derselben Verbindung, in der Form, die Ihnen vorliegt:

• eine Metadaten-URL, die wir abrufen und auslesen
• das Metadaten-Dokument selbst, für Provider, die eine Datei bereitstellen, statt sie zu hosten
• die Entity ID, Anmelde-URL und Signaturzertifikate, direkt eingegeben

Ein hochgeladenes Dokument wird für diese drei Werte ausgelesen und nicht gespeichert.

Bis die Details eingehen, bleibt die Verbindung ein Entwurf: Sie verarbeitet keine Anmeldungen und kann nicht aktiviert werden.

Wie Mitglieder identifiziert werden

Eine SAML-Verbindung identifiziert jedes Mitglied anhand der NameID, die Ihr Provider sendet, und dieser Bezeichner ist für jede Person, die sich anmeldet, permanent. Beim Einrichten der Verbindung werden Sie nicht nach dem gewünschten Format gefragt. Wenn Sie eine Metadaten-URL oder ein Dokument angegeben haben, lesen wir aus, was Ihr Provider dort bekanntgibt, und ordnen die Verbindung diesem Wert zu. Wenn Sie die Details manuell eingegeben haben, gibt es keine Metadaten zum Auslesen, und die Verbindung wird einer permanenten ID zugeordnet.

Was Sie steuern können, ist der Wert dahinter. Setzen Sie den Anwendungsbenutzernamen bei Ihrem Provider auf einen opaken, nie wiederverwendeten Wert und senden Sie die Adresse separat als email-Attribut. Eine E-Mail-Adresse als Bezeichner ist dauerhaft schwächer: Wird die Adresse jemals neu vergeben, erbt die nächste Person damit das Bird-Konto.

Metadaten beschreiben, was Ihr Provider senden kann; die Anwendungskonfiguration legt fest, was er tatsächlich sendet, und beides kann voneinander abweichen. Deshalb meldet die Testanmeldung in Schritt 3 den Bezeichner und das Format, die die Assertion tatsächlich enthielt, und dieser Bericht dient Ihnen zur Prüfung, ob beides übereinstimmt, bevor jemand auf die Verbindung angewiesen ist. Wir lehnen zudem einen als persistent bezeichneten Bezeichner ab, der in Wirklichkeit eine E-Mail-Adresse ist.

Wenn der Test ein unerwartetes Format meldet, haben Sie zwei Korrekturmöglichkeiten, und welche richtig ist, hängt davon ab, was falsch ist:

• Der Provider sendet den falschen Wert. Ändern Sie den Anwendungsbenutzernamen bei Ihrem Provider und testen Sie erneut. Das ist in der Regel die richtige Lösung, weil der opake Bezeichner der wertvolle ist.
• Die Verbindung ist dem falschen Wert zugeordnet. Öffnen Sie Edit bei der Verbindung und ändern Sie das NameID-Format auf das, was Ihr Provider sendet.

Führen Sie eine der beiden Korrekturen durch, bevor sich Mitglieder anmelden. Sobald sie es getan haben, sind ihre Konten mit dem geltenden Bezeichner verknüpft, das Format ist damit festgelegt und die Änderung wird abgelehnt. Erstellen Sie stattdessen eine Verbindung für das neue Format.

Einen Provider ersetzen

Die Identity-Provider-Details einer SAML-Verbindung können ersetzt werden, solange sich noch niemand darüber angemeldet hat. Sobald Mitglieder die Verbindung genutzt haben, sind ihre Konten mit den Bezeichnern Ihres aktuellen Providers verknüpft, und ein Austausch wird abgelehnt. Erstellen Sie stattdessen eine Verbindung für den neuen Provider. Bei einer OIDC-Verbindung können Sie das Client Secret jederzeit rotieren, was die Identifizierung der Mitglieder nicht ändert, aber der Provider selbst kann nicht ersetzt werden.

Die Testanmeldung in Schritt 3 zählt nicht. Ein Test verknüpft kein Konto und gewährt keinen Zugriff, sodass eine Verbindung, die Sie eingerichtet und getestet, aber noch nicht an Ihr Team weitergegeben haben, weiterhin umkonfiguriert werden kann.

Was sich für Ihr Team ändert

Eine Verbindung kann einem Mitglied bei der ersten erfolgreichen SSO-Anmeldung standardmäßigen Organisations- und Workspace-Zugriff gewähren. Konfigurieren Sie diesen Standardzugriff explizit; andernfalls laden Sie Mitglieder ein und weisen Sie Rollen zu, bevor diese sich anmelden. Siehe Benutzer, Teams & Rollen.

Das Aussetzen einer Verbindung verhindert neue Anmeldungen darüber. Prüfen Sie Bird-Mitgliedschaften und aktive Sitzungen separat, wenn jemand Ihr Unternehmen verlässt.

Nächste Schritte

• Login, Passwort & MFA: individuelle Kontosicherheit, einschließlich persönlicher Google-/GitHub-Anmeldung
• Benutzer, Teams & Rollen: wie Rollen und Berechtigungen funktionieren, sobald Mitglieder aufgenommen sind
• Authentifizierung & API-Schlüssel: die Authentifizierungsreferenz für Entwickler