Différence entre un fournisseur d’identité et un service d’annuaire ?

Un fournisseur d’identité comme un service d’annuaire peuvent servir de plateforme centrale contenant des données d’identité pour l’authentification des utilisateurs. Un fournisseur d’identité, IdP, est plus puissant et peut également être utilisé dans des environnements cloud. Un service d’annuaire est principalement conçu pour des environnements IT internes.

Quelle est la différence entre un fournisseur d’identité et un Service Provider ?

Un fournisseur d’identité, IdP, authentifie les utilisateurs et fournit des données d’identité aux applications et aux services. Une telle application ou un tel service est appelé Service Provider, SP. L’IdP assure donc l’authentification des utilisateurs à destination du SP.

Fournisseur d’identité (IdP)

Q: Qu’est-ce qu’un fournisseur d’identité ?

Un fournisseur d’identité, IdP, est un système qui authentifie les utilisateurs et confirme ainsi leur identité pour des applications ou des services. Un IdP gère les identifiants de connexion et prend le plus souvent en charge le Single Sign-On et l’authentification multifacteur.

Qu’est-ce qu’un fournisseur d’identité ?

Un IdP (Identity Provider) est une plateforme centrale capable de vérifier l’identité numérique des utilisateurs. Les applications qui sont reliées à un tel IdP par une relation de confiance peuvent déléguer l’authentification des utilisateurs à ce fournisseur d’identité. L’utilisateur se connecte à l’IdP et, en cas d’authentification réussie, obtient immédiatement l’accès aux applications connectées. L’IdP peut également fournir des informations supplémentaires afin de faciliter l’autorisation des utilisateurs.

Pourquoi un fournisseur d’identité est-il important ?

Le principal avantage est que l’utilisateur n’a pas à se connecter séparément à différentes applications avec des identifiants distincts. Une seule paire d’identifiants est enregistrée dans l’IdP, le plus souvent un nom d’utilisateur et un mot de passe, ce qui permet d’accéder à plusieurs applications connectées. Ainsi, le fournisseur d’identité constitue un élément clé du Single Sign-On (SSO), car l’authentification peut généralement être configurée pour que l’utilisateur ne se connecte qu’une seule fois au début d’une session; il obtient ensuite automatiquement l’accès aux autres applications. Cette approche est à la fois plus conviviale et plus sécurisée. Si les utilisateurs ne doivent se connecter qu’une fois, l’usage d’un mot de passe fort et de l’authentification multifacteur pose en général moins de difficultés.

Au-delà du SSO, un fournisseur d’identité est également essentiel pour la fédération, où une seule paire d’identifiants permet d’accéder à plusieurs domaines partenaires. Les collaborateurs d’organisations partenaires, par exemple différentes écoles au sein d’un même établissement, peuvent ainsi accéder facilement, avec leurs propres identifiants, aux applications et aux données des uns et des autres grâce au fournisseur d’identité.

Fournisseur d’identité et Service Provider

Avant d’expliquer le fonctionnement d’un fournisseur d’identité, il est utile de préciser d’abord la notion de Service Provider, car ces deux termes sont souvent liés:

Le fournisseur d’identité est la plateforme responsable de la vérification de l’identité d’un utilisateur et de la fourniture de données d’authentification à d’autres systèmes. Il gère les comptes utilisateurs et leurs moyens de connexion tels que mots de passe, mais également l’authentification multifacteur (MFA) ou les données biométriques.
Un Service Provider est une application ou un service qui s’appuie sur un fournisseur d’identité pour vérifier les utilisateurs. Le SP fait donc confiance à l’IdP pour l’authentification, puis accorde l’accès en conséquence. Le terme Service Provider peut prêter à confusion, car dans le contexte de l’authentification, c’est justement lui qui consomme un service fourni par l’Identity Provider.

Comment fonctionne un fournisseur d’identité ?

Comment utiliser un fournisseur d’identité pour se connecter facilement à des applications ou des services, les Service Providers? Pour illustrer en même temps le SSO, nous donnons un exemple où deux applications sont accédées successivement.

Authentification auprès du fournisseur d’identité pour l’Application 1

