Chaque identifiant distinct, c’est un mot de passe de plus à réinitialiser et un compte de plus à fermer quand quelqu’un s’en va. L’authentification unique (SSO) SAML relie votre plateforme de formation (LMS) à votre fournisseur d’identité : les personnes se connectent à leurs formations avec leur compte professionnel, et les accès suivent votre annuaire. Voici comment fonctionne SAML, comment se déroule la configuration avec Microsoft Entra ID, Okta ou Google Workspace, et ce qu’il faut vérifier avant la mise en production.
Comment fonctionne l’authentification unique SAML
SAML (Security Assertion Markup Language) 2.0 est une norme ouverte pour échanger des informations de connexion entre deux systèmes qui se font confiance. Le LMS ne voit jamais le mot de passe de la personne : il l’envoie vers votre fournisseur d’identité, qui vérifie son identité, avec l’authentification multifacteur que vous exigez le cas échéant, puis la renvoie avec une déclaration signée.
| Terme | Ce que cela signifie |
|---|---|
| Fournisseur d’identité (IdP) | Le système qui authentifie vos collaborateurs, comme Entra ID, Okta ou Google Workspace. |
| Fournisseur de services (SP) | L’application à laquelle les personnes se connectent : votre LMS. |
| Assertion | La déclaration XML signée émise par l’IdP : qui est la personne, quand elle s’est connectée, et des attributs tels que l’e-mail et le nom. |
| Entity ID | Un nom unique pour chaque partie, souvent en forme d’URL mais qui n’est qu’un identifiant. Il doit correspondre exactement. |
| ACS URL | L’URL de l’Assertion Consumer Service : l’adresse du LMS qui reçoit la réponse de l’IdP. |
| Certificat de signature | L’IdP signe avec sa clé privée ; le LMS vérifie avec le certificat public de l’IdP et rejette les assertions falsifiées ou modifiées. |
| Métadonnées | Un fichier XML regroupant un entity ID, des points de terminaison et des certificats, prêt à être importé. |
Les assertions ont une durée de vie courte et désignent leur destinataire (l’entity ID du SP). Le SP rejette tout ce qui a expiré ou qui est destiné à une autre application.
Pourquoi l’authentification unique vaut la peine pour un LMS
- Pas de mots de passe supplémentaires. Les personnes utilisent leur compte de tous les jours, et votre MFA et vos politiques d’accès couvrent aussi la formation.
- Les arrivants accèdent rapidement à la plateforme. Affectez l’application LMS à un groupe, et les nouveaux collaborateurs qui en font partie peuvent se connecter dès le premier jour.
- Les partants perdent l’accès à la source. Désactivez quelqu’un dans votre annuaire et il ne peut plus ouvrir de nouvelle session LMS. SAML contrôle la connexion, pas le compte : archivez donc aussi le compte LMS dans le cadre du processus de départ.
Création de comptes juste-à-temps
Avec le provisionnement juste-à-temps (JIT), le LMS crée un compte la première fois que quelqu’un se connecte, à partir des attributs de l’assertion : aucune liste d’utilisateurs à importer. Encadrez-le par des garde-fous :
- Limitez-le à vos propres domaines d’e-mail, pour qu’une application mal configurée ou un compte invité ne crée pas d’utilisateurs parasites.
- Donnez aux nouveaux comptes le rôle le plus restreint, et accordez les droits d’administrateur de façon délibérée.
- Identifiez les personnes à partir d’un identifiant stable lorsque votre IdP peut en envoyer un, car les adresses e-mail changent.
Connexion initiée par le SP ou par l’IdP
- Initiée par le SP : la personne ouvre le LMS, qui envoie une demande d’authentification à l’IdP, et l’IdP transmet sa réponse à l’ACS URL. Cela fonctionne depuis des favoris et des liens dans des e-mails, et ce flux est généralement considéré comme plus sûr, car la réponse correspond à une demande émise par le LMS.
- Initiée par l’IdP : la personne clique sur la vignette de l’application dans Microsoft My Apps, dans son tableau de bord Okta ou dans le menu des applications Google, et l’IdP envoie une réponse non sollicitée à l’ACS URL.
Vous pouvez proposer les deux ; testez chacune.
Configurer l’authentification unique SAML, pas à pas
La séquence est à peu près la même partout :
- Définir le périmètre : qui utilise l’authentification unique, quels groupes reçoivent l’application, quels domaines d’e-mail sont autorisés, et quel attribut identifie chaque personne.
- Créer la connexion dans le LMS et noter son entity ID et son ACS URL.
- Créer une application SAML chez votre IdP avec ces valeurs, choisir le format de NameID et ajouter les attributs e-mail, prénom et nom.
- Affecter des utilisateurs ou des groupes ; les personnes non affectées sont généralement refusées.
- Fournir au LMS les informations de l’IdP : une URL de métadonnées, un fichier de métadonnées, ou l’entity ID de l’IdP, l’URL de connexion et le certificat de signature.
- Faire correspondre les attributs avec les noms que votre IdP envoie réellement.
- Tester, puis activer, et informer les personnes de ce qui change.
Remarques selon le fournisseur
La documentation de votre fournisseur détaille les écrans exacts. À savoir :
- Microsoft Entra ID : utilisez une application d’entreprise hors galerie, et non une inscription d’application, qui ne propose pas SAML. Les noms de revendications (claims) sont de longs URI : copiez-les exactement. L’ID d’objet fait un bon identifiant stable. Pour les personnes sans boîte aux lettres, la revendication d’e-mail peut être vide ; le nom d’utilisateur principal (UPN) peut la remplacer s’il s’agit d’une vraie adresse.
- Okta : créez une intégration d’application SAML 2.0. Vous nommez vous-même les déclarations d’attributs : elles doivent donc correspondre exactement à la correspondance du LMS, y compris la casse. Son ID utilisateur interne constitue un identifiant stable.
- Google Workspace : ajoutez une application SAML personnalisée et téléchargez son fichier de métadonnées. L’application est désactivée au départ : activez-la pour les bonnes unités d’organisation ou les bons groupes. Une configuration courante identifie les personnes par leur adresse e-mail principale ; prévoyez donc le cas des adresses renommées et réutilisées.
Liste de contrôle des tests
Avant la mise en production, vérifiez ces points dans une fenêtre de navigation privée :
- Un utilisateur existant se connecte en partant du LMS, puis de nouveau depuis la vignette de l’application.
- Un nouvel utilisateur de votre domaine obtient un compte avec le bon rôle.
- Une personne non affectée à l’application est refusée.
- Une personne extérieure à vos domaines autorisés est refusée.
- L’e-mail, le prénom et le nom arrivent correctement.
- Un administrateur peut toujours entrer par la voie de secours.
Pièges fréquents
Décalage d’horloge
Si les horloges de l’IdP et du LMS diffèrent de plus que ce que le LMS tolère, des assertions valides sont rejetées comme pas encore valides ou déjà expirées. Cela touche surtout les serveurs d’identité auto-hébergés : gardez donc leurs horloges synchronisées.
Renouvellement de certificat
Les certificats de signature de l’IdP expirent, et si le LMS ne fait pas confiance au certificat de remplacement, toutes les connexions échouent d’un coup. Notez la date d’expiration dans votre agenda. Si votre LMS peut faire confiance à deux certificats, ajoutez d’abord le nouveau côté LMS, puis activez-le chez l’IdP ; sinon, basculez les deux côtés ensemble à un moment calme. Testez immédiatement.
Correspondance des attributs
Les noms d’attributs sont généralement comparés à l’identique : un LMS qui attend email n’acceptera pas Email. Vérifiez aussi l’identifiant. Un NameID transitoire change à chaque session et une adresse e-mail peut changer ; un NameID persistant ou un attribut d’identifiant immuable est stable. Si les personnes sont identifiées par leur e-mail, archivez le compte d’un partant avant que son adresse ne soit réattribuée.
Domaines d’e-mail non concordants
Les annuaires comptent souvent des personnes dont le nom de connexion n’est pas leur adresse e-mail, des prestataires sur d’autres domaines, et des collaborateurs d’entreprises rachetées qui utilisent encore les anciens. Si le LMS limite les comptes à certains domaines, ils sont refusés. Dressez la liste de tous les domaines avant la mise en production.
Comment Acadenix procède
L’authentification unique SAML est incluse dans l’offre Gold, avec des guides pas à pas pour Entra ID, Okta et Google Workspace.
- Tester, puis activer. Vous enregistrez les informations de votre IdP en brouillon, lancez Test configuration (tester la configuration) en vous connectant chez votre fournisseur, et vous ne l’activez qu’ensuite. Une revendication d’e-mail manquante est signalée avec les noms de revendications que votre fournisseur a bien envoyés.
- Modifications par étapes. Un nouveau certificat ou un nouveau tenant est ajouté sous forme de mise à jour de configuration, et la configuration actuelle continue de fonctionner jusqu’à ce que vous l’activiez.
- JIT dans vos domaines. Une personne sans compte obtient un compte apprenant à sa première connexion, uniquement si son e-mail appartient aux domaines d’inscription de votre organisation, et vous pouvez désactiver ce comportement. Lorsqu’une personne qui possède déjà un compte Acadenix se connecte pour la première fois via votre IdP, Acadenix lui envoie par e-mail un code à usage unique pour confirmer le lien. Cela n’arrive qu’une fois par personne.
- Deux portes d’entrée. Les personnes partent de votre page de connexion, qui peut les conduire directement à votre IdP ou afficher un bouton, ou de la vignette dans My Apps, Okta ou Google.
- Une connexion, une organisation. Une connexion SAML ne se transmet pas aux organisations situées sous son propriétaire, ce qui compte pour les groupes comptant de nombreux sites.
- Une voie de secours. Si votre IdP est indisponible, les administrateurs peuvent toujours se connecter avec un code à usage unique envoyé par e-mail, et cette voie ne peut pas être désactivée.
En plus de SAML, les personnes peuvent se connecter avec un code envoyé par e-mail ou avec un compte Google, Microsoft ou LinkedIn. Plus de détails sur notre page Sécurité.
À retenir
- Échangez les entity ID, l’ACS URL et les métadonnées, puis faites correspondre un identifiant stable et un e-mail vérifié.
- Limitez les comptes juste-à-temps à vos propres domaines et au rôle le plus restreint.
- Testez les deux flux de connexion, les refus et la voie de secours avant la mise en production.
- Notez dans votre agenda l’expiration des certificats et archivez les comptes LMS des partants.
Envie de connecter Acadenix à votre fournisseur d’identité ? Comparez les offres sur notre page Tarifs, ou parlez-en avec nous à propos de votre configuration.
