Dein Team mit SSO anmelden
Was du baust
Abschnitt betitelt „Was du baust“Am Ende dieses Tutorials hast du:
- eine SAML-Verbindung zwischen deinem Control Center-Server und einem Identitätsanbieter (als Beispiel nehmen wir Okta),
- einen Benutzer, der bei der ersten Anmeldung automatisch provisioniert wird, und
- eine Mitgliedschaftsrichtlinie für den Arbeitsbereich, die du bewusst gewählt hast.
Du brauchst einen Server, den du verwaltest (den Server-Eigentümer — den Betreiber der Installation), und eine IdP-Anwendung, die du konfigurieren kannst. Plane 20 Minuten ein.
1. Die Single-Sign-on-Einstellungen öffnen
Abschnitt betitelt „1. Die Single-Sign-on-Einstellungen öffnen“Melde dich bei Control Center an und öffne Einstellungen → Server → Single sign-on. Der Bildschirm wechselt zwischen SAML und OpenID Connect, dazu die Karte Benutzerbereitstellung (SCIM). Bleib bei SAML.
Alles auf diesem Bildschirm gilt serverweit: ein IdP authentifiziert die Menschen aller Arbeitsbereiche, deshalb darf nur der Server-Eigentümer ihn bearbeiten.
2. Die IdP-Metadaten einfügen
Abschnitt betitelt „2. Die IdP-Metadaten einfügen“Öffne in Okta den Tab Sign On deiner App und kopiere das Metadaten-XML (oder lade es herunter und füge den Dateiinhalt ein). Zurück in Control Center fügst du es in IdP-Metadaten-XML ein und klickst auf Verbindung testen.
Der Toast nennt den Anmelde-Endpunkt des IdP — der Beweis, dass die Metadaten
geparst wurden, das Zertifikat gelesen wurde und der Server daraus eine
Anmeldeanfrage bauen kann (der Test prüft alles bis auf den
Browser-Roundtrip). Schlägt er fehl, war das XML kein vollständiges
EntityDescriptor (der SAML-Tab in Okta nennt es “Metadata URL”; öffne die
URL und kopiere, was sie ausliefert). Dieselbe Schaltfläche unter OpenID
Connect prüft stattdessen das Discovery-Dokument deines Issuers. Ein
ablaufendes Zertifikat und die Frage, ob der IdP Control Center erkennt,
prüfst du mit der
Prüfung in Schritt 6.
3. Control Center beim IdP registrieren
Abschnitt betitelt „3. Control Center beim IdP registrieren“Klicke auf SP-Metadaten kopieren und gib sie der Person, die die Okta-Seite einrichtet (oder lies die beiden Werte ab, nach denen sie fragt):
- ACS URL:
https://<your-server>/saml/acs - Entity ID:
https://<your-server>/saml
Die URLs leiten sich von dem Origin ab, den die Browser deiner Benutzer erreichen. Läuft der Server hinter einem Tunnel oder einem Reverse-Proxy, muss dieser Origin stabil bleiben (Einstellungen → Server → Verbindung und Status → Diesen Server teilen zeigt die öffentliche URL) — oder du hältst die Entity-ID ausdrücklich im Feld SP-Entity-ID fest.
4. Festlegen, was eine Anmeldung gewährt
Abschnitt betitelt „4. Festlegen, was eine Anmeldung gewährt“Zwei Richtlinien entscheiden, was die erste Anmeldung bewirkt:
- Benutzer bei der ersten Anmeldung zu jedem Workspace hinzufügen — lass sie an, wenn ein einzelnes Team den Server nutzt und SSO dort Vertrauen bedeutet. Schalte sie aus, wenn sich mehrere Teams oder Kunden den Server teilen: jede neue Person braucht dann eine ausdrückliche Einladung in den Arbeitsbereich, und das ist die sicherere Vorgabe.
- Unbekannte Benutzer bei der ersten Anmeldung bereitstellen — standardmäßig an; schalte sie aus, um alle abzuweisen, deren Konto noch nicht existiert.
Optional ordnest du ein Attribut zu, das die Gruppennamen trägt (bei Okta ist
das üblicherweise groups), und übersetzt Gruppen mit der Zuordnung in
Rollen — zum Beispiel {"platform-leads": "admin"}. SSO kann die Rolle
Eigentümer nie vergeben.
5. Aktivieren und eine Anmeldung durchführen
Abschnitt betitelt „5. Aktivieren und eine Anmeldung durchführen“Schalte SAML für die Anmeldung verwenden ein, klicke auf Verbindung
speichern und öffne dann ein privates Browserfenster unter
https://<your-server>/saml/login. Melde dich bei Okta an, und du landest
wieder im Web-Client — angemeldet, das Konto angelegt und die Mitgliedschaft
nach der Richtlinie vergeben, die du gewählt hast.
Derselbe Einstieg erscheint auf dem Verbindungsbildschirm im Web (Mit SAML anmelden), sobald du die Serveradresse eintippst — das Formular richtet sich nach dem, was der Server anbietet (bei OpenID Connect steht Mit OpenID Connect anmelden). Die Schaltfläche öffnet die Anmeldung in einem neuen Tab; ist der Roundtrip abgeschlossen, übernimmt der wartende Tab die Sitzung von selbst. Der Einrichtungsbildschirm des Desktop-Servers macht dasselbe: tippe die Server-URL ein, dann erscheint Mit SAML anmelden, öffnet deinen Browser, und die App meldet dich an, sobald der Roundtrip durch ist.
6. Von dieser Seite prüfen
Abschnitt betitelt „6. Von dieser Seite prüfen“Bevor du SSO ausrollst oder eine Anmeldung scheitert, prüfst du die Teile hier. Die Prüfung läuft vollständig in deinem Browser: sie liest die Metadaten, die du in diesem Tab einfügst, und wendet dieselben Regeln an wie der Server. Mit deiner Serveradresse fragt sie diesen Server außerdem, ob die SAML-Anmeldung eingeschaltet ist.
Sie erkennt, was Verbindung testen in der App nicht sieht: ein Signaturzertifikat kurz vor dem Ablauf, einen IdP, der signierte Anfragen verlangt, und mit der Testanmeldung, ob der IdP Control Center überhaupt erkennt.
Runs in your browserYour metadata is read in this tab and never uploaded. Add a server address and your browser also asks that server which sign-in methods it offers.
Test sign-in at your IdP
- Your IdP's sign-in page: it recognizes Control Center's entity ID. You can close the tab.
- An error at your IdP: it names what to fix, usually an unknown entity ID (Entra: AADSTS700016) or a user not assigned to the app.
- Your server's "Sign-in failed" page: also a pass. The IdP accepted the request and posted back to your ACS URL; your server refuses it only because this page started the sign-in, not your server.
Nächste Schritte
Abschnitt betitelt „Nächste Schritte“- Gib deinem IdP auch die Kontrolle über den Lebenszyklus: Benutzer mit SCIM provisionieren und deprovisionieren.
- Dein IdP spricht OpenID Connect statt SAML? Einen OpenID Connect-Anbieter verbinden.
- Was prüft der Browser-Roundtrip eigentlich? Wie Single Sign-on funktioniert.