Introduction 

Sur votre plateforme, vous pouvez configurer l’authentification unique (SSO), qui permet aux utilisateurs de se connecter à l’aide des identifiants d’un compte externe, comme un système institutionnel, un réseau d’entreprise ou un autre fournisseur d’identité.

• Lorsque le SSO est activé, les utilisateurs n’ont pas besoin de saisir un nom d’utilisateur et un mot de passe créés spécifiquement pour la plateforme.
• Au lieu de cela, ils peuvent cliquer sur un bouton de connexion (ou être redirigés automatiquement) pour s’authentifier via la page du fournisseur d’identité externe, après quoi ils sont redirigés en toute sécurité vers la plateforme.  

Cet article couvre les détails de configuration et les conseils de dépannage qui s’appliquent à différentes configurations SSO. Les informations contenues ici complètent celles fournies dans l’article spécifique à votre protocole ou intégration particulier.

Types de configurations SSO

La plateforme prend en charge plusieurs façons de configurer l’authentification unique, des protocoles standard aux intégrations directes :

Protocoles standard

• Protocole Open ID Connect : vous pouvez configurer l’application Open ID Connect pour configurer l’authentification unique avec le fournisseur d’identité de votre choix, tel que Okta, Salesforce, Onelogin, Microsoft Entra ID, etc.
• Protocole SAML : vous pouvez de la même manière configurer l’application SAML pour configurer l’authentification unique à l’aide de divers fournisseurs d’identité.  

À noter : pour chaque protocole vous ne pouvez configurer qu’un seul fournisseur d’identité sur le même domaine (plateforme principale ou entreprise étendue). Par exemple, si vous configurez OpenID Connect avec Okta comme fournisseur d’identité, vous ne pouvez pas configurer une autre instance OpenID Connect avec un fournisseur d’identité différent sur le même domaine. Cependant, vous pouvez le faire sur un domaine différent de l’entreprise étendue.  

Intégrations directes

La plateforme prend également en charge une variété d’intégrations SSO directes avec des fournisseurs d’identité, y compris Auth0, Gmail et Google Apps. 

Authentification unique externe

Il est également possible de forcer les utilisateurs non authentifiés vers une URL SSO externe spécifiée. Dans l’onglet SSO de l’application API et SSO, cochez l’option Forcer SSO externe et saisissez l’URL SSO externe requise. Avec ce paramètre,  lorsque les utilisateurs accèdent à l’URL de la plateforme, ils sont automatiquement redirigés vers l’URL SSO externe spécifiée. 

À noter : l’option Forcer SSO externe, lorsqu’elle est activée, remplace toutes les autres méthodes de connexion :
- la page de connexion standard ne sera pas affichée, les utilisateurs ne peuvent donc pas se connecter avec leurs identifiants de la plateforme, ni utiliser aucun bouton SSO sur la page de connexion standard. 
- de plus, la redirection vers l’URL SSO externe a priorité sur toutes les redirections automatiques vers le fournisseur d’identité que vous configurez pour d’autres méthodes de SSO.  
En pratique, cela signifie que seule l’URL SSO externe peut être utilisée pour accéder à la plateforme. 

Comportement du SSO

→ Vous verrez ces paramètres lors de la configuration du SSO via les protocoles OpenID Connect ou SAML, ou via l’intégration directe Auth0.

Les paramètres de Comportement du SSO vous permettent de configurer la manière dont les utilisateurs se connecteront à la plateforme via l’authentification unique. Deux options sont disponibles : Afficher la page de connexion standard et Redirection automatique vers le fournisseur d’identité

Afficher la page de connexion standard :

Avec cette option, lorsque les utilisateurs cliquent sur Connexion dans l’en-tête de la plateforme, ils verront le formulaire de Connexion normal avec les champs pour saisir les identifiants de la plateforme.

• Si vous sélectionnez également Afficher le bouton SSO sur la page de connexion, sous les champs nom d’utilisateur et mot de passe, les utilisateurs verront un bouton pour se connecter avec le SSO.  Ce bouton aura un logo correspondant au protocole SSO particulier ou au fournisseur d’identité configuré.
• Lorsqu’ils cliquent sur ce bouton SSO, ils sont redirigés vers une page pour s’authentifier avec le fournisseur d’identité, et si l’authentification réussit, ils sont connectés à la plateforme.

