1. À qui s'adresse ce guide
La plateforme Cyber Guru s'intègre avec tout fournisseur d'identité prenant en charge SAML 2.0. Pour Microsoft Entra ID et Google Workspace, il existe des guides dédiés avec des captures d'écran des consoles respectives :
Ce guide concerne tous les autres cas : Okta, Microsoft ADFS, Shibboleth, Oracle, ForgeRock, IBM, AWS, WSO2, PingFederate, ou une solution développée en interne.
Tu ne trouveras pas de captures d'écran : chaque console a sa propre interface, et les intitulés changent selon les versions. Tu trouveras en revanche tout ce que ton fournisseur d'identité doit faire et les valeurs exactes à échanger, afin que la personne qui connaît ton système puisse le configurer sans hésitation.
| 💡 | La configuration de ton fournisseur d'identité est à la charge de ton organisation, avec les ressources internes ou avec le support du fournisseur de la plateforme d'identité. Cyber Guru configure son propre côté et fournit toutes les valeurs nécessaires. |
2. Comment fonctionne l'intégration
Cyber Guru agit en tant que Service Provider (SP), ton système en tant que Identity Provider (IdP). Pour que le protocole fonctionne, les deux doivent disposer des composants SAML 2.0 et établir une relation de confiance mutuelle (le fameux circle of trust) via l'échange de métadonnées.
Le flux prévu est SP-initiated : l'utilisateur commence depuis l'adresse de la plateforme, est redirigé vers ton fournisseur d'identité pour s'authentifier, puis revient sur la plateforme avec une assertion SAML. (L'accès initié depuis le portail de l'IdP — IdP-initiated — est possible mais nécessite une configuration supplémentaire : voir Scénarios SSO avancés.)
3. Prérequis et décisions à prendre avant de commencer
| Élément | Qui le fournit | Remarques |
|---|---|---|
| Fournisseur d'identité compatible SAML 2.0 | Client | Aucun autre protocole n'est pris en charge. |
| Privilèges administratifs sur l'IdP | Client | Il faut pouvoir créer une nouvelle application/relying party et définir les attributs transmis. |
Champ à utiliser comme username
|
Client |
Décision la plus importante de la configuration. Il doit s'agir d'un attribut immuable : c'est la clé qui permet à la plateforme de reconnaître l'utilisateur et elle ne peut pas être modifiée une fois le projet lancé. Dans Active Directory, il s'agit généralement de l'ObjectGUID ; dans d'autres systèmes, un identifiant équivalent (par exemple un matricule). Évite l'email et l'UPN s'ils sont susceptibles de changer dans le temps. |
| Attributs obligatoires renseignés sur les profils | Client | Ils sont au nombre de quatre : username, email, firstName, lastName. |
| Organisations à transmettre | Client + Cyber Guru | Facultatif, sous la forme org_{NOM_ORG}. Utile si la société fonctionne sans préchargement ou si l'une d'elles doit être utilisée comme Team pour les statistiques et la gamification. |
| Métadonnées IdP | Client | URL publique accessible depuis Internet, ou fichier XML. |
| Politique d'accès à l'application | Client | Utilise un groupe dédié : seuls les utilisateurs autorisés à l'application pourront y accéder. |
| Mode de peuplement des utilisateurs | Client + Cyber Guru | Avec préchargement (recommandé) ou sans : voir Procédure générale SSO. |
| Comptes de test | Client | 2-3 comptes pour la recette, autorisés sur l'application. |
| Sous-domaine de la plateforme et métadonnées SP | Cyber Guru | Fournis après l'échange. |
4. Configuration étape par étape
Étape 1 — Crée l'application SAML sur ton fournisseur d'identité
Crée une nouvelle application (selon le système, cela peut s'appeler application, relying party trust, service provider, client) de type SAML 2.0. N'utilise pas de modèles de catalogue pour d'autres produits : il faut une intégration générique.
Étape 2 — Transmets les métadonnées IdP à Cyber Guru
Envoie à Cyber Guru l'URL publique des métadonnées de ton fournisseur d'identité (préférable) ou bien le fichier XML des métadonnées.
Les métadonnées doivent contenir : l'entityID de l'IdP, l'endpoint du Single Sign-On Service et le certificat public de signature.
| ⚠️ | Si ton fournisseur d'identité n'est accessible que depuis le réseau interne, les métadonnées doivent tout de même être exposées sur une URL publique ou transmises sous forme de fichier. Un endpoint non accessible depuis Internet ne peut pas être utilisé pour l'authentification des utilisateurs externes. |
Étape 3 — Reçois les métadonnées SP de Cyber Guru et configure l'application
Cyber Guru termine la configuration de son côté et t'envoie l'URL des métadonnées SP. Si ton système prend en charge l'import automatique des métadonnées, utilise-le : c'est la méthode la moins sujette aux erreurs. Sinon, ouvre l'URL dans un navigateur et récupère les valeurs depuis le fichier XML :
| Valeur à configurer | Où la trouver dans le fichier XML des métadonnées SP |
|---|---|
| Entity ID (audience / identifiant SP) | attribut entityID de l'élément racine <md:EntityDescriptor>
|
| ACS URL (Assertion Consumer Service, reply URL, destination) | attribut Location de l'élément <md:AssertionConsumerService> avec binding HTTP-POST |
| ⚠️ | Copie les valeurs depuis ton fichier de métadonnées, caractère par caractère. Ne les reconstitue pas à la main et ne les copie pas depuis d'autres guides ou des configurations d'autres organisations : l'adresse dépend de l'environnement où ta société est hébergée. |
Étape 4 — Exigences techniques de l'assertion
| Paramètre | Valeur requise |
|---|---|
| Version du protocole | SAML 2.0 |
| Binding de la réponse | HTTP-POST vers l'ACS URL |
| Signature | L'assertion (ou la réponse) doit être signée avec la clé privée de l'IdP ; le certificat public correspondant doit figurer dans les métadonnées transmises |
| Chiffrement de l'assertion | Non requis. Si ton IdP l'impose, signale-le avant la configuration |
| Format du Name ID | À définir selon l'indication reçue de Cyber Guru avec les métadonnées SP |
| Single Logout | Facultatif. Si ton IdP effectue le logout avec binding HTTP-POST, signale-le : cela nécessite une configuration supplémentaire côté Cyber Guru |
Étape 5 — Configure les attributs transmis
L'assertion doit contenir quatre attributs obligatoires, avec ces noms exacts :
| Nom de l'attribut | Contenu |
|---|---|
username |
L'identifiant immuable choisi dans les prérequis |
email |
Adresse email de l'utilisateur |
firstName |
Prénom |
lastName |
Nom |
Facultatifs : locale (code langue ISO à deux lettres minuscules), country (code pays ISO à deux lettres majuscules) et les organisations sous la forme org_{NOM_ORG}.
| 🛑 |
Deux règles valables pour tout fournisseur d'identité : 1. Les noms des attributs sont sensibles à la casse. firstName et lastName doivent être écrits exactement ainsi, en camelCase.2. Les noms ne doivent pas avoir de préfixes de namespace. De nombreux fournisseurs d'identité — ADFS et Microsoft Entra ID en particulier — transmettent les attributs avec un préfixe du type http://schemas.xmlsoap.org/ws/2005/05/identity/claims : ce préfixe doit être supprimé, sinon l'attribut ne sera pas reconnu. |
La référence complète sur les attributs — obligatoires, facultatifs, organisations et Team, fréquence de mise à jour — se trouve ici : Attributs Identity Provider SSO. Les attributs non présents dans cette liste doivent être validés au préalable avec Cyber Guru.
Voici un exemple de la partie attributs de l'assertion attendue :
<saml2:AttributeStatement>
<saml2:Attribute Name="username">
<saml2:AttributeValue>a1b2c3d4-0000-1111-2222-33445566778</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="email">
<saml2:AttributeValue>mario.rossi@esempio.it</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="firstName">
<saml2:AttributeValue>Mario</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="lastName">
<saml2:AttributeValue>Rossi</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>Étape 6 — Autorise les utilisateurs
Assigne à l'application le groupe contenant les utilisateurs autorisés. Quiconque n'est pas autorisé à l'application recevra une erreur lors de la connexion, même si tout le reste est correctement configuré. Pour la recette, n'autorise que les comptes de test.
Étape 7 — Documente la configuration
Conserve les valeurs saisies (Entity ID, ACS URL, noms des attributs, groupe autorisé) et le fichier de métadonnées : ils seront nécessaires lors du renouvellement du certificat.
5. Test et validation
- Vérifie que le compte de test est bien autorisé à l'application sur le fournisseur d'identité.
- Si la société est configurée avec préchargement, vérifie que ce même compte est déjà présent sur la plateforme avec un username identique à la valeur envoyée dans l'attribut
username. S'il n'est pas préchargé, l'accès sera refusé. - Ouvre une fenêtre de navigation privée/incognito dans ton navigateur.
- Va sur
https://<sous-domaine>.platform.cyberguru.euet clique sur le bouton de connexion SSO. - Authentifie-toi sur ton fournisseur d'identité : si tout fonctionne, tu arrives sur la page d'accueil Cyber Guru sans avoir à saisir d'autres identifiants.
- Vérifie sur la plateforme que le prénom, le nom et l'email sont corrects : s'ils sont vides ou incorrects, le problème vient des attributs transmis.
6. Si quelque chose ne fonctionne pas
Le premier outil à utiliser est un SAML tracer dans le navigateur : il permet de capturer la réponse SAML et de vérifier les noms exacts des attributs (casse comprise), l'absence de préfixes de namespace, la valeur de username et la présence des quatre attributs obligatoires.
Vérifie ensuite que l'Entity ID et l'ACS URL configurés correspondent caractère par caractère à ceux des métadonnées SP, et que l'utilisateur est bien autorisé à l'application.
Les messages d'erreur les plus courants, avec leur cause et leur solution, sont regroupés ici : FAQ SSO.
Si le problème persiste, contacte le support Cyber Guru en fournissant : le message d'erreur complet, l'heure de la tentative, le username de l'utilisateur concerné, le sous-domaine de la société et, si possible, les fichiers SamlRequest.xml et SamlResponse.xml.
7. Après la mise en production : maintenance
Après la configuration, les métadonnées doivent être considérées comme fixes. Si elles changent — renouvellement du certificat de signature, nouveaux endpoints, nouvelle application, remplacement du fournisseur d'identité — ne les modifie pas de ton côté : ouvre une demande auprès du support Cyber Guru, qui coordonnera la mise à jour des deux côtés. Il en va de même pour les changements d'email, d'UPN ou de domaine des utilisateurs, qui peuvent rompre l'association avec les comptes sur la plateforme.
Les procédures sont détaillées ici : Maintenance SSO : renouvellement du certificat et changement de username/email.