Aller au contenu
Avanet

Configurer OpenID Connect et Okta pour le SSO Sophos Fusion

Sophos Fusion (anciennement Sophos Central) peut utiliser un fournisseur OpenID Connect pour un Single Sign-on initié par le SP. La connexion commence dans Sophos Fusion, 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 Fusion, d’un administrateur de secours testé et d’un fournisseur OIDC qui accepte les Authorization Requests attendues par Sophos. Tous les comptes Fusion concernés doivent être associés à un domaine et à un seul fournisseur d’identité.

Le domaine est configuré avant le fournisseur :

  1. Ouvrir Global Settings > Access Control > Sign-in and Identity > Sophos Sign-in > Verify domains.
  2. Sous Federated domains, sélectionner Add domain et saisir le domaine de l’entreprise. example.com n’est qu’un exemple et doit être remplacé.
  3. Utiliser Copy pour récupérer l’enregistrement TXT affiché, le publier dans le DNS public et attendre sa propagation. Sophos indique que celle-ci peut prendre jusqu’à 24 heures.
  4. Dans Fusion, sélectionner Verify domain ownership pour le domaine, puis Verify. Le statut doit afficher le domaine avec une date de vérification.

La vérification est valable un an et peut être renouvelée pendant cette période. Son échéance doit être intégrée au suivi opérationnel : une fédération fonctionnelle aujourd’hui n’élimine pas la future revérification.

Fusion requiert quatre valeurs pour le fournisseur :

ChampSignification
Client IDidentifiant public de l’application OIDC créée pour Sophos Fusion
IssuerURL exacte de l’émetteur dont la valeur correspond au claim iss de l’ID Token
Authz endpointendpoint HTTPS pour l’Authorization Request
JWKS URLendpoint 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 :

  1. Sélectionner OIDC – OpenID Connect, puis Single-Page Application.
  2. Attribuer un nom unique tel que Sophos Fusion SSO.
  3. Sous Grant type, désélectionner le Core Grant Authorization Code.
  4. Sous Advanced > Other grants, activer Implicit (hybrid).
  5. Pour Sign-in redirect URI, saisir https://federation.sophos.com/login/callback.
  6. Supprimer les Sign-out redirect URIs existants.
  7. 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.
  8. 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 Fusion

  1. Ouvrir Global Settings > Access Control > Sign-in and Identity > Federated identity providers.
  2. Sélectionner Add identity provider, puis saisir un nom et une description.
  3. Sélectionner Type: Open ID Connect et le Vendor correspondant, par exemple Okta.
  4. Saisir exactement le Client ID, l’Issuer, l’Authz Endpoint et la JWKS URL.
  5. Sélectionner le domaine vérifié. Plusieurs domaines sont possibles, mais un utilisateur reste associé à un seul domaine.
  6. Sélectionner IdP enforced MFA uniquement si le fournisseur garantit la MFA pour toutes les identités concernées. Avec No IdP enforced MFA, Fusion impose sa propre vérification MFA après l’authentification réussie par l’IdP.
  7. 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 Fusion. 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 Global Settings > Access Control > Sign-in and Identity > Sophos sign-in, sélectionner d’abord Sophos Central Admin or Federated credentials. Après l’enregistrement, l’administrateur qui effectue la modification vérifie que Fusion l’a automatiquement ajouté à une Custom Sign-in Rule avec connexion Sophos. Cette règle constitue un recours supplémentaire, mais ne remplace pas un second Super Admin testé séparément.

Le test positif commence sur https://fusion.sophos.com dans une session de navigation privée. Après la saisie de l’adresse e-mail pilote, le navigateur doit rediriger vers Okta, y demander la MFA prévue, puis ouvrir le Dashboard Sophos Fusion avec le rôle attendu. 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 Fusion 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 Fusion 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 Fusion 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 Fusion IdP enforced MFA.

Désactiver ou revenir en arrière en toute sécurité

Avant toute maintenance du fournisseur OIDC, rétablir Sophos Central Admin or Federated credentials sous Sophos sign-in. Deux Super Admins testent ensuite leur accès Sophos dans des sessions de navigation privée. Pour revenir entièrement à Sophos Central Admin email and password, les utilisateurs sans mot de passe Sophos utilisable en définissent un nouveau avec Reset Password.

Le fournisseur Fusion n’est désactivé, ou les affectations de l’application IdP retirées, qu’après ces tests. Conserver le domaine, les valeurs du fournisseur, l’application IdP et la Custom Sign-in Rule jusqu’à la validation de la connexion, des rôles et du Self Service Portal par le parcours de repli. Si celui-ci échoue, laisser le fournisseur OIDC actif et restaurer le réglage de connexion précédent.

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 Fusion avec la MFA, des passkeys et un IdP.

Questions fréquentes

Sophos Fusion 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 Fusion 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.