La configuration standard prévoit un fournisseur d'identité (Identity Provider) par entreprise. Cependant, la plateforme Cyber Guru prend en charge certains scénarios plus complexes. Si vous vous reconnaissez dans l’un de ces cas, signalez-le à Cyber Guru avant de commencer la configuration : la séquence des étapes sera différente.
1. Deux tenants Entra ID (ou deux domaines d’authentification) pour la même entreprise
Quand c’est nécessaire : l’organisation dispose de deux tenants Microsoft Entra ID distincts — généralement après une fusion ou en présence d’une filiale — mais souhaite n’avoir qu’une seule entreprise Cyber Guru, avec des rapports et une gamification unifiés.
Comment ça fonctionne : l’entreprise reste unique ; deux connexions SSO sont configurées et la page de connexion affiche deux boutons d’accès, un pour chaque tenant. Chaque utilisateur utilise celui de son organisation.
Ce dont nous avons besoin :
- les métadonnées IdP de chacun des tenants (une application SAML pour chaque, configurée comme dans le guide standard) ;
- l’indication de quels utilisateurs appartiennent à quel tenant.
Attention : les utilisateurs doivent être enregistrés sur l’IdP avec le bon domaine. Un utilisateur présent sur le mauvais tenant, ou avec un domaine email non aligné, ne pourra pas se connecter.
2. Second fournisseur d’identité sur la même entreprise
Quand c’est nécessaire : coexistence temporaire de deux systèmes d’identité (par exemple lors d’une migration d’ADFS vers Entra ID), ou populations gérées par des IdP différents.
Comment ça fonctionne : Cyber Guru configure une seconde connexion SAML sur la même entreprise. Un second URL de métadonnées SP, différent du premier, vous sera fourni, à utiliser pour configurer l’application sur le second IdP.
| ⚠️ | Pour chaque IdP, utilisez exactement l’URL de métadonnées SP qui vous est indiqué pour cette connexion. Réutiliser celui de la première connexion est l’erreur classique dans ce scénario et entraîne un échec d’authentification difficile à diagnostiquer. |
Note sur les migrations : si un même utilisateur doit passer d’un IdP à l’autre, le lien avec l’ancienne identité doit être supprimé par Cyber Guru. Prévoyez le plan de migration à l’avance : voir Maintenance SSO.
3. Accès IdP-initiated (depuis le portail du fournisseur d’identité)
Quand c’est nécessaire : vous souhaitez que les utilisateurs accèdent à Cyber Guru en cliquant sur une icône dans le portail d’applications de l’IdP (le panneau d’apps de Google Workspace, le My Apps de Microsoft), sans passer par l’adresse de la plateforme.
Comment ça fonctionne : il s’agit d’un scénario techniquement différent de la connexion lancée depuis la plateforme (SP-initiated) et qui nécessite un endpoint ACS dédié, différent de celui utilisé dans la configuration standard. Cyber Guru vous le fournira sur demande.
Que faire : ouvrez un ticket auprès du support.
4. Plusieurs entreprises Cyber Guru sur le même tenant IdP
Quand c’est nécessaire : l’organisation dispose de plusieurs entreprises Cyber Guru distinctes (par exemple une pour le parcours standard et une pour un parcours NIS2, ou encore une par filiale du groupe) mais d’un seul tenant IdP.
Comment ça fonctionne : chaque entreprise a son propre URL de métadonnées SP. Sur l’IdP, il faut généralement des applications SAML distinctes, une par entreprise, chacune avec son propre groupe d’utilisateurs autorisés.
Attention : un utilisateur qui doit accéder à deux entreprises doit être affecté aux deux applications. Vérifiez bien la correspondance entre groupes et entreprises : il est facile d’assigner la population à la mauvaise application.
5. Classifications organisationnelles multiples
Vous pouvez transmettre toutes les classifications dont vous avez besoin sous forme d’organisations, au format org_{NOM_ORG} : site, département, unité organisationnelle, division, etc. Sur la plateforme, elles deviennent des filtres pour les tableaux de bord et les rapports, et l’une d’elles peut être désignée comme Équipe pour la gamification. Voir Attributs Identity Provider SSO.
6. Attributs très spécifiques ou provisioning automatique
Si vous avez besoin d’importer dans la plateforme des attributs qui ne relèvent pas du modèle des organisations (matricule, numéro fiscal, crédits de formation) ou de synchroniser automatiquement le cycle de vie des utilisateurs — création, mise à jour, désactivation — le SSO n’est pas l’outil adapté : SAML ne transmet les informations qu’au moment de la connexion et n’indique pas à la plateforme qu’un utilisateur a été désactivé.
Dans ces cas, il faut envisager le provisionnement via SCIM 2.0 ou l’utilisation des API, en complément du SSO pour l’authentification. En l’absence de SCIM, les modalités de déprovisionnement doivent être définies avec Cyber Guru. Ce choix doit être fait avant la mise en production, car il conditionne la façon dont les utilisateurs sont ajoutés.
7. Single Logout (SLO)
Certaines solutions d’Identity Provider gèrent la déconnexion d’une manière qui n’est pas prévue par la configuration par défaut. Si, après la déconnexion de la plateforme, vous constatez des erreurs ou des sessions qui restent ouvertes, signalez-le : il s’agit d’une modification de configuration côté Cyber Guru, et non d’une intervention sur votre IdP.