OpenID Connect und Okta für Sophos Fusion SSO konfigurieren

Sophos Fusion (ehemals Sophos Central) kann einen OpenID-Connect-Provider für SP-initiiertes Single Sign-on verwenden. Die Anmeldung beginnt bei Sophos Fusion und wird von dort zum Identity Provider weitergeleitet. Ein vom IdP gestarteter Dashboard-Link allein ist daher kein gültiger Funktionstest.

Voraussetzungen

Benötigt werden ein Super Admin, eine in Fusion verifizierte Domain, ein getesteter Rückfall-Admin und ein OIDC-Provider, der die von Sophos erwarteten Authorization Requests akzeptiert. Alle betroffenen Fusion-Konten müssen einer Domain und genau einem Identity Provider zugeordnet sein.

Die Domain wird vor dem Provider eingerichtet:

Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in > Verify domains öffnen.
Unter Federated domains mit Add domain die eigene Domain erfassen. example.com steht hier nur für die Domain des eigenen Unternehmens und muss ersetzt werden.
Den angezeigten TXT-Record mit Copy übernehmen, im öffentlichen DNS publizieren und die Propagation abwarten. Sophos nennt dafür bis zu 24 Stunden.
In Fusion bei der Domain Verify domain ownership und danach Verify wählen. Der Status muss die Domain mit Verifizierungsdatum zeigen.

Die Verifizierung gilt ein Jahr und kann innerhalb dieses Jahres erneuert werden. Der Ablauf gehört deshalb in die Betriebsplanung; eine heute funktionierende Föderation ersetzt die spätere Re-Verifizierung nicht.

Fusion benötigt vier Providerwerte:

Feld	Bedeutung
Client ID	öffentliche Kennung der für Sophos Fusion erstellten OIDC-Anwendung
Issuer	exakte Aussteller-URL, deren Wert mit dem `iss`-Claim des ID Tokens übereinstimmt
Authz endpoint	HTTPS-Endpunkt für die Authorization Request
JWKS URL	HTTPS-Endpunkt mit den öffentlichen Signaturschlüsseln des Providers

Die Callback URL lautet exakt https://federation.sophos.com/login/callback. Sophos fordert dabei openid profile email, response_type=id_token und response_mode=form_post an. Der Provider muss einen ID Token liefern; Sophos fordert in diesem Ablauf keinen Authorization Code an.

Okta-App einrichten

In der Okta Admin Console wird unter Applications > Create App Integration eine Anwendung angelegt:

OIDC – OpenID Connect und danach Single-Page Application auswählen.
Einen eindeutigen Namen wie Sophos Fusion SSO vergeben.
Unter Grant type den Core Grant Authorization Code abwählen.
Unter Advanced > Other grants Implicit (hybrid) aktivieren.
Als Sign-in redirect URI https://federation.sophos.com/login/callback eintragen.
Vorhandene Sign-out redirect URIs entfernen.
Die Zuweisung zunächst auf eine definierte Pilotgruppe beschränken. Sophos zeigt als einfaches Beispiel eine Freigabe an alle Organisationsbenutzer; für einen sicheren Rollout ist eine Pilotgruppe kontrollierbarer.
Speichern und die Client ID notieren.

Den Issuer liefert die verwendete Okta Authorization Domain. Bei einer Custom Domain sieht das beispielsweise wie https://login.example.com aus. Daraus ergeben sich normalerweise:

Issuer:         https://login.example.com
Authz endpoint: https://login.example.com/oauth2/v1/authorize
JWKS URL:       https://login.example.com/oauth2/v1/keys

Die Werte werden nicht aus einem Beispiel kopiert, sondern gegen die Discovery- beziehungsweise Provider-Konfiguration des eigenen Okta-Tenants geprüft. Ein Issuer mit anderem Authorization Server kann abweichende Pfade enthalten.

Provider in Sophos Fusion anlegen

Global Settings > Access Control > Sign-in and Identity > Federated identity providers öffnen.
Add identity provider wählen und Name sowie Beschreibung erfassen.
Type: Open ID Connect und den passenden Vendor, beispielsweise Okta, wählen.
Client ID, Issuer, Authz Endpoint und JWKS URL exakt eintragen.
Die verifizierte Domain auswählen. Mehrere Domains sind möglich, ein Benutzer bleibt aber genau einer Domain zugeordnet.
IdP enforced MFA nur wählen, wenn der Provider MFA für alle betroffenen Identitäten garantiert. Mit No IdP enforced MFA erzwingt Fusion nach erfolgreicher IdP-Authentisierung eine eigene MFA-Prüfung.
Speichern, Provider erneut öffnen und nach vollständiger Konfiguration mit Turn on aktivieren.