Astuce : dans Menu de navigation > Personnalisation (formes géométriques) > Identité de marque et visuelle > Page de connexion vous pouvez définir l’option Afficher uniquement les boutons SSO et masquer le formulaire de connexion, dans ce cas, le formulaire de connexion n’affichera que les boutons SSO, mais pas les champs de nom d’utilisateur et de mot de passe.  

À noter : si vous ne choisissez pas d’afficher le bouton SSO, les utilisateurs ne pourront pas initier la connexion SSO depuis la page d’accueil de la plateforme. 

Redirection automatique vers le fournisseur d’identité : 

Avec cette deuxième option, les utilisateurs ne voient pas le formulaire de connexion de la plateforme et n’ont besoin de cliquer sur aucun bouton de connexion SSO. Au lieu de cela, lorsqu’ils tentent d’accéder à l’URL de la plateforme, ils sont automatiquement redirigés vers la page pour s’authentifier avec le fournisseur d’identité. Ensuite, si l’authentification réussit, ils sont connectés à la plateforme.

Veuillez noter qu’avec l’option de redirection automatique, les utilisateurs ne peuvent pas afficher la page publique et ne peuvent pas choisir entre d’autres options de connexion. Avec cette méthode, ils sont tenus de s’authentifier auprès du fournisseur d’identité configuré. 

Il est recommandé d’éviter d’activer la redirection automatique vers le fournisseur d’identité jusqu’à ce que vous ayez confirmé que le SSO fonctionne correctement. Sinon, vous risquez de vous retrouver bloqué hors de la plateforme si la redirection est active et que le SSO ne fonctionne pas.

Remarques sur la redirection automatique :
Si certains de vos utilisateurs ne sont pas gérés par le fournisseur d’identité (IdP) et ont besoin d’accéder à la plateforme avec des identifiants natifs, n’activez pas la redirection automatique vers le fournisseur d’identité, car cela empêcherait les utilisateurs non-IdP de se connecter. 
Choisissez plutôt l’option Afficher le bouton SSO sur la page de connexion : 
- cela permet aux utilisateurs gérés par l’IdP de se connecter via SSO, tandis que les utilisateurs en dehors de l’IdP peuvent continuer à se connecter à l’aide du formulaire de connexion natif de la plateforme. 
- l’application Extended Enterprise peut également être utilisée pour configurer différents comportements de connexion pour des groupes d’utilisateurs ou des publics spécifiques. 

Page de destination de déconnexion

Avec la redirection automatique, lorsqu’un utilisateur se déconnecte de la plateforme, il sera envoyé vers une page de destination par défaut indiquant que la déconnexion a réussi. Il pourra alors soit fermer la page, soit utiliser le bouton de reconnexion pour s’authentifier à nouveau. 

Si vous le souhaitez, vous pouvez rediriger les utilisateurs qui se déconnectent vers une autre page, en saisissant son URL dans le champ Page de destination de déconnexion. 

Comportement de déconnexion

→ Vous verrez ces paramètres lors de la configuration du SSO via les protocoles OpenID Connect ou SAML, ou via l’intégration directe Auth0.

L’option Comportement de déconnexion vous permet de définir si l’utilisateur doit également être automatiquement déconnecté du fournisseur d’identité lorsqu’il se déconnecte de la plateforme.  

• Dans certaines configurations SSO, lorsque cette option est sélectionnée, un champ de texte Endpoint déconnexion apparaît. Ici, vous pouvez définir une URL vers laquelle les utilisateurs atterriront après s’être déconnectés de la plateforme et du fournisseur d’identité. 

Remarque : pour éviter les conflits, si vous utilisez la Redirection automatique vers le fournisseur d’identité, vous ne devez pas activer l’option Comportement de déconnexion. 

Attribut du nom d’utilisateur

→ Vous verrez ce paramètre lors de la configuration du SSO via les protocoles OpenID Connect ou SAML, ou via l’intégration directe Auth0

Lorsque vous implémentez l’authentification unique (SSO) via un fournisseur d’identité, la décision de savoir si un utilisateur se connectant via SSO existe déjà sur la plateforme dépend généralement d’un champ d’identifiant unique reçu du fournisseur d’identité. 

Dans le champ Attribut du nom d’utilisateur, vous pouvez définir le champ que vous souhaitez utiliser à cet effet :

