Über einen zentralen Identity Provider anmelden

Diese Seite richtet sich an Administratoren, die die Anmeldung an Workspace über einen zentralen OpenID-Connect-Provider (OIDC) ermöglichen möchten. Der Provider bestätigt, wer sich anmeldet. Welche Mandanten und Funktionen die Person nutzen darf, entscheidet weiterhin die jeweilige Workspace-Installation.

Die Capability ist standardmäßig ausgeschaltet. Nur der System-Mandant kann sie für einen einzelnen Zielmandanten freischalten. Die Einrichtung allein aktiviert keine weiteren Mandanten und ist keine Freigabe für einen Produktivbetrieb.

Eine Mitarbeiterin kann etwa in einer Installation normale Benutzerin und in einer zweiten Mandantenadministratorin sein. Die zentrale Anmeldung gibt ihr keine Mitgliedschaft in weiteren Kundenmandanten.

Wenn stattdessen andere Anwendungen ihre Benutzer über Workspace anmelden sollen, lesen Sie Workspace als Identity Provider.

Freischaltung und Voraussetzungen

Der System-Mandant schaltet auth.upstream_oidc_login für jeden gewünschten Mandanten einzeln frei. Die Capability ist standardmäßig aus. Ein normaler Mandantenadministrator kann sie nicht selbst freischalten; der System-Mandant selbst bleibt bei lokaler Anmeldung. identity_provider.sso ist eine andere Capability und ersetzt diese Freischaltung nicht.

Planen Sie vor der Einrichtung:

  • Eine aktive, verifizierte HTTPS-Domain für die Administrationsoberfläche des Zielmandanten. Registrieren Sie beim Provider die daraus abgeleitete, verbindungsspezifische Rücksprungadresse exakt.
  • Einen Provider mit dem unterstützten Profil für Workspace, Microsoft Entra oder Google sowie eine eigene Client-Registrierung.
  • Ein im Secret Store des Mandanten hinterlegtes Client-Secret, sofern das Providerprofil eines benötigt. Geben Sie Secrets nicht in Tickets oder Agentenprompts weiter.
  • Eine vom Betreiber erlaubte ausgehende HTTPS-Verbindung zum Provider. Regeln für andere Integrationen öffnen diesen Zugriff nicht automatisch.
  • Einen geprüften lokalen Notfallzugang mit den erforderlichen Rechten und einem vom Provider unabhängigen zweiten Faktor.

Beginnen Sie die Anmeldung auf der kanonischen Administrationsdomain des Zielmandanten. Weitere Domains desselben Mandanten sind keine alternativen Rücksprungadressen. Ändert sich die kanonische Domain oder entfällt ihre aktive Verifikation, können begonnene Anmeldungen nicht abgeschlossen werden. Aktualisieren Sie zuerst die Providerregistrierung und beginnen Sie dann eine neue Anmeldung. Die globale Serveradresse ersetzt die Mandantendomain nicht.

Verbindung und Zulassungsregeln verwalten

Öffnen Sie im Zielmandanten Anmeldung > OIDC-Verbindungen. Zum Anzeigen benötigen Sie federation_connections:list und federation_connections:read. Erstellen, Ändern und Löschen verlangen die jeweils passenden Scopes federation_connections:create, federation_connections:update und federation_connections:delete.

Wählen Sie das Providerprofil und pflegen Sie Name, Issuer, Client-ID, Secret-Referenz, Aktivierungsstatus und die Sitzungsdauer. Das API-Feld sessionLifetimeSeconds verwendet standardmäßig acht Stunden und darf das Installationsmaximum von 24 Stunden nicht überschreiten. Workspace leitet Callback-, Frontchannel-Logout- und Backchannel-Logout-URI aus der verifizierten Administrationsdomain ab. Diese Felder sind schreibgeschützt.

Öffnen Sie danach Anmeldung > Zulassungsregeln. Zum Anzeigen benötigen Sie federation_policies:list und federation_policies:read; Änderungen verwenden die entsprechenden Scopes mit create, update oder delete. Jede Regel bindet eine Verbindung, eine Organisation und die Entscheidung allow oder deny. includeDescendants bezieht Unterorganisationen ausdrücklich ein. Eine optionale kürzere sessionLifetimeSeconds verkürzt nur Sitzungen in diesem Geltungsbereich.