Für Google Workspace nennt Sophos OIDC als möglichen Provider, liefert in der Fusion-Anleitung aber keinen vergleichbaren vollständigen Feldsatz. Deshalb werden die Werte aus der tatsächlich verwendeten Google- beziehungsweise Cloud-Identity-OIDC-Konfiguration übernommen und im Pilot validiert. Okta-Pfade werden nicht auf Google übertragen.

Unter Global Settings > Access Control > Sign-in and Identity > Sophos sign-in wird zuerst Sophos Central Admin or Federated credentials gewählt. Nach dem Speichern kontrolliert der ausführende Admin, dass Fusion ihn automatisch in eine Custom Sign-in Rule mit Sophos-Login aufgenommen hat. Diese Regel ist ein zusätzlicher Rückweg, ersetzt aber nicht den separat getesteten zweiten Super Admin.

Der positive Test beginnt in einer privaten Browser-Sitzung auf der Sophos-Anmeldeseite unter https://fusion.sophos.com. Nach Eingabe der Pilot-E-Mail muss der Browser zu Okta wechseln, dort die vorgesehene MFA verlangen und danach das Sophos-Fusion-Dashboard mit der erwarteten Rolle öffnen. Anschliessend werden mindestens diese Fälle getestet:

gültiger Pilotbenutzer mit IdP-MFA,
Benutzer ohne App-Zuweisung,
falsche oder nicht verifizierte Domain,
abgelaufene IdP-Sitzung,
Sign-out und erneute SP-initiierte Anmeldung,
zweiter Super Admin über den Rückfallweg.

Erst nach erfolgreichem Pilot wird Federated credentials only erwogen. Eine IdP-App-Zuweisung an alle Benutzer ersetzt nicht die Kontrolle, ob jedes Fusion-Konto der richtigen Domain und dem Provider zugeordnet ist.

Troubleshooting

Invalid redirect oder Login-Schleife: Callback, Anwendungstyp und Implicit-ID-Token-Flow prüfen.
Unknown issuer: iss im ID Token muss exakt zum Fusion-Feld Issuer passen.
Signatur kann nicht geprüft werden: JWKS URL, HTTPS-Erreichbarkeit und aktuell publizierten Key kontrollieren.
Benutzer wird nicht gefunden: email-Claim, Fusion-E-Mail und Domainzuordnung vergleichen.
Provider lässt sich nicht einschalten: Pflichtfelder, Domain und URL-Format sind unvollständig oder ungültig.
MFA fehlt oder erscheint doppelt: IdP-Policy und Fusion-Auswahl IdP enforced MFA gemeinsam prüfen.

Sicher deaktivieren oder zurückrollen

Vor Wartungsarbeiten am OIDC-Provider wird unter Sophos sign-in auf Sophos Central Admin or Federated credentials zurückgeschaltet. Zwei Super Admins testen danach ihren Sophos-Zugang in privaten Browser-Sitzungen. Für die vollständige Rückkehr zu Sophos Central Admin email and password setzen Benutzer ohne nutzbares Sophos-Passwort dieses über Reset Password neu.

Erst nach diesen Tests werden der Fusion-Provider ausgeschaltet oder die IdP-App-Zuweisungen entzogen. Domain, Providerwerte, IdP-App und Custom Sign-in Rule bleiben erhalten, bis Anmeldung, Rollen und Self Service Portal über den Rückweg bestätigt sind. Schlägt der Rückweg fehl, bleibt der OIDC-Provider aktiv und die vorherige Sign-in-Einstellung wird wiederhergestellt.

Sign-in Rules, Break-Glass-Zugang, MFA-Recovery und die Umschaltung des Tenant-Modus erklärt Sophos-Fusion-Anmeldung mit MFA, Passkeys und IdP absichern.

Häufige Fragen

Unterstützt Sophos Fusion den Authorization Code Flow?

Die aktuelle Sophos-Anleitung beschreibt für diesen OIDC-Ablauf einen Implicit Request mit response_type=id_token und ohne angeforderten Authorization Code. Die Provider-App muss genau zu diesem dokumentierten Verhalten passen.

Kann der Okta-Dashboard-Link als Test verwendet werden?

Nein. Sophos Fusion verwendet einen SP-initiierten Ablauf. Der Test startet auf der Sophos-Anmeldeseite, damit Domainrouting, Request und Callback tatsächlich geprüft werden.