Partagez cet article
L’époque où les employés s’installaient sur leur poste de travail et interagissaient exclusivement avec des applications natives est révolue mais pas oubliée : l’héritage des mots de passe uniques pour les services/applications persiste, aggravant les frustrations des administrateurs informatiques et des utilisateurs.
C’est particulièrement vrai avec les infrastructures en nuage, où l’exposition des informations d’identification sur le réseau et la possibilité d’une multitude de mots de passe faibles entravent la productivité des utilisateurs et augmentent les risques. Il existe une meilleure solution : l’authentification unique (SSO).
Qu’est-ce que l’authentification unique (SSO) ?
Le SSO est une solution que de nombreuses grandes entreprises ont adoptée pour moderniser l’authentification et la gestion des identités, ainsi que pour faciliter l’entrée et la sortie des employés. Un mot de passe unique et sécurisé est utilisé au départ, mais les choses commencent ensuite à fonctionner très différemment.
Le SSO utilise SAML, un mécanisme qui partage les identités entre les organisations et les applications. SAML n’envoie pas de mots de passe sur le web à chaque connexion ; il utilise plutôt un système de jetons sécurisés, ce qui réduit les risques de sécurité lorsqu’il est correctement mis en œuvre. En d’autres termes, un avenir « sans mot de passe » avec des normes d’authentification modernes comme SAML et OAuth devrait figurer sur votre feuille de route.
Vous vous demandez peut-être pourquoi l’adoption du SSO n’est pas universelle. La réponse est compliquée : de nombreuses petites et moyennes entreprises (PME) sont embourbées dans des environnements d’annuaire anciens qui utilisent le protocole réseau Kerberos pour sécuriser l’authentification sur les réseaux locaux.
Cela fonctionnait bien dans ce scénario « sur site », mais les infrastructures informatiques d’aujourd’hui ne sont pas toutes locales et utiliser des mots de passe pour s’authentifier dans chaque service revient à résoudre un problème par un autre. La mentalité de Kerberos, centrée sur les mots de passe, est devenue préjudiciable à la sécurité, et son utilisation est complexe et risquée dans le cadre de déploiements inter-royaux (c’est-à-dire que si A fait confiance à B et B à C, A pourrait faire confiance à C).
Vous constaterez également que cet ancien protocole compliqué est difficile à dépanner, qu’il est difficile de vérifier les garanties de sécurité et qu’il peut donner lieu à des autorisations déléguées sans contraintes en aval. Les résultats les plus pernicieux de cette dette technique sont : une gestion difficile des mots de passe, le risque de réutilisation des mots de passe et les violations de données qui exposent ces informations d’identification.
Tous ces éléments augmentent vos risques (inacceptables), ce qui rend les violations de données plus probables. Le SSO est un moyen moderne et simple de résoudre tous ces problèmes, mais sa mise en place prend du temps.
Franchement, « le SSO est difficile à tester » est un autre refrain courant. Vous ne coderiez pas un site Web sans avoir visionné le produit et effectué des tests avant d’entrer en production. Votre marque, votre réputation et la satisfaction des utilisateurs en pâtiraient, et cela n’a aucun sens. Il en va de même pour le SSO, où :
- Au niveau de l’infrastructure, des informations relatives aux terminaux, à la sécurité et à la confidentialité sont échangées, et
- Au niveau de la présentation, un seul justificatif d’identité est créé pour l’expérience d’ouverture de session.
Les ressources d’essai ne sont généralement pas disponibles publiquement ou consistent en des essais limités dans le temps qui peuvent ne pas être synchronisés avec votre calendrier.
N’attendez pas : le SSO doit être une priorité absolue
Avant de commencer, l’importance du SSO en tant qu’exigence de sécurité fondamentale n’est pas toujours évidente au premier abord. L’écrasante majorité des cyberattaques sont des « drive-by » où les attaquants tirent parti d’une mauvaise hygiène informatique, comme des mots de passe faibles.
Ce ne sont généralement pas les menaces persistantes avancées (APT) compliquées qui exposent les données et les utilisateurs d’une entreprise, mais le fait de ne pas être proactif et d’adopter des solutions modernes. Ajoutez à cela la difficulté de gérer un grand nombre d’informations d’identification et d’autorisations d’utilisateurs disparates, ce qui donne des maux de tête aux administrateurs informatiques rien que d’y penser. La violation de la sécurité de Colonial Pipeline en est un exemple et a été la conséquence d’un seul mauvais mot de passe et d’un seul compte dont le service informatique avait perdu la trace.
Des IdP et des ressources de test facilement accessibles vous permettent de « le faire maintenant », plutôt que de reporter à plus tard un projet hautement prioritaire. Une matrice de priorité normalisée vous aidera à faire valoir vos arguments en interne, sur la base d’un système de triage de tous vos projets, avec une compréhension mutuelle entre l’informatique et les responsables de niveau C, en tenant compte du budget et de l’urgence.
Une utilisation judicieuse de toutes les capacités de votre IdP, comme le SSO, contribuera grandement à la protection de votre organisation. L’adoption du SSO devrait être une priorité dans votre évaluation de toute plateforme d’annuaire et d’authentification, ce qui est rendu possible par l’utilisation du test gratuit SAML Service Provider (SP).
Il permet d’évaluer pleinement la solution SSO avant de l’acheter, ce qui renforce votre expertise ainsi que la confidentialité, l’intégrité et la disponibilité des ressources informatiques qui sont vitales pour votre entreprise. Une violation coûte bien plus cher que le SSO. L’utilisation du test SP est simple, et est décrite en détail ci-dessous.
Maintenant, passons à l’étape du testing.
Le fournisseur de services de test SAML et la sélection des fournisseurs
Il y a trois entités à garder à l’esprit lorsque vous démarrez votre projet SSO :
- Le fournisseur d’identité (IdP), (c’est-à-dire un annuaire des utilisateurs et des capacités d’authentification)
- Le fournisseur de services (SP), ou application Web
- Un utilisateur qui a un compte et une identité établis au sein de l’IdP.
Les outils de test sont également utiles, et un service gratuit appelé SAML Test Service Provider est disponible gratuitement pour accélérer vos efforts en matière de SSO. De nombreux fournisseurs d’identité ne sont pas prêts à fournir un bac à sable à des fins de testing, alors faites preuve de diligence lorsque vous choisissez le vôtre. Il est également important de tenir compte de la prise en charge du SSO lorsque vous choisissez un fournisseur de services Internet. Les fournisseurs de services peuvent devenir un obstacle à l’adoption du SSO lorsque la tarification exploite votre désir d’adopter les meilleures pratiques de sécurité.
Le SSO n’est pas un luxe, mais une nécessité absolue pour les organisations comptant plus de 5 membres. Cependant, des fonctionnalités telles que la prise en charge de SAML sont souvent liées à des niveaux de service plus élevés au sein des applications Web (également appelées plus haut : fournisseurs de services).
C’est ce qu’on appelle officieusement la « taxe SSO », qui rend les projets plus difficiles à justifier lorsque les coûts sont multipliés. Utilisez un fournisseur de services qui offre le SSO comme une fonctionnalité de base du produit ; sinon, cette capacité vitale peut être hors de portée du budget de votre organisation.
Un autre point douloureux commun que le fournisseur de services de test abordera est la préparation : SAML fait de la migration une proposition « tout ou rien ». Tous les utilisateurs doivent être authentifiés via le SSO dès le départ. Par conséquent, tester votre mise en œuvre bien à l’avance portera ses fruits avec une ressource de formation facilement disponible, permettant aux utilisateurs d’obtenir un niveau de confort et de compétence de base avec le processus de connexion au portail avant le basculement.
Mise en route du fournisseur de services de test SAML
Il existe deux façons d’effectuer vos tests : Le SSO initié par l’IdP et le SSO initié par le SP. Dans cet exemple, JumpCloud est l’IdP en combinaison avec le fournisseur de tests gratuits.
SSO initié par l’IdP
Les métadonnées SAML et IdP :
L’étape initiale pour utiliser le fournisseur de services de test est la méthode initiée par l’IdP. Vous pouvez obtenir les métadonnées SAML du SP de test, qui sont disponibles ici. Les métadonnées sont des informations qui décrivent le service afin que votre IdP puisse le consommer.
Votre IdP disposera d’une interface permettant de créer un connecteur SAML générique (remarque : les IdP disposent généralement d’une bibliothèque de connecteurs préfabriqués prêts à l’emploi pour les services couramment utilisés). Cette étape permettra d’intégrer votre IdP à l’outil de test SAML avec une configuration par défaut.
La possibilité de personnaliser son aspect et sa convivialité est décrite ici. Cependant, il n’est pas nécessaire de personnaliser quoi que ce soit pour effectuer des tests fonctionnels de base à l’aide de l’outil gratuit. Voici quelques ressources qui démystifieront le début de ce processus :
- Comment travailler avec les métadonnées SAML pour ADFS et XML ?
- Authentification unique (SSO) avec SAML 2.0 Connector (application SAML personnalisée)
SSO initié par le SP
Utilisez les métadonnées de votre IdP
L’étape des métadonnées est un prérequis pour le SSO initié par le SP. Vous suivrez une procédure similaire pour le SSO initié par le SP en téléchargeant (ou en coupant et collant) les métadonnées IdP dans l’outil de test. Il en résultera la création d’une URL unique que vous utiliserez pour vous connecter tout au long de vos tests.
URL de test
L’URL renvoie à l’IdP, qui s’occupe de la gestion de l’identité et de l’authentification. Les instructions insistent sur la nécessité de mettre cette URL en signet et sur le fait que l’accès à celle-ci enverra une demande SAML AuthNRequest à votre IdP, qui est simplement un message envoyé par le SP demandant l’authentification de la session d’un utilisateur donné.
Le processus d’importation des métadonnées IdP doit être répété dans l’outil si vous le perdez, il est donc conseillé de le garder à portée de main pendant toute la durée du test (ne vous inquiétez pas, il y a des instructions détaillées sur la page Web du service de test). La considération la plus importante est d’avoir un IdP qui vous permettra d’expérimenter à votre propre rythme.
Façons d’authentifier le SSO
Le site de test comprend des informations supplémentaires, mais aussi un « AuthNRequest Wizard » qui s’affiche en haut de la page une fois que l’utilisateur s’est authentifié. Vous pouvez l’utiliser pour déterminer une méthode d’authentification spécifique de l’IdP (AuthenticationContextClassRef) ou signaler que l’authentification initiale a eu lieu afin que l’IdP puisse ensuite sélectionner un facteur plus fort pour renforcer votre sécurité.
Il est fortement conseillé d’utiliser l’authentification multifactorielle (MFA, ou multi-factor authentication), mais il faut toujours tenir compte de l’aspect humain de la mise en œuvre et de l’utilisation quotidienne. Différentes formes d’authentification sont plus faciles et certaines sont plus difficiles à maîtriser pour l’utilisateur. Les notifications push sont souvent décrites comme étant les plus conviviales.
Attributs et personnalisations du SSO
Choisissez une couleur, n’importe laquelle.
Vous voulez un portail que les utilisateurs reconnaîtront immédiatement et auquel ils feront confiance grâce à une image de marque et un schéma de couleurs appropriés. L’outil de test dispose d’une fonction appelée « RelayState » qui permet de personnaliser l’apparence de la page protégée ; de définir l’attribut à une couleur prise en charge du côté IdP (NameID) ou de déclencher un changement de couleur sans modifier la configuration en ajoutant l’URL unique du site de test — par exemple « https://sptest.iamshowcase.com/protected?color=blue ».
Messages de bienvenue SSO et autres personnalisations
NameID, une déclaration d’attribut SAML, est l’endroit où d’autres personnalisations, comme un message de bienvenue, sont définies. Des informations supplémentaires sur les attributs peuvent être trouvées ici (téléchargement PDF). Le site de test fournit l’exemple suivant spécifique à l’outil :
« Bonjour <prénom> <nom> »
Pour remplir les champs <prénom> et/ou <nom>, il essaiera de trouver un attribut appelé « prénom » pour <prénom> et « nom » ou « nomdefamille » pour <nom>. Tout ceci ignore totalement la casse du nom de l’attribut, donc préNom, Prénom, prénom, PrÉnOm sont tous les mêmes (si vous pensez que PrÉnOm est une bonne idée… nous saluons votre audace !)
Intégrité de l’utilisateur
Veuillez noter que l’outil de test est uniquement destiné à des fins de démonstration et que certaines fonctions de sécurité avancées ne sont pas prises en charge pour le moment, notamment les demandes AuthNR signées et les assertions SAML cryptées, qui sont des données communiquées entre le SP et l’IdP concernant le statut d’autorisation de l’utilisateur (ce qui signifie que vous êtes un utilisateur légitime). Les détails concernant les attributs et les déclarations d’attributs se trouvent par ailleurs dans l’outil de test.
Conformité et conservation des données pour le SSO
Vous pouvez également souhaiter consigner toutes les authentifications SAML à des fins de conformité si vous êtes dans un secteur réglementé ou si vos analystes de sécurité et vos administrateurs informatiques suivent l’accès aux ressources. Des régimes de conformité spécifiques imposent la journalisation de l’accès à des points d’extrémité désignés, tels que : La conformité PCI DSS pour les environnements de données des titulaires de cartes (CDE) ; HIPAA et les informations de santé personnelles (PHI) ; et la vue large du GDPR sur les données stockées pour les résidents basés dans l’UE.
Conclusion
Le fournisseur de services de test SAML supprime les obstacles à l’adoption du SSO et facilite la relation avec un IdP offrant un environnement bac à sable adapté au calendrier de votre projet. Il est conseillé d’examiner si un SP (application Web) fournit un support SAML SSO natif et gratuit avant de choisir ce fournisseur. Le risque et les dépenses liés à l’absence de SSO sont moins acceptables si :
- Votre organisation s’agrandit
- Elle consomme plus de services
- L’authentification Kerberos et les mots de passe traditionnels s’avèrent inadéquats pour les services en cloud ; ET,
- L’environnement des menaces de cybersécurité devient de plus en plus difficile à contrôler et à analyser.
Les tests sont importants afin d’être prêt pour le passage à SAML, qui est mondial et pourrait perturber les opérations sans une acceptation et une formation adéquates des utilisateurs.
Les avantages du SSO sont essentiels pour l’infrastructure en cloud et ne devraient pas être relégués au domaine des grandes entreprises disposant de budgets plus importants. Vous pouvez utiliser un modèle de matrice des priorités pour déterminer la place du SSO dans votre agenda informatique : les résultats pourraient vous surprendre.
Inscrivez-vous dès aujourd’hui pour un essai gratuit de 30 jours.