• Lors de votre sélection, assurez-vous que le champ sélectionné est renseigné pour tous vos utilisateurs dans le fournisseur d’identité.
• Le champ sélectionné doit également être unique. Par exemple, si vous sélectionnez family_name, vous devez vous assurer qu’aucun de vos utilisateurs ne porte le même nom de famille dans le fournisseur d’identité.
• Par exemple, vous pouvez utiliser un e-mail comme Attribut du nom d’utilisateur, à condition que tous vos utilisateurs aient des e-mails distincts côté fournisseur. 

Le champ du fournisseur d’identité que vous sélectionnez dans l’Attribut du nom d’utilisateur sera mis en correspondance (par défaut*) avec le champ Nom d’utilisateur sur la plateforme. Cela signifie que :
- si les deux champs correspondent, l’utilisateur s’authentifiant via SSO est considéré comme existant déjà sur la plateforme, et sera connecté à ce compte.
- si aucun Nom d’utilisateur correspondant n’est trouvé sur la plateforme, l’utilisateur SSO n’existe pas encore sur la plateforme, mais peut être automatiquement créé si vous configurez le Provisionnement des utilisateurs. 
*Uniquement dans la configuration standard SAML, vous pouvez modifier ce paramètre par défaut pour choisir un champ différent.

Provisionnement des utilisateurs

→ Vous verrez ces paramètres lors de la configuration du SSO via les protocoles OpenID Connect ou SAML, ou via l’intégration directe Auth0

Le provisionnement des utilisateurs vous permet de créer automatiquement un nouvel utilisateur sur la plateforme si l’authentification SSO est valide mais que cet utilisateur n’existe pas encore sur la plateforme. Il vous permet également de mettre à jour automatiquement les détails d’un utilisateur sur la plateforme en fonction des informations correspondantes au niveau du fournisseur d’identité SSO. 

Astuce : par défaut, un utilisateur est considéré comme existant déjà sur la plateforme si son Nom d’utilisateur correspond au champ du fournisseur d’identité que vous avez défini comme Attribut du nom d’utilisateur. Consultez le chapitre Attribut du nom d’utilisateur. 

Création d’utilisateurs provisionnés

Lorsque vous choisissez d’Activer le provisionnement des utilisateurs, un utilisateur se connectant via SSO qui n’existe pas encore sur la plateforme sera créé à la volée, avec Nom d’utilisateur sur la plateforme = le champ du fournisseur défini dans l’Attribut du nom d’utilisateur.  

Remarque sur le placement dans la branche par défaut : pour le SSO sur la plateforme principale, les utilisateurs nouvellement créés seront placés dans la branche racine. Pour le SSO sur un client d’une entreprise étendue, les utilisateurs nouvellement créés seront placés dans la branche associée au client.

Ajouter plus de champs provisionnés 

En plus du Nom d’utilisateur, vous souhaiterez peut-être renseigner d’autres détails d’un utilisateur provisionné en utilisant les informations récupérées auprès du fournisseur d’identité. 

Pour ce faire, rendez-vous à la section Ajouter des champs. Celle-ci s’affichera légèrement différemment selon la configuration SSO que vous utilisez, mais dans tous les cas, elle vous permettra de faire correspondre d’autres champs côté fournisseur d’identité avec les champs correspondants de la plateforme. 

Notez que chaque champ de la plateforme et champ du fournisseur d’identité ne peut être utilisé qu’une seule fois. Vous ne pouvez pas faire correspondre plusieurs champs de la plateforme au même champ IdP, ni vice versa. 

Astuce : si sur l’onglet Paramètres avancés > Auto-inscription de la plateforme vous avez coché l’option Nom et prénom sont requis pour s’enregistrer, assurez-vous d’inclure ces champs dans la section Ajouter des champs, afin que les utilisateurs provisionnés puissent être créés.  
De même, si vous avez défini certains champs supplémentaires d’utilisateur comme obligatoires sur la plateforme, assurez-vous qu’ils sont mappés ici afin de pouvoir être renseignés, sinon l’utilisateur ne pourra pas être créé correctement. 

Mettre à jour les champs provisionnés

Cochez la case Si l’utilisateur existe déjà, mettre à jour ses informations pour mettre à jour automatiquement, au sein de la plateforme, les valeurs de tous les champs provisionnés qui ont été modifiés du côté du fournisseur d’identité. Dans le cas contraire, vous devrez copier manuellement toute modification pour garder les champs provisionnés alignés.  

Verrouiller les champs d’utilisateur provisionnés

Cochez la case Verrouiller les champs d’utilisateur provisionnés pour empêcher les utilisateurs de modifier, dans Mon profil, tous les champs d’utilisateur provisionnés. Ces champs apparaîtront grisés et marqués comme désactivés, afin que l’utilisateur ne puisse pas modifier la valeur obtenue auprès du fournisseur d’identité. 