Un utilisateur tente d’accéder à l’Application 1, autrement dit au SP 1.
L’Application 1 constate que l’utilisateur n’est pas connecté et envoie donc une demande d’authentification au fournisseur d’identité (IdP).
L’utilisateur est redirigé vers la page de connexion de l’IdP, où il saisit ses identifiants tels qu’un nom d’utilisateur et un mot de passe.
L’IdP vérifie l’identité de l’utilisateur et, en cas de succès, génère un jeton d’authentification, c’est-à-dire un laissez-passer numérique chiffré.
L’utilisateur est renvoyé vers l’Application 1 avec ce jeton.
L’Application 1 valide le jeton et l’utilisateur obtient l’accès.

L’accès s’est donc effectué de manière indirecte. Une relation de confiance existe entre le fournisseur d’identité et le Service Provider, c’est pourquoi l’application accorde l’accès sur la base du jeton d’authentification.

Accès à l’Application 2 avec SSO

L’utilisateur tente ensuite d’accéder à l’Application 2, soit au SP 2.
L’Application 2 détecte elle aussi que l’utilisateur n’est pas connecté et envoie donc une demande d’authentification à l’IdP.
L’IdP constate que l’utilisateur dispose déjà d’une session active, issue de l’Application 1. Il ne redemande donc pas d’identifiants.
L’IdP génère ensuite un jeton d’authentification pour l’Application 2.
L’Application 2 valide le jeton et accorde l’accès à l’utilisateur.

L’utilisateur est maintenant connecté à l’Application 2 sans se reconnecter. Le SSO n’est pas une fonctionnalité obligatoire d’un fournisseur d’identité, il serait également possible de se reconnecter avec les mêmes identifiants, mais une IdP est particulièrement adaptée pour activer cette fonctionnalité.

Parce que les fournisseurs d’identité doivent s’intégrer de manière fluide à de nombreuses applications, la communication repose sur des protocoles standard. SAML (Security Assertion Markup Language) ou OpenID Connect sont par exemple utilisés pour l’échange des jetons d’authentification. Pour transmettre également des données d’autorisation depuis l’IdP vers les applications, des protocoles tels qu’OAuth 2.0 et JWT (JSON Web Token) sont employés.

Exemples d’Identity Providers

Deux exemples connus de fournisseurs d’identité sont Entra ID et Google Identity Platform:

Microsoft Entra ID, anciennement Azure Active Directory, est un fournisseur d’identité cloud qui propose le Single Sign-On (SSO), l’authentification multifacteur (MFA) et la fédération, avec Active Directory Federation Services, ADFS. Entra ID s’intègre de manière fluide avec Microsoft 365, Azure et des applications d’entreprise. Ce fournisseur d’identité Microsoft Azure prend en charge, entre autres, les normes OAuth 2.0, OpenID Connect et SAML.
Google Identity Platform fournit des services d’authentification et d’autorisation et prend en charge le SSO et la MFA. Il offre aux utilisateurs disposant de comptes Google un accès sécurisé à Google Workspace, aux applications mobiles et aux applications web. Cet IdP prend en charge OAuth 2.0, OpenID Connect et Firebase Authentication.

En outre, les environnements IAM modernes proposent souvent un fournisseur d’identité intégré. HelloID offre également à ses clients leur propre fournisseur d’identité, incluant les fonctionnalités MFA et SSO.

Fournisseur d’identité au sein de votre solution IAM

Un fournisseur d’identité joue en général un rôle spécifique au sein d’un environnement de Gestion des Identités et des Accès, IAM, plus vaste. L’IdP est essentiel pour vérifier les utilisateurs et fournir des informations destinées à l’authentification et à l’autorisation, puis un environnement IAM complète cela avec des fonctionnalités supplémentaires. La plateforme IAM assure également la gestion des données d’identité et des droits tout au long du cycle de vie de l’identité. Celui-ci commence à l’entrée des utilisateurs et se poursuit lors des mobilités internes vers d’autres fonctions, puis jusqu’à la sortie de l’organisation. Ci-dessous, nous décrivons brièvement comment une plateforme IAM telle que HelloID exploite un fournisseur d’identité et y ajoute de la valeur.

Access Management

De nombreux clients utilisent aujourd’hui Microsoft 365 comme base pour leur bureautique. Cela signifie aussi l’usage d’AD comme service d’annuaire ou d’Entra ID comme véritable fournisseur d’identité. Dans ce cas, une plateforme IAM comme HelloID n’est pas utilisée directement pour ces fonctions d’accès, mais pour des fonctions avancées de management et de gouvernance. Nous détaillons cela dans les paragraphes ci-dessous.