Die Verbindung ist gespeichert, wenn die Liste sie nach einem Neuladen mit dem gewählten Status zeigt und die abgeleiteten Endpunkte unverändert bleiben. Die Einrichtung ist fachlich geprüft, wenn ein ausdrücklich zugeordnetes Testkonto die Anmeldung abschließt, im richtigen Mandanten landet und nur die lokal vergebenen Rollen und Organisationen sieht. Prüfen Sie zusätzlich eine abgewiesene Regel und einen Mandanten ohne Capability-Freischaltung.

Zwei Workspace-Installationen verbinden

Die Einrichtung benötigt berechtigte Administratoren auf beiden Seiten. Der Quellmandant betreibt den Identity Provider; der Zielmandant verwendet ihn für die Anmeldung. Beide können auf unterschiedlichen Installationen liegen. Die folgenden Schritte sind ein manueller Ablauf, keine automatische Kopplung der beiden Systeme.

Der Quell-Issuer lautet https://<Quellhost>/api/v1/idp/oidc/tenants/<Quellmandanten-ID>. Verwenden Sie den exakt veröffentlichten Wert aus der Discovery des Quellmandanten.

  1. Prüfen Sie die getrennten Freischaltungen: identity_provider.sso an der Quelle und auth.upstream_oidc_login am Ziel. Legen Sie Quellmandant, Zielmandant, exakten Issuer, Client-ID und einen festen Anwendungsschlüssel für die Registrierung an der Quelle fest.
  2. Speichern Sie am Ziel zunächst eine inaktive Verbindung mit diesem Issuer und dieser Client-ID. Lesen Sie anschließend ihre serverseitig abgeleitete Rücksprungadresse ab. Erfinden oder bearbeiten Sie diese Adresse nicht.
  3. Registrieren Sie an der Quelle den OIDC-Client unter dem vereinbarten Anwendungsschlüssel mit genau dieser Client-ID und Rücksprungadresse. Prüfen Sie außerdem Quellmitgliedschaft und Anwendungszulassung der vorgesehenen Benutzer. Die Zielverbindung erteilt diese Rechte nicht.
  4. Erzeugen Sie das Client-Secret an der Quelle einmal und übergeben Sie es über einen dafür vorgesehenen sicheren Kanal. Hinterlegen Sie es im Secret Store des Zielmandanten und ordnen Sie der Verbindung dessen Referenz zu. Das Quellsystem gibt das Secret später nicht erneut im Klartext aus.
  5. Vergleichen Sie Mandanten, Issuer, Client-ID und Rücksprungadresse auf beiden Seiten. Aktivieren Sie die Zielverbindung erst danach und prüfen Sie mit einem ausdrücklich zugeordneten Testkonto die Anmeldung und lokalen Rechte.

Statusabfragen erzeugen oder rotieren kein Secret. Verwenden Sie bei einer wiederholten Client-Konfiguration denselben Anwendungsschlüssel. Ist die Secret-Zustellung unklar, deaktivieren Sie die Zielverbindung und führen Sie eine kontrollierte Rotation mit erneuter Übergabe durch. Planen Sie dabei eine Unterbrechung ein; es gibt keine zugesicherte parallele Gültigkeit zweier Secrets. Eine erfolgreiche Speicherung auf einer Seite bestätigt nicht automatisch die Konfiguration der anderen Installation.

Personen und Zugriffsrechte zuordnen

Eine externe Identität wird durch die Kombination aus Aussteller (issuer) und Benutzerkennung (subject) zugeordnet. Gleiche E-Mail-Adressen verbinden keine Konten. Auch Rollen oder Gruppen aus dem Provider erzeugen keine lokalen Administrationsrechte.

Legen Sie für eine neue OIDC-Einladung zuerst die Person im Zielmandanten an. Die Einladung bindet diese Person ausdrücklich an eine Providerverbindung und gegebenenfalls an eine Organisation desselben Mandanten. Bestehende Passworteinladungen bleiben Passworteinladungen. Ein erneuter Einladungsversand ändert nicht stillschweigend den verifizierten Kontakt eines bestehenden Kontos.

