SAML v2 Single Sign-On (SSO)

⚙️ Premiers Pas

Quelle est notre solution SSO et comment fonctionne-t-elle ?

Notre solution SSO est initiée par le fournisseur de services (SP), ce qui signifie que le processus de connexion commence depuis notre application et redirige les utilisateurs vers le fournisseur d’identité (IdP) de leur organisation pour l’authentification.

Où puis-je trouver les supports de formation ?

Des vidéos et supports de formation sont disponibles sur notre page de formation interne. Ressources supplémentaires :

• Présentation de formation sur la connexion forcée
• Formation sur les méthodes d’authentification non standard
• Documentation générale sur le SSO SAML v2

✍ Exigences de Configuration

Quelles informations dois-je obtenir du client pour configurer le SSO ?

Vous avez besoin de quatre éléments provenant du fournisseur d’identité (IdP) du client :

• EntityID : identifiant unique de l’IdP
• Certificat(s) X509 : certificats de sécurité (peuvent être multiples)
• URL de connexion : point de terminaison d’authentification de l’IdP
• Nom(s) de domaine : domaines email utilisant exclusivement le SSO

Comment obtenir ces informations du client ?

Deux méthodes :

Méthode 1 : Importation du fichier metadata.xml

• Demandez le fichier metadata.xml au client
• Importez-le directement dans notre formulaire de configuration
• Le système remplit automatiquement l’EntityID, les certificats X509 et l’URL de connexion, si présents

Méthode 2 : Extraction manuelle

• Demandez le fichier metadata.xml au client
• Extrait les informations nécessaires :
  • EntityID : dans le nœud EntityDescriptor
  • Certificats X509 : dans les nœuds X509Certificate
  • URL de connexion : dans le nœud SingleSignOnService

À quoi faut-il faire attention lors de l’importation de fichiers XML ?

• Chaque importation XML écrase les paramètres client précédents
• Le fichier XML peut ne pas contenir toutes les informations requises
• Recherchez les nœuds XML, pas les numéros de ligne
• Extraire **tous** les certificats X509 s’ils sont multiples

⛅ Paramètres de Configuration

Quelles sont les deux principales options de flux de connexion ?

1. SSO SAML exclusif (le plus sécurisé – recommandé)

   • Cochez « Forcer tous les utilisateurs à se connecter via SAML »
   • Toute l’authentification passe par l’IdP

2. Implémentation SAML partielle

   • Authentification via SAML possible au niveau du serveur de connexion
   • Connexion alternative email/mot de passe disponible

Quelles méthodes d’authentification sont prises en charge ?

Notre implémentation SSO prend en charge 6 méthodes par défaut :

• Mot de passe
• Transport protégé par mot de passe
• Client TLS
• X.509
• Windows intégré
• Kerberos

Qu’est-ce que « Utiliser le protocole strict » et dois-je l’activer ?

Le protocole strict renforce la sécurité en validant les informations de l’IdP avant traitement. Il est activé par défaut et recommandé, bien qu’il nécessite une configuration et des tests supplémentaires côté client.

Comment gérer plusieurs domaines ?

Si le client a plusieurs domaines nécessitant un accès SSO exclusif, sépare-les par des virgules dans le champ de domaine.

⚓ Restrictions de Domaine et Email

Puis-je utiliser le même domaine email pour des configurations de groupe et de client ?

Non. Une configuration SAML pour un groupe ne peut pas partager le même domaine email qu’une configuration client. Chaque domaine email ne peut être utilisé que dans une seule instance de configuration.

✈️ Configuration Spécifique à Microsoft ADFS

Quelles considérations spéciales pour les clients Microsoft ADFS ?

Pour les services ADFS de Windows, les clients doivent s’assurer que le message et l’assertion sont configurés pour être signés. Ils doivent :

• Configurer l’application sur le serveur ADFS
• Ouvrir PowerShell sur le serveur ADFS
• Vérifier avec `Get-AdfsRelyingPartyTrust` ou avec l’identifiant :

Get-AdfsRelyingPartyTrust -Identifier 

• Vérifier que `SamlResponseSignature` = `MessageAndAssertion`
• Sinon, mettre à jour avec :

Set-AdfsRelyingPartyTrust -TargetIdentifier "" -SamlResponseSignature "MessageAndAssertion"

Quels sont les identifiants d’application Dilitrust valides pour ADFS ?

• dilitrustgoveu
• dilitrustgovna
• dilitrustexeceu
• dilitrustexecna
• dilitrustdataroomprod_eu
• dilitrustdataroomprod_na

⚡ Dépannage

Le client ne peut pas se connecter après la configuration – que vérifier ?

Cela arrive souvent avec les IdP Microsoft, surtout avec :

• Authentification biométrique
• Clés d’authentification matérielles
• Système d’exploitation Windows

Étapes de résolution :

• Consultez les supports formation sur méthodes d’authentification non standard
• Envisagez d’activer les méthodes non standard
• Important : confirmer avec le service R&D avant activation

Que se passe-t-il après avoir enregistré la configuration ?

L’enregistrement génère des métadonnées spécifiques pour ce client. Chaque client a des métadonnées uniques, même si les configurations semblent similaires. Copiez ces métadonnées et transmettez-les au client pour leur configuration IdP.

Le client dit que certaines informations manquent dans son fichier metadata.xml – que faire ?

Contactez directement le client pour obtenir les informations manquantes. Leur fichier XML peut ne pas contenir toutes les données nécessaires à la configuration client.

☕ Bonnes Pratiques

Quelle est l’approche de sécurité recommandée ?

• Utiliser exclusivement SAML à l’échelle du système (connexion SAML forcée)
• Garder le protocole strict activé
• S’assurer de la validation correcte des certificats
• Vérifier que les restrictions de domaine sont bien configurées

Comment gérer les certificats ?

• Toujours extraire et utiliser **tous** les certificats X509 s’ils sont multiples
• Vérifier que les certificats sont valides et non expirés
• S’assurer que les certificats correspondent entre l’IdP du client et notre configuration

Que faut-il retenir sur les métadonnées ?

• Chaque client a des métadonnées uniques, même avec des configurations similaires
• Toujours fournir les métadonnées spécifiques générées après enregistrement
• Le client doit implémenter nos métadonnées dans son IdP pour que le SSO fonctionne correctement