Simplifier l'intégration de l'authentification SAML pour les développeurs
Découvrez ce qu'est SAML, comment mettre en place le SSO, et les étapes rapides pour intégrer l'authentification SAML en tant que Fournisseur d'Identité (IdP) ou Fournisseur de Service (SP).
RanProduct & Design
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Single Sign-On (SSO) est essentiel pour les applications modernes, et SAML permet une authentification sécurisée et conviviale entre les systèmes d'identité d'entreprise. Ce guide simplifie SAML pour les développeurs et les designers avec des étapes claires et des exemples pratiques pour t'aider à l'implémenter efficacement.
Qu'est-ce que l'authentification SAML et les applications SAML ?#
Security Assertion Markup Language (SAML) est une norme basée sur XML utilisée pour échanger des données d'authentification et d'autorisation entre deux acteurs clés : le Fournisseur d'Identité (IdP) et le Fournisseur de Service (SP). C'est une solution courante pour le Single Sign-On (SSO) dans les organisations, facilitant la vie des utilisateurs en entreprise en leur permettant de se connecter une seule fois et d’accéder à de multiples applications.
Le Fournisseur d'Identité (IdP) est responsable de la gestion et de la vérification des identifiants utilisateur, tels que les noms d'utilisateur et les mots de passe. Lorsqu'un utilisateur tente d'accéder à un service protégé, l'IdP confirme son identité et envoie cette confirmation au service.
Exemple : Imagine que tu travailles pour une grande entreprise qui utilise Microsoft Azure AD pour gérer les comptes employés. Lorsque tu veux te connecter à Salesforce, Azure AD joue le rôle d'IdP. Il vérifie tes identifiants et informe Salesforce que tu es autorisé à l'utiliser.
Le Fournisseur de Service (SP) est l’application ou le service auquel les utilisateurs essaient d'accéder. Il compte sur l'IdP pour gérer toute l'authentification.
Exemple : En reprenant le scénario ci-dessus, Salesforce est le SP. Il repose sur Microsoft Azure AD (l'IdP) pour confirmer ton identité. Une fois qu’Azure AD t’a authentifié, Salesforce t'accorde l’accès.
Quand on parle d’une “application SAML”, on fait généralement référence au SP.
Grâce au protocole SAML, tu peux configurer ton service en tant qu’IdP pour prendre en charge l’intégration d’applications (comme Azure AD / Google Workspace), ou en tant que SP (comme Salesforce / Slack) pour permettre le SSO à tes utilisateurs.
Une Assertion SAML est au cœur du protocole SAML. C'est une “note” numérique créée par l’IdP et envoyée à un SP, qui dit : “J’ai confirmé l’identité de cet utilisateur.” Nous allons voir ensuite comment ce processus fonctionne pour l’IdP et le SP.
Quand ton service fonctionne comme IdP, tu actives l’authentification SAML sur plusieurs applications. Cela permet aux utilisateurs d’accéder à différents services via une seule identité d’entreprise.
Voici un flux SSO SAML typique pour un IdP :
L'utilisateur essaie d’accéder à une application (SP), comme Salesforce.
L’application redirige l’utilisateur vers ton IdP pour authentification.
L'utilisateur saisit ses identifiants sur la page de connexion de ton IdP.
L'IdP vérifie les identifiants.
Si les identifiants sont validés, l’IdP envoie une assertion SAML au SP.
Le SP traite l’assertion, confirme sa validité et accorde l’accès à l’utilisateur.
Si ton service est un SP, tu vas t’intégrer à différents fournisseurs d’identité pour proposer le SSO à tes utilisateurs. Cela permet aux salariés d’organisations différentes d’accéder à ton application de façon sûre et efficace.
Voici un flux pour un SSO initié par le SP :
L'utilisateur tente de se connecter à ton application.
Ton application génère une requête SAML et redirige l'utilisateur vers la page de connexion de l’IdP.
L’utilisateur se connecte à l’IdP (ou saute cette étape s’il est déjà identifié).
L’IdP vérifie l’identité de l’utilisateur et, une fois validée, “emballe” les informations dans une assertion SAML.
L’IdP retourne l’assertion à ton application.
Ton service vérifie l’assertion. Si elle est valide, l’utilisateur obtient l’accès à ton application.
IdP Entity ID : Un identifiant unique pour l’IdP dans les communications SAML, comme un badge nominatif numérique.
URL SSO : Le point d’entrée (URL) de connexion où le SP redirige les utilisateurs pour s’authentifier.
Certificat X.509 : Une clé publique utilisée pour signer l’assertion SAML, assurant sa sécurité. C'est le “sceau” qui vérifie l’authenticité.
Astuce : Si ton IdP propose une URL des métadonnées SAML, c’est plus simple. Cette URL contient toutes les infos nécessaires (certificats, URLs SSO, IdP Entity ID) au même endroit. Ça réduit les erreurs de copier-coller et évite la mise à jour manuelle des certificats.
NameID Format : Définit le format de l’identifiant utilisateur (ex : adresse email ou nom d’utilisateur).
Attributs SAML : Ce sont des informations supplémentaires transmises (rôles, email, département…) par l’IdP au SP.
Exemple : si l’assertion SAML signée par l’IdP inclut email ([email protected]), role (admin) et department (engineering), le SP peut utiliser role pour accorder des droits administrateur ou department pour placer l’utilisateur dans la bonne équipe. Pour obtenir ces données, l’IdP et le SP doivent s’accorder sur le mapping des attributs. Par exemple, l’IdP définit “department” comme équipe, alors que le SP l’attend comme groupe. Un bon mapping garantit un échange fluide.
Assertions chiffrées (Optionnel) : Pour protéger les données sensibles, les assertions SAML peuvent être chiffrées.
Rôle de l’IdP : Chiffre l’assertion avec la clé publique du SP.
Rôle du SP : Déchiffre l’assertion avec sa clé privée pour lire les informations utilisateur.
À ce stade, tu as tout ce qu’il faut pour configurer une connexion SAML. Pour intégrer Salesforce (SP) avec Azure AD (IdP), suis les étapes suivantes :
Récupère l’IdP Entity ID, l’URL SSO et le certificat depuis Azure AD puis configure-les dans Salesforce.
Fournis l’SP Entity ID et l’ACS URL de Salesforce à Azure AD.
Logto permet à d’autres applications de s’appuyer sur lui pour l’authentification fédérée, et prend en charge l’authentification multi-facteurs (MFA) pour une sécurité renforcée.
Configurer les paramètres SAML
Configure l’application avec l’Assertion Consumer Service URL et l’SP Entity ID du Service Provider (SP).
Fournir l’URL de métadonnées
Logto fournit une IdP Metadata URL que les SP peuvent utiliser pour récupérer automatiquement les informations essentielles comme les URLs SSO et les certificats.
Configuration avancée (Optionnel)
Tu peux créer plusieurs nouveaux certificats avec empreintes et dates d’expiration, mais un seul certificat peut être actif à la fois.
Modifie le Name ID format pour l’adapter à tes besoins métier.
Active le chiffrement des assertions SAML en copiant-collant le certificat x509 de ton fournisseur de services pour chiffrer les assertions.
Mapper les attributs(Optionnel)
Personnalise facilement la façon dont les attributs utilisateur sont partagés avec les Service Providers (SP).
Pour plus de détails, consulte la documentation officielle : SAML App
Logto s’intègre avec tous les IdP d’entreprise via les protocoles SAML ou OIDC. Que tu proposes un SSO lancé depuis le SP pour tes pages de connexion unifiées ou que tu configures un SSO initié par l’IdP, la démarche est simple.
Créer un connecteur d’entreprise
Va dans Logto Console > Enterprise SSO et crée un nouveau connecteur d’entreprise. Sélectionne SAML comme protocole.
Configurer les paramètres SAML
Fournis soit l’URL des métadonnées soit le fichier XML de métadonnées de ton IdP. Si les métadonnées ne sont pas disponibles, passe en configuration manuelle en saisissant l’IdP Entity ID, l’URL SSO, et en uploadant le certificat de signature.
Partager l’ACS URL et SP Entity ID
Communique l’ACS URL et l’SP Entity ID de Logto à ton IdP pour compléter l’intégration.
Mapper les attributs (Optionnel)
Configure le mapping des données utilisateur (comme l’email ou le nom) pour que l’information circule justement entre l’IdP et Logto.
Ajouter des domaines emails d’entreprise
Dans l’onglet “SSO Experience” du connecteur, ajoute un ou plusieurs domaines d’email. Cela garantit que seuls les utilisateurs de ces domaines peuvent s’authentifier via le SSO.
Activer le SSO initié par IdP (Optionnel)
N’active cette fonctionnalité que si elle est requise par tes clients entreprise. Elle permet aux utilisateurs de se connecter directement à tes applications depuis le tableau de bord IdP.
SAML offre une méthode standardisée et sécurisée pour le SSO, rendant l’authentification plus fluide. Logto simplifie la mise en œuvre que tu le déploies comme IdP ou comme SP. Avec son interface conviviale et son support des versions cloud et open-source, Logto enlève la complexité de l’intégration SAML. En configurant seulement quelques paramètres, tu peux relier tes services à n’importe quel IdP ou SP SAML et t’occuper de l’expérience de tes utilisateurs.
