Qu’est-ce que le SAML
et comment fonctionne-t-il
avec Active Directory ?

Dans le monde du travail actuel, la simplification de la gestion des mots de passe est essentielle. Alors que les entreprises font un bond en avant dans la digitalisation, les employés utilisent plus que jamais (page en anglais) des outils collaboratifs, de messagerie ou de stockage. Cela représente un défi pour la gestion informatique : comment fournir aux employés un accès sécurisé aux applications internes et aux données stockées dans le cloud ? Pour beaucoup, la réponse est le SAML (Security Assertion Markup Language, en français : Langage de Balisage d'Assertion de Sécurité).

Qu’est-ce que le SAML ?

Le SAML est une norme ouverte qui simplifie les processus d’authentification. C’est basé sur le langage XML (Extensible Markup Language), qui normalise la communication entre les entités à authentifier et le service ou l’application web. En d’autres termes, le SAML est ce qui rend possible l’utilisation d’un seul identifiant pour vous connecter à plusieurs applications différentes.

Qu’en est-il de l’authentification unique SAML ?

L’un des principaux rôles de SAML est de permettre la SSO (page en aglais). Avant le SAML, la SSO était possible, mais dépendante des cookies et viable que sur un même domaine.

Le SAML permet l'authentification unique (SSO) en autorisant les utilisateurs à accéder à plusieurs applications avec une seule connexion et un seul ensemble d'informations d'identification. Bien que le SAML ne soit pas récent, il existe depuis 2002, de nombreuses nouvelles applications et entreprises SaaS utilisent le SAML pour la SSO. Sa version la plus récente, SAML 2.0 permet une SSO inter-domaine (page en anglais) basée sur le web et constitue la norme pour l'autorisation des ressources.

Dans l’environnement Active Directory, l’authentification unique de SAML permet aux utilisateurs d’accéder à un large panel d’applications avec seulement une information de connexion. Les utilisateurs Active Directory peuvent continuer à utiliser une source d’identité centralisée (AD) pour accéder aux applications Cloud comme Microsoft 365.

Si vous êtes à la recherche d’informations sur le fonctionnement de SAML avec Active Directory et sur la façon dont le SAML peut s’intégrer à la MFA et à des fournisseurs d’accès comme UserLock, alors ce Guide est pour vous.

Une introduction à la terminologie SAML

Avant de débuter, voici quelques termes utiles pour naviguer dans le jargon SAML.

  • Fournisseur d’identité (IdP) :
    Un site ou un fournisseur qui identifie l’utilisateur et envoie l’assertion SAML
  • Fournisseur de service (SP) :
    Un site ou un fournisseur qui reçoit l’assertion SAML et qui reconnait l’authentification pour permettre la connexion automatique
  • Assertion :
    Une assertion contient de nombreuses informations appelées « revendications ». Elles sont généralement transmises des IdPs aux SPs. Ces revendications permettent aux SPs de décider qui a les autorisations nécessaires pour gagner l’accès. Il existe 3 types de revendications SAML :
    1. Revendication d’authentification :
      Cette revendication dit au SP que le IdP a authentifié l’utilisateur à un certain moment et a utilisé une certaine méthode d’authentification. Cette revendication peut également contenir des informations supplémentaires sur l’utilisateur appelées contexte d’authentification.
    2. Revendication d’attribut :
      Un attribut est une paire nom-valeur que les SP et les IdP utilisent pour décider d’accorder ou non l’accès. Ces revendications déclarent que l’utilisateur est associé avec certains attributs.
    3. Revendication de décision d’autorisation :
      Cette revendication confirme, ou affirme, qu’un utilisateur a certaine autorisation. Habituellement, cela suit une formule simple (en anglais): un utilisateur (souvent appelé « principal ») est autorisé à effectuer l'action A sur la ressource R étant donné la preuve P.
  • Métadonnées :
    les métadonnées SAML sont contenues dans un document et décrivent un déploiement SAML. Cela peut être dans le contexte de SP ou de IdP. Les déploiements partagent des métadonnées pour établir la confiance et l’intemporalité, puis transmettent à minima :
    1. L’identité de l’utilisateur
    2. Des clés cryptographiques
    3. Des points de contact des protocoles (liaisons et emplacements)

Quels sont les avantages de l’authentification SAML ?

Le SAML apporte de nombreux avantages pour la sécurité, pour les utilisateurs, et pour les autres fournisseurs de service.

  • La simplicité :
    Les utilisateurs ne se connectent qu'une seule fois à l'IdP, puis bénéficient d'un accès transparent et plus sécurisé à toutes les applications.
  • Augmentation de la sécurité :
    De nombreux SP n’ont ni le temps ni les ressources de mettre en œuvre et d'appliquer une authentification utilisateur sécurisée lors de la connexion. En règle générale, les IdP sont mieux équipés pour authentifier les identités des utilisateurs. En renvoyant l'authentification à l'IdP, le SAML permet une authentification sécurisée qui peut appliquer plusieurs niveaux de sécurité, comme la MFA.

Les avantages pour les utilisateurs

  • Amélioration de l’expérience utilisateurs :
    Grâce au SAML, vos utilisateurs peuvent dire adieu aux maux de tête en essayant de retenir de nombreux noms d’utilisateur et mots de passe
  • Gain de temps :
    Le SAML accélérant le processus d’authentification, les utilisateurs perdent moins de temps

Les avantages pour les fournisseurs de service :

  • Réduire la charge de gestion :
    Les fournisseurs de service peuvent améliorer la sécurité de leur plateforme sans pour autant stocker les mots de passe.
  • Réduire les coûts et les charges du service support :
    N’ayant plus besoin de gérer les problèmes de mots de passe oubliés, le service support réduit les coûts et libère les équipes techniques pour traiter d’autres demandes plus urgentes.

La différence entre le SAML initié par le IdP et le SAML initié par le SP

Il est important de signaler que l’IdP et le SP, peuvent tous les deux initier une requête SAML. Avec l'initiation SP, la demande de connexion est initiée par l'application à laquelle l'utilisateur veut accéder. L'utilisateur est ensuite redirigé vers l'IdP, qui vérifie alors si l'utilisateur est actuellement connecté et s’il est authentifié ou non. L'IdP génère alors une réponse SAML vers le SP qui donne à l'utilisateur l'accès à l'application.

Dans le cas d'une connexion initiée par l'IdP, l'utilisateur se connecte directement à l'IdP. Lorsque l'utilisateur ouvre ensuite les applications compatibles, le SP envoie une demande d'authentification à l'IdP. Une fois authentifié, l'IdP indique que l'utilisateur est authentifié et l'utilisateur accède à l'application.

Comment le SAML fonctionne-t-il avec Active Directory ?

AD sur site est la marque de fabrique dans la gestion des identités depuis des décennies. Maintenant, alors que les entreprises passent à un environnement hybride ou cloud, elles veulent tirer profit de l’investissement réalisé dans AD. Les entreprises ont besoin d’un moyen de continuer à utiliser AD pour gérer les authentifications sur les applications cloud, sans perturber les utilisateurs ou les opérations informatiques.

Avec le SAML, les utilisateurs AD sur site, peuvent accéder à une multitude d’applications web, comme Microsoft 365, en utilisant seulement leurs informations de connexion.

Comment ça marche exactement ? Cette pratique courante utilise une identité fédérée (page en anglais) : des ID utilisateurs stockées dans des applications et des entreprises distinctes. Le SAML est un langage courant qui permet à ces applications et entreprises fédérées de communiquer et de faire confiance à leurs utilisateurs respectifs.

Tout d’abord, le SAML transmet l’information d’authentification (comment la connexion, l’état d’authentification, l’identifiant, etc.), entre l’IdP (Active Directory) et le SP (applications Cloud et services web). Lorsqu’un utilisateur essaie d’accéder à un site, AD transmet l'authentification SAML au SP, qui peut alors accorder l'accès à l'utilisateur.

Comment configurer la SSO SAML avec Active Directory ?

Il y a plusieurs manières différentes de configurer le SAML avec AD sur site. Regardons ensemble les exemples les plus courants :

Configurer la SSO SAML avec Microsoft AD FS ou AD Azure

Tout d'abord, Microsoft propose des solutions qui s'appuient sur le SAML pour fournir une SSO : Active Directory Federation Service (AD FS) et Azure AD (devenu Microsoft Entra ID).

AD FS est une solution autonome d’identité fédérée qui peut fournir des fonctionnalités SSO pour les utilisateurs AD sur site, mais c’est compliqué à déployer et à gérer (page en anglais).

Azure AD transpose la plateforme de gestion des identités de Microsoft sur le Cloud, loin du serveur sur site. Microsoft Azure AD permet aux utilisateurs AD d’accéder aux fonctionnalités SSO pour se connecter aux applications cloud. Microsoft recommande désormais Azure AD Connect pour tous les systèmes existants, à l’exception de AD FS.

Azure Active Directory Domain Services est un service géré et facultatif qui déploie des contrôleurs de domaine Windows Server dans Azure. Azure AD Domain Services offre un soutien aux entreprises qui disposent de services et de protocoles hérités qu'elles souhaitent transférer dans le cloud.

Bien qu’Azure AD offre la possibilité aux environnements AD sur site d’utiliser la SSO, de nombreuses entreprises, pour des raisons de sécurité, de simplicité, etc. préfèrent conserver leur authentification d’identité ID sur site.

Configurer la SSO SAML sécurisée
pour les Active Directory
sur site avec UserLock

UserLock étend l’authentification d’identité AD sur site au cloud, tout en veillant à ce que l'authentification se fasse via le serveur AD sur site. Avec UserLock, les entreprises peuvent aussi combiner la SSO avec l’authentification multifacteur (MFA) pour un accès sécurisé et fluide aux ressources tant du réseau que du cloud.

Installée et configurée en quelques minutes sur un serveur Windows standard, la SSO de UserLock prend en charge le protocole SAML 2.0 (en anglais) pour permettre l'authentification fédérée des applications cloud. Les utilisateurs ne se connectent qu’une seule fois avec leurs identifiants AD pour accéder aux applications et aux ressources cloud de l’entreprise.

Comment fonctionne UserLock SSO – Un exemple SAML pour Active Directory

Bob, comme la plupart des guerriers de bureau, commence sa journée en se connectant à son ordinateur. Il tape ses identifiants AD de connexion. Puisque son entreprise a mis en place un double facteur d’authentification (2FA) avec UserLock, il scanne rapidement l'empreinte de son pouce en utilisant sa clé de sécurité Token2-Bio. Puis il ouvre sa boite à outils quotidienne : Slake, Salesforce et Microsoft 365. Etant donné que la SSO de UserLock est en place pour ces applications, Bob peut accéder à toutes les applications sans entrer de mots de passe supplémentaires.

Etude de cas : comment UserLock SSO exploite le SAML pour Active Directory

Voici quelques façons dont le SAML fonctionne avec UserLock SSO

Cas n°1 : La SSO pour les applications SaaS compatibles

UserLock prend en charge une liste croissante d’applications SaaS. En utilisation la SSO SAML, l’utilisateur est authentifié grâce à ses identifiants de connexion existants sur site. UserLock peut également demander une authentification à deux facteurs, selon les conditions définies. Découvrez quelles sont les applications prises en charge et comment les configurer.

La SSO pour les applications SaaS compatibles

Cas n°2 : la SSO pour Microsoft 365 avec Active Directory

Grâce à UserLock, les utilisateurs peuvent également profiter de l’accès transparent à la suite Microsoft 365 après s’être connecté a AD. Les administrateurs informatiques, quant à eux, peuvent alors profiter des contrôles complets de UserLock pour gérer l'accès des utilisateurs à Microsoft 365.

la SSO pour Microsoft 365 avec Active Directory

Cas n°3 : La SSO pour Microsoft 3655 avec Azure AD Domain Services

Pour les écosystèmes qui utilisent Azure AD Domain Services, UserLock peut sécuriser et gérer les accès pour Microsoft 365.

La SSO pour Microsoft 3655 avec Azure AD Domain Services

Cas n°4 : La SSO pour les applications SaaS non compatibles

Les administrateurs informatiques peuvent aussi configurer une application non prise en charge à l’aide du protocole SAML. En utilisant leurs informations d’authentification Windows AD, les utilisateurs peuvent bénéficier d’un accès sécurisé et transparent aux applications SaaS les plus utilisées par votre équipe.

UserLock : la SSO sécurisée pour les identités AD sur site à l'aide de SAML

Avec UserLock, les entreprises peuvent fournir une SSO plus sécurisée et rapide grâce à SAML. Puisque les authentifications d’identité AD restent sur site, il n’y a pas besoin de créer et de gérer un nouvel annuaire pour les identités des utilisateurs. Aussi, les entreprises peuvent facilement appliquer des politiques de gestion pour les comptes, les services, les rôles et les groupes.

Vous voulez en savoir plus sur la façon dont UserLock peut aider votre organisation à mettre en place une SSO sécurisé pour les identités AD sur site ? Planifiez une démo UserLock aujourd’hui.

Télchargez ce livre blanc en PDF

Version PDF - 420 KB

Voyez par vous-même à quel point UserLock est facile à utiliser.

Téléchargez un essai gratuit Planifiez une démo