Parallèlement, il existe encore des scénarios où l’on souhaite appliquer un fournisseur d’identité propre au sein de la plateforme IAM. Le module HelloID Access Management propose à cet effet son propre fournisseur d’identité, offrant le SSO et l’authentification multifacteur pour les applications connectées. Chaque utilisateur dispose alors d’un portail personnalisé avec les icônes de ses applications, ouvrables en un clic. Ce portail SSO HelloID peut aussi être intégré aisément, sous forme de widget, dans l’intranet existant d’une organisation cliente. Grâce aux fonctionnalités d’Access Management, nous proposons également la fédération pour faciliter la collaboration entre organisations clientes et prendre en charge des scénarios de migration.

Provisionnement

Les données d’un fournisseur d’identité tel qu’Entra ID peuvent bien sûr être gérées directement sur la plateforme par un administrateur IT. Cela devient toutefois rapidement difficile à maîtriser lorsque l’organisation connecte de très nombreuses applications à l’IdP avec des centaines, voire des milliers d’utilisateurs. D’autant qu’il ne s’agit pas uniquement d’attribuer une fois des comptes et des droits. Il faut ensuite maintenir ces données en permanence à jour.

Nous simplifions cette gestion avec le module HelloID Provisioning qui, sur la base de l’Attribute Based Access Control, ABAC, garantit que chaque collaborateur dispose à tout moment automatiquement des bons comptes et des bons droits. Pour ce faire, la plateforme consulte un système source, tel que l’application RH. On y trouve à tout moment la fonction, le service et le site actuels des collaborateurs, sur la base desquels HelloID détermine automatiquement les comptes et les droits d’accès requis. Ceux-ci sont ensuite automatiquement répercutés pour chaque collaborateur vers le fournisseur d’identité, ainsi que vers d’autres systèmes cibles; car toutes les plateformes ne sont pas raccordées à l’IdP et d’autres systèmes cibles enregistrent également des informations relatives aux droits d’accès.

Votre fournisseur d’identité joue donc techniquement un rôle important dans votre Single Sign-On, et par conséquent dans l’authentification des utilisateurs et l’autorisation vers les systèmes cibles. Le module de provisionnement garantit ensuite que, dans les grandes organisations complexes, tous les paramètres sont gérés de manière maîtrisable et contrôlable.

Service Automation

Il en va de même pour le module HelloID Service Automation. Grâce au provisionnement, nous veillons à ce que les utilisateurs reçoivent automatiquement, lorsque c’est possible, les comptes et les droits. En plus de ce provisionnement automatique, des demandes individuelles demeurent toutefois nécessaires. Par exemple, quelqu’un peut avoir besoin temporairement d’une licence d’application supplémentaire pour travailler sur un projet. Une telle modification peut naturellement être effectuée par des administrateurs de niveau 2, directement dans le fournisseur d’identité et dans d’autres systèmes cibles. Avec le module Service Automation, les agents du support ou les managers peuvent désormais réaliser eux-mêmes ces changements. Certaines modifications peuvent aussi être effectuées en libre-service par un collaborateur via le portail self-service. Ici encore, les changements concernent notamment le fournisseur d’identité, mais ils sont réalisés de façon bien plus efficace et conviviale. De plus, toutes les modifications sont plus faciles à tracer a posteriori. Et la sécurité est préservée, car les changements sont exécutés via HelloID et personne ne travaille directement dans les systèmes cibles.

Gouvernance

Dans HelloID, nous proposons des fonctionnalités de reporting étendues, regroupées en outre au sein du module HelloID Governance. Nous pouvons ainsi tracer facilement toutes les modifications de droits et évaluer mensuellement la gestion des comptes et des droits, puis ajuster si nécessaire. Des contrôles réguliers nous permettent d’identifier les portes dérobées et les incohérences et de maintenir notre modèle de rôles à jour. La fonctionnalité IAM est ainsi intégrée à la boucle Plan-Do-Check-Act, exigence importante d’ISO 27001 et des normes de sécurité qui en dérivent.

En savoir plus sur le rôle d’un fournisseur d’identité ?

Vous souhaitez en savoir plus sur le rôle d’un fournisseur d’identité et sur son utilisation dans HelloID? La page Access Management de notre site présente un aperçu complet des fonctionnalités et des possibilités.