Configurer OpenID Connect et Okta pour le SSO Sophos Central

Sophos Central peut utiliser un fournisseur OpenID Connect pour un Single Sign-on initié par le SP. La connexion commence dans Sophos Central, qui redirige ensuite vers le fournisseur d’identité. Un simple lien vers le Dashboard lancé depuis l’IdP ne constitue donc pas un test fonctionnel valide.

Prérequis

Il faut disposer d’un Super Admin, d’un domaine vérifié dans Central, d’un administrateur de secours testé et d’un fournisseur OIDC qui accepte les Authorization Requests attendues par Sophos. Tous les comptes Central concernés doivent être associés à un domaine et à un seul fournisseur d’identité.

Central requiert quatre valeurs pour le fournisseur :

Champ	Signification
Client ID	identifiant public de l’application OIDC créée pour Sophos Central
Issuer	URL exacte de l’émetteur dont la valeur correspond au claim `iss` de l’ID Token
Authz endpoint	endpoint HTTPS pour l’Authorization Request
JWKS URL	endpoint HTTPS contenant les clés de signature publiques du fournisseur

La Callback URL est exactement https://federation.sophos.com/login/callback. Sophos demande alors openid profile email, response_type=id_token et response_mode=form_post. Le fournisseur doit renvoyer un ID Token. Sophos ne demande aucun Authorization Code dans ce processus.

Configurer l’application Okta

Dans l’Okta Admin Console, une application est créée sous Applications > Create App Integration :

Sélectionner OIDC – OpenID Connect, puis Single-Page Application.
Attribuer un nom unique tel que Sophos Central SSO.
Sous Grant type, désélectionner le Core Grant Authorization Code.
Sous Advanced > Other grants, activer Implicit (hybrid).
Pour Sign-in redirect URI, saisir https://federation.sophos.com/login/callback.
Supprimer les Sign-out redirect URIs existants.
Limiter d’abord l’affectation à un groupe pilote défini. Sophos présente comme exemple simple une autorisation accordée à tous les utilisateurs de l’organisation. Pour un déploiement sûr, un groupe pilote offre davantage de contrôle.
Enregistrer et noter le Client ID.

L’Okta Authorization Domain utilisée fournit l’Issuer. Avec un Custom Domain, il peut par exemple être https://login.example.com. On obtient alors généralement :

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

Les valeurs ne sont pas copiées depuis un exemple. Elles sont vérifiées par rapport à la configuration Discovery ou à celle du fournisseur du tenant Okta concerné. Un Issuer utilisant un autre Authorization Server peut comporter des chemins différents.

Créer le fournisseur dans Sophos Central

Ouvrir Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
Sélectionner Add identity provider, puis saisir un nom et une description.
Sélectionner Type: OpenID Connect et le Vendor correspondant, par exemple Okta.
Saisir exactement le Client ID, l’Issuer, l’Authz Endpoint et la JWKS URL.
Sélectionner le domaine vérifié. Plusieurs domaines sont possibles, mais un utilisateur reste associé à un seul domaine.
Sélectionner IdP enforced MFA uniquement si le fournisseur garantit la MFA pour toutes les identités concernées. Sinon, utiliser No IdP enforced MFA.
Enregistrer, ouvrir de nouveau le fournisseur et l’activer avec Turn on une fois la configuration terminée.

Pour Google Workspace, Sophos indique OIDC comme fournisseur possible, mais ne fournit pas de jeu de champs complet comparable dans le guide Central. Les valeurs sont donc reprises depuis la configuration OIDC Google ou Cloud Identity effectivement utilisée, puis validées lors du pilote. Les chemins Okta ne sont pas transposés à Google.

Mode de connexion et pilote

Sous Sophos sign-in, sélectionner d’abord le mode parallèle avec mot de passe Sophos et identifiants fédérés. Tester ensuite au minimum les cas suivants :

utilisateur pilote valide avec MFA de l’IdP,
utilisateur sans affectation à l’application,
domaine incorrect ou non vérifié,
session IdP expirée,
déconnexion et nouvelle connexion initiée par le SP,
second Super Admin utilisant la solution de repli.

Le passage à Federated credentials only n’est envisagé qu’après la réussite du pilote. L’affectation de l’application IdP à tous les utilisateurs ne remplace pas le contrôle de l’association de chaque compte Central au domaine et au fournisseur appropriés.

Dépannage

Invalid redirect ou boucle de connexion : contrôler le Callback, le type d’application et l’Implicit ID Token Flow.
Unknown issuer : le claim iss dans l’ID Token doit correspondre exactement au champ Central Issuer.
La signature ne peut pas être vérifiée : contrôler la JWKS URL, son accessibilité via HTTPS et la clé actuellement publiée.
L’utilisateur est introuvable : comparer le claim email, l’adresse e-mail Central et l’association au domaine.
Le fournisseur ne peut pas être activé : les champs obligatoires, le domaine ou le format de l’URL sont incomplets ou non valides.
La MFA est absente ou apparaît deux fois : contrôler conjointement la policy IdP et la sélection Central IdP enforced MFA.

Les Sign-in Rules, l’accès Break Glass, la récupération de la MFA et le changement de mode du tenant sont expliqués dans Sécuriser la connexion à Sophos Central avec la MFA, des passkeys et un IdP.

Questions fréquentes

Sophos Central prend-il en charge l’Authorization Code Flow ?

Le guide Sophos actuel décrit pour ce processus OIDC une Implicit Request avec response_type=id_token et sans Authorization Code demandé. L’application du fournisseur doit correspondre précisément à ce comportement documenté.

Le lien du Dashboard Okta peut-il être utilisé comme test ?

Non. Sophos Central utilise un processus initié par le SP. Le test commence sur la page de connexion Sophos afin de vérifier réellement le routage du domaine, la Request et le Callback.