Eine bereits vorhandene Identität erhält keine zweite Identität durch eine E-Mail-Suche. Das Verknüpfen eines zusätzlichen Providerkontos verlangt einen frischen Nachweis des bisherigen Kontozugangs und anschließend die Anmeldung beim neuen Provider. Ein bestehendes Browserfenster mit angemeldeter Sitzung reicht als Nachweis allein nicht aus.

Organisationsregeln gelten zunächst nur für die ausgewählte Organisation. Unterorganisationen sind nur bei ausdrücklich gewählter Teilbaumregel einbezogen. Die nächstgelegene Regel entscheidet; ohne passende Erlaubnis ist der Zugriff gesperrt. Eine individuelle Freigabe hebt eine maßgebliche Organisationssperre nicht auf. Die Hierarchie erzeugt keine Mitgliedschaft in anderen Mandanten.

Nach dem erfolgreichen Provider-Nachweis ermittelt Workspace die zulässigen lokalen Kontexte neu. Gibt es genau einen Kontext, wird er automatisch verwendet. Bei mehreren zulässigen Kontexten wählen Sie ausdrücklich zwischen dem persönlichen Zugriff und den angebotenen Organisationen. Vor der Erstellung der Sitzung prüft Workspace Mitgliedschaft und nächstgelegene Regel erneut. Organisationsdaten werden vor dem Provider-Nachweis nicht angezeigt.

Browser, nucli und lokales Passwort

Die Browseranmeldung bietet die für den Zielmandanten verfügbaren Verbindungen an. Ein gegebenenfalls erforderlicher lokaler zweiter Faktor bleibt wirksam. Bei einem Mandantenwechsel werden Mitgliedschaft und Berechtigung im Ziel erneut geprüft.

nucli login nutzt die Browseranmeldung, wenn der Server sie als Standard anbietet. Mit nucli login --local wählen Sie ausdrücklich den lokalen Passwortweg. Bei älteren Servern bleibt die bisherige Anmeldung erhalten. Weitere Optionen stehen unter nucli.

Für ein bisher rein föderiertes Konto ist das Einrichten eines lokalen Passworts ein eigener Vorgang: erneute Anmeldung über die bestehende Verknüpfung, erforderlicher lokaler zweiter Faktor und ein zusätzlicher Bestätigungscode an den gespeicherten verifizierten Kontakt. Eine bereits für einen Passwortzugang belegte E-Mail-Adresse kann diesen optionalen Schritt verhindern. Sie verhindert nicht allein die OIDC-Anmeldung oder eine personengebundene OIDC-Einladung.

Der Vorgang übernimmt keine fremden Zugangsdaten und senkt keinen zweiten Faktor. Er meldet Sie auch nicht automatisch lokal an. Die bisherige Passwortwiederherstellung bleibt an einen vorhandenen lokalen Passwortzugang gebunden. In einer impersonierten Sitzung ist keine Passwortänderung erlaubt.

Ausfall, Sperrung und Prüfung

Prüfen Sie den lokalen Notfallzugang, bevor Sie sich auf den zentralen Provider verlassen. Ein Provider-Ausfall soll die lokale Anmeldung nicht verhindern. Entfernen Sie diesen Zugang nicht im Zuge der Einrichtung.

Wird eine Verbindung, Freischaltung oder maßgebliche Zugriffsregel widerrufen, dürfen daraus stammende Sitzungen nicht durch Verlängerung oder einen Mandantenwechsel wieder Zugang erhalten. Vom Provider ausgelöste Abmeldungen hängen von dessen unterstütztem Logout-Vertrag ab; insbesondere ist keine sofortige globale Abmeldung über Google zugesichert.

Prüfen Sie vor einem produktiven Einsatz mindestens die Anmeldung im Browser und mit nucli, unterschiedliche lokale Rollen, eine ausgeschlossene Unterorganisation, einen nicht freigeschalteten Kundenmandanten und den lokalen Zugang bei nicht erreichbarem Provider. Eine erfolgreiche Anmeldung allein belegt noch nicht die richtige Rechtevergabe.

Nächste Schritte