→ Notez cependant qu’un Superadmin ou un Power User peut toujours modifier les valeurs de ces champs provisionnés verrouillés dans la Gestion des utilisateurs avec la restriction suivante : seuls les champs d’informations sur l’utilisateur peuvent être modifiés, tandis que les champs supplémentaires utilisateur, s’ils sont verrouillés, ne peuvent être modifiés par personne. 

Si vous avez configuré plus d’une méthode SSO, vous pouvez rencontrer des problèmes en raison des interactions entre les champs verrouillés. Pour plus de détails à ce sujet, consultez le chapitre Conflits de provisionnement entre plusieurs configurations SSO

Veuillez noter que tous les paramètres de provisionnement décrits ici s’appliquent uniquement aux utilisateurs qui se connectent via SSO (authentification unique). Par exemple, les champs provisionnés verrouillés ne seront pas désactivés pour les utilisateurs qui se connectent à l’aide de leurs identifiants sur la plateforme. 

Conflits de provisionnement entre plusieurs configurations SSO

Il est recommandé d’éviter d’avoir plusieurs méthodes SSO actives avec le provisionnement sur le même domaine, car des interférences ou des conflits peuvent survenir. Ces problèmes peuvent apparaître même si certains fournisseurs SSO ne sont pas entièrement configurés.

Notez que nous faisons ici référence à une situation où plusieurs fournisseurs SSO sont actifs sur la même plateforme principale ou le même client/domaine d’une entreprise étendue. Vous pouvez, cependant, utiliser différentes méthodes d’authentification unique sur différents domaines. 

Interaction entre les champs verrouillés avec plusieurs fournisseurs SSO

Sur les plateformes ayant plus d’un fournisseur SSO actif pour le même domaine, vous pouvez rencontrer un comportement de verrouillage de champ incohérent si les deux fournisseurs ont le Provisionnement activé, mais des paramètres différents pour Verrouiller les champs provisionnés (l’un activé, l’autre désactivé). 

Par exemple :
- des champs peuvent rester verrouillés même pour le fournisseur dont le verrouillage est désactivé
- inversement, des champs peuvent être déverrouillés pour le fournisseur dont le verrouillage est activé

→ Notez que ce comportement se produit uniquement lorsque plusieurs fournisseurs SSO sont actifs sur la même plateforme principale ou le même client/domaine extended enterprise. Cependant, les paramètres des champs verrouillés dans un domaine n’affectent pas les autres domaines.

SSO avec différents champs provisionnés et options de verrouillage

Un problème connexe peut survenir lorsque deux configurations SSO ont des champs supplémentaires provisionnés, en particulier lorsqu’un flux SSO provisionne et verrouille un champ obligatoire que l’autre fournisseur SSO ne provisionne pas. Par exemple : 

• SSO 1 : configuré pour provisionner le champ supplémentaire utilisateur obligatoire "monchamp", avec l’option Verrouiller les champs provisionnés cochée
• SSO 2 : ne provisionne PAS "monchamp"

Si un utilisateur se connecte avec le SSO 2,  la connexion peut échouer car le champ "monchamp" est obligatoire, mais ne peut pas être renseigné car il est verrouillé par le SSO 1. 

Pour résoudre les conflits de provisionnement :

Si vous rencontrez un conflit de provisionnement tel que ceux décrits ci-dessus, vous pouvez le résoudre des manières suivantes : 

• Si possible, envisagez de n’avoir qu’une seule méthode SSO configurée sur un domaine donné (plateforme principale ou client extended enterprise).
• Si vous avez besoin de plusieurs méthodes SSO, conservez le provisionnement activé sur une seule d’entre elles, et désactivez le provisionnement des autres SSO  (les utilisateurs concernés devront alors être ajoutés au SSO dont le provisionnement est activé, et mis à jour avec une connexion)
• Si vous devez conserver plusieurs SSO avec le provisionnement, veillez à aligner soigneusement les configurations de provisionnement des utilisateurs de tous les fournisseurs SSO afin qu’ils aient les mêmes champs supplémentaires et options de verrouillage. En particulier assurez-vous que les champs supplémentaires d’utilisateur obligatoires sont provisionnés.
• Si un champ supplémentaire obligatoire cause le problème, définissez-le sur la plateforme comme non obligatoire.