L'authentification unique (SSO) permet aux utilisateurs de se connecter à DiliTrust avec leur compte d'entreprise, via le service de connexion de leur entreprise. Ce service s'appelle le fournisseur d'identité (IdP). DiliTrust utilise la norme SAML pour le SSO, et la connexion démarre toujours depuis DiliTrust (on parle de connexion « initiée par le fournisseur de services »).
Ce guide explique comment configurer le SSO SAML pour un nouveau client dans la Gestion d'entités juridiques (LEM) et les Instances digitalisées (BP), et ce que voient les utilisateurs une fois la configuration faite.
✋ Qui peut faire quoi
- La personne qui configure le SSO recueille les informations du client, remplit la configuration SAML et transmet les métadonnées DiliTrust au client.
- L'équipe informatique du client fournit les informations du fournisseur d'identité et, pour ADFS, vérifie les paramètres de signature.
- Les utilisateurs (administrateurs et membres du conseil) se connectent ensuite par SSO de la même façon.
✍ Personne qui configure le SSO : recueillir les informations
Il vous faut quatre informations du fournisseur d'identité du client :
- EntityID
- certificat(s) X509
- URL de connexion
- nom(s) de domaine autorisé(s)
Option 1 : importer le fichier de métadonnées (le plus simple)
- Demandez au client son fichier metadata.xml.
- Importez-le sur la page des paramètres du client SAML. L'EntityID, le ou les certificats X509 et l'URL de connexion sont remplis automatiquement si le fichier les contient.
- S'il manque des informations dans le fichier, demandez-les au client.
L'import d'un nouveau fichier XML remplace tous les paramètres client existants.
Option 2 : saisir les informations à la main
Ouvrez le fichier metadata.xml du client et repérez :
- l'EntityID dans le nœud EntityDescriptor ;
- le ou les certificats X509 dans le nœud X509Certificate. Il peut y en avoir plusieurs : incluez-les tous ;
- l'URL de connexion dans le nœud SingleSignOnService.
Les numéros de ligne varient d'un fichier à l'autre : cherchez toujours les noms des nœuds.
✅ Personne qui configure le SSO : remplir la configuration SAML
Ouvrez la page de configuration du client SAML.
- Cochez Activer SAML pour l'intégration SSO.
- Choisissez comment les utilisateurs se connectent :
- Connexion entièrement SAML (recommandée) : les utilisateurs se connectent uniquement par SAML. Cochez Obliger tous les utilisateurs à se connecter via SAML.
- Connexion partiellement SAML : les utilisateurs peuvent encore se connecter avec leur e-mail et leur mot de passe au niveau du centre de données.
- Vérifiez les méthodes d'authentification. Six sont prises en charge par défaut : Password, Password Protection Transport, TLS Client, X.509, Integrated Windows et Kerberos. Pour d'autres méthodes, consultez le support de formation sur les méthodes d'authentification non standard.
- Laissez le protocole strict activé (il l'est par défaut). Il vérifie les informations du fournisseur d'identité avant de les traiter, pour plus de sécurité.
- Dans Paramètres du Client, saisissez ou vérifiez l'Entity ID, l'URL de connexion de l'IdP, le ou les certificats X509 et le ou les noms de domaine exclusifs, séparés par des virgules.
- Cliquez sur Enregistrer. Les métadonnées propres au client sont générées.
- Copiez ces métadonnées et envoyez-les au client pour qu'il valide et teste la connexion.
⚖️ Équipe informatique du client : étape supplémentaire pour ADFS
Si le client utilise Windows Active Directory Federation Services (ADFS), le message et l'assertion doivent tous deux être signés. Sur le serveur ADFS, exécutez :
Get-AdfsRelyingPartyTrust -Identifier <A_DILITRUST_APP_IDENTIFIER>
Si SamlResponseSignature n'a pas la valeur MessageAndAssertion, exécutez :
Set-AdfsRelyingPartyTrust -TargetIdentifier "<A_DILITRUST_APP_IDENTIFIER>" -SamlResponseSignature "MessageAndAssertion"
Identifiants d'application DiliTrust valides : dilitrust_gov_eu, dilitrust_gov_na, dilitrust_exec_eu, dilitrust_exec_na, dilitrust_dataroom_prod_eu, dilitrust_dataroom_prod_na.
☝ Utilisateurs : première connexion et création du mot de passe
Sauf si la connexion SAML est obligatoire, les utilisateurs doivent quand même créer un mot de passe DiliTrust à l'activation de leur compte. C'est normal et cette étape ne peut pas être évitée aujourd'hui, même si leur domaine e-mail figure dans les noms de domaine exclusifs.
Si un utilisateur saisit son adresse e-mail sur https://auth.dilitrust.com/, il reçoit un e-mail de création de mot de passe. Le lien ouvre la page de création de mot de passe DiliTrust et ne redirige jamais vers le fournisseur d'identité.
⌚ Utilisateurs : ouvrir le lien d'une réunion depuis un e-mail de notification
Les e-mails de notification des Instances digitalisées peuvent contenir un lien vers une réunion. Avec le SSO activé :
- Le lien ouvre la page de connexion DiliTrust. Le lien n'identifie pas l'utilisateur : il saisit donc une fois son adresse e-mail.
- La suite dépend du réglage :
- Connexion SAML obligatoire (Obliger tous les utilisateurs à se connecter via SAML est coché) : l'utilisateur est envoyé directement vers son fournisseur d'identité. Ceux qui essaient de se connecter avec un mot de passe y sont aussi envoyés.
- Connexion SAML facultative (l'option n'est pas cochée) : l'utilisateur n'est pas envoyé vers le fournisseur d'identité. Il saisit son mot de passe DiliTrust, plus l'authentification à deux facteurs si elle est configurée.
- Après connexion, l'utilisateur arrive directement sur la réunion, dans les deux cas.
À savoir
- La redirection vers le fournisseur d'identité n'a lieu que si la connexion SAML est obligatoire.
- La connexion SAML obligatoire s'applique à tout le compte de l'utilisateur. S'il appartient à plusieurs clients, elle s'applique dès qu'un seul d'entre eux l'impose.
- Certains utilisateurs n'arrivent pas tout de suite sur la réunion : ceux qui ont des conditions d'utilisation à accepter voient d'abord cette page, les utilisateurs du support arrivent sur le tableau de bord du support, et les utilisateurs membres d'aucun groupe ne sont pas redirigés vers la réunion.
- Un lien de réunion valide contient l'identifiant de la réunion et celui du groupe : /fr/redirection_email/meeting/{meeting_id}/{group_id}. Sans l'identifiant du groupe, l'utilisateur voit une erreur « page introuvable » (404).
❗ Limites et dépannage
- Une configuration SAML de groupe ne peut pas utiliser le même domaine e-mail que la configuration client. Chaque domaine e-mail ne peut exister qu'une fois par configuration.
- Si le client rencontre des problèmes de connexion pendant les tests, surtout avec des fournisseurs d'identité Microsoft utilisant une authentification biométrique ou matérielle, consultez le support de formation sur les méthodes non standard. Confirmez toujours avec l'équipe R&D avant d'activer des options non standard.
❓ Questions fréquentes
Pourquoi les utilisateurs SSO doivent-ils créer un mot de passe ?
Sauf si la connexion SAML est obligatoire, la création du mot de passe fait partie de l'activation du compte et ne peut pas être évitée aujourd'hui.
Pourquoi un lien de réunion affiche-t-il une erreur 404 ?
Il manque l'identifiant du groupe dans le lien. Un lien valide contient l'identifiant de la réunion et celui du groupe.
Cet article a-t-il été utile ?
C'est super !
Merci pour votre commentaire
Désolé ! Nous n'avons pas pu vous être utile
Merci pour votre commentaire
Commentaires envoyés
Nous apprécions vos efforts et nous allons corriger l'article