Tous les services Google, y compris Google Cloud, Google Marketing Platform et Google Ads, exploitent Google Sign-In pour authentifier les utilisateurs. Ce document explique le modèle de domaine sur lequel Google Sign-In s'appuie pour l'authentification et la gestion des identités. Le modèle de domaine vous aide à comprendre le fonctionnement de Google Sign-In dans un contexte d'entreprise, la façon dont les identités sont gérées et comment faciliter l'intégration avec un fournisseur d'identité externe (IdP). Le schéma suivant montre comment ces entités interagissent.
Comme le montre ce schéma, l'identité Google, utilisée par Google Sign-In, est au centre du modèle. L'identité Google est liée à un certain nombre d'autres entités qui sont toutes pertinentes dans le contexte de la gestion des identités :
- Google pour le grand public contient les entités pertinentes pour une utilisation orientée client des services Google tels que Gmail.
- Google pour les entreprises contient des entités gérées par Cloud Identity ou Google Workspace. Ces entités sont les plus pertinentes pour gérer des identités d'entreprise.
- Google Cloud contient les entités spécifiques à Google Cloud.
- Externe contient des entités pertinentes si vous intégrez Google à un fournisseur d'identité externe.
Dans le schéma, les flèches pleines indiquent que les entités se font référence les unes aux autres ou se contiennent les unes les autres. En revanche, les flèches en pointillés indiquent une relation de fédération.
Identités Google
Les identités, les utilisateurs et les comptes utilisateur jouent un rôle essentiel dans la gestion des identités. Les trois termes sont étroitement liés et sont parfois utilisés de manière interchangeable. Toutefois, dans le contexte de la gestion des identités, il est intéressant de différencier les concepts suivants :
Une identité est un nom qui identifie de manière unique la personne qui interagit avec un service Google. Google utilise des adresses e-mail à cette fin. L'adresse e-mail d'une personne est considérée comme l'identité Google de cette personne.
Le processus de vérification de l'association entre une personne et une identité est appelé authentification ou connexion. Il permet à la personne de prouver qu'il s'agit bien de son identité.
Une personne peut avoir plusieurs adresses e-mail. Étant donné que les services Google utilisent une adresse e-mail comme identité, une telle personne serait considérée comme ayant plusieurs identités.
Un compte utilisateur est une structure de données qui effectue le suivi des attributs, des activités et des configurations qui doivent être appliqués chaque fois qu'une identité interagit avec un service Google. Les comptes utilisateur ne sont pas créés directement. Ils doivent être provisionnés avant la première connexion.
Les comptes utilisateur sont identifiés par un ID qui n'est pas exposé en externe. Les interfaces utilisateur ou les API nécessitent donc que vous référenciez indirectement le compte utilisateur par son identité associée, telle que
alice@gmail.com. Malgré cette indirection, toutes les données et tous les détails de configuration sont associés au compte utilisateur, et non à l'identité.
Dans la plupart des cas, il existe une relation un à un entre les comptes utilisateur et les identités, ce qui les rend faciles à fusionner. Cependant, ce n'est pas toujours le cas, comme l'illustrent les cas suivants :
La relation entre les comptes utilisateur et les identités n'est pas fixe. Vous pouvez modifier l'adresse e-mail principale d'un compte utilisateur, ce qui associe une identité différente à l'utilisateur.
En tant qu'administrateur Cloud Identity ou Google Workspace, vous pouvez même échanger les adresses e-mail principales de deux utilisateurs. Par exemple, si vous avez échangé les adresses e-mail principales d'Alice (
alice@example.com) et de Bob (bob@example.com), Alice utilisera le compte utilisateur précédent de Bob et Bob le compte utilisateur précédent d'Alice. Étant donné que les données et la configuration sont associées au compte utilisateur, et non à l'identité, Alice utilise également la configuration et les données existantes de Bob (et Bob utilise désormais la configuration et les données d'Alice). La figure suivante illustre cette relation.
Dans une configuration non fédérée, vous devez également réinitialiser les mots de passe pour qu'Alice et Bob échangent leurs comptes utilisateur. Dans une configuration fédérée, dans laquelle Alice et Bob utilisent un fournisseur d'identité externe pour s'authentifier, il n'est pas nécessaire de réinitialiser les mots de passe.
La relation entre l'identité et les utilisateurs peut ne pas être 1:1. Un compte personnel peut être intentionnellement associé à plusieurs identités, comme dans le schéma suivant.
Il est également possible qu'une identité fasse référence à deux comptes utilisateur différents. Nous vous recommandons d'éviter cette situation, mais elle peut survenir en cas de conflit de compte utilisateur. Dans ce cas, un écran de sélection s'affiche lors de l'authentification, dans lequel l'utilisateur choisit le compte à utiliser.
Google distingue deux types de comptes utilisateur : les comptes utilisateur personnels et les comptes utilisateur gérés. Les sections suivantes décrivent de manière plus détaillée les deux types de comptes utilisateur et leurs entités associées.
Google pour le grand public
Si vous possédez une adresse Gmail telle que alice@gmail.com, votre compte Gmail est un compte personnel. De même, si vous utilisez le lien Créer un compte sur la page de connexion Google et que vous fournissez une adresse e-mail personnalisée (alice@example.com, par exemple), le compte créé est un compte personnel.
Compte personnel
Les comptes personnels sont créés en libre-service et sont principalement destinés à être utilisés à des fins privées. La personne qui a créé le compte personnel a le contrôle total du compte et de toutes les données créées lorsqu'elle l'utilise. L'adresse e-mail utilisée par cette personne lors de l'inscription devient l'adresse e-mail principale du compte personnel et lui sert d'identité. Cette personne peut ajouter des adresses e-mail au compte personnel. Ces adresses e-mail servent d'identités supplémentaires et peuvent également être utilisées pour la connexion.
Lorsqu'un compte personnel utilise une adresse e-mail principale correspondant au domaine principal ou secondaire d'un compte Cloud Identity ou Google Workspace, le compte personnel est également appelé compte utilisateur non géré.
Un compte personnel peut être membre de plusieurs groupes.
Google pour les entreprises
Si votre entreprise utilise des services Google, il est préférable d'utiliser des comptes utilisateur gérés. Ces comptes sont appelés gérés car leur cycle de vie et leur configuration peuvent être entièrement contrôlés par l'entreprise.
Les comptes utilisateur gérés sont une fonctionnalité de Cloud Identity et de Google Workspace.
Compte Cloud Identity ou Google Workspace
Un compte Cloud Identity ou Google Workspace est le conteneur de premier niveau pour les utilisateurs, les groupes, la configuration et les données. Un compte Cloud Identity ou Google Workspace est créé lorsqu'une entreprise s'inscrit à Cloud Identity ou Google Workspace et correspond à la notion de locataire.
Cloud Identity et Google Workspace partagent une plate-forme technique commune. Les deux produits utilisent le même ensemble d'API et d'outils d'administration et partagent la notion de compte en tant que conteneur pour les utilisateurs et les groupes. Ce conteneur est identifié par un nom de domaine. En ce qui concerne la gestion des utilisateurs, des groupes et de l'authentification, les deux produits peuvent être considérés comme équivalents.
Un compte contient des groupes et une ou plusieurs unités organisationnelles.
Unité organisationnelle
Une unité organisationnelle (UO) est un sous-conteneur de comptes utilisateur qui vous permet de segmenter les comptes utilisateur définis dans le compte Cloud Identity ou Google Workspace en ensembles dissociés pour faciliter leur gestion.
Les unités organisationnelles sont organisées de manière hiérarchique. Chaque compte Cloud Identity ou Google Workspace possède une unité organisationnelle racine, sous laquelle vous pouvez créer d'autres UO selon vos besoins. Vous pouvez également imbriquer vos unités organisationnelles.
Cloud Identity et Google Workspace vous permettent d'appliquer certaines configurations par unité organisationnelle, telles que l'attribution de licence ou la validation en deux étapes. Ces paramètres s'appliquent automatiquement à tous les utilisateurs de l'unité organisationnelle et sont également hérités par les unités organisationnelles enfants. Les unités organisationnelles jouent donc un rôle clé dans la gestion de la configuration de Cloud Identity et de Google Workspace.
Un compte utilisateur ne peut pas appartenir à plusieurs unités organisationnelles, ce qui différencie les UO des groupes. Bien que les unités organisationnelles soient utiles pour appliquer la configuration aux comptes utilisateur, elles ne sont pas destinées à être utilisées pour la gestion des accès. Pour gérer les accès, nous vous recommandons d'utiliser des groupes.
Bien que les unités organisationnelles ressemblent à des dossiers Google Cloud, les deux entités ont des objectifs différents et ne sont pas liées.
Compte utilisateur géré
Les comptes utilisateur gérés fonctionnent de la même manière que les comptes utilisateur personnels, mais ils peuvent être entièrement contrôlés par les administrateurs du compte Cloud Identity ou Google Workspace.
L'identité d'un compte utilisateur géré est définie par son adresse e-mail principale.
L'adresse e-mail principale doit utiliser un domaine correspondant à l'un des domaines (principal, secondaire ou d'alias) ajoutés au compte Cloud Identity ou Google Workspace. Les comptes utilisateur gérés peuvent avoir des adresses e-mail d'alias et une adresse e-mail de récupération supplémentaires, mais ces adresses ne sont pas considérées comme des identités et ne peuvent pas être utilisées pour la connexion. Par exemple, si Alice utilise alice@example.com comme adresse e-mail principale et a configuré ally@example.com comme adresse e-mail d'alias et alice@gmail.com comme adresse e-mail de récupération, elle ne peut utiliser que l'adresse e-mail alice@example.com pour se connecter.
Les comptes utilisateur gérés sont contenus dans une unité organisationnelle et peuvent être membres de plusieurs groupes.
Les comptes utilisateur gérés sont destinés à des utilisateurs humains plutôt qu'à des utilisateurs machine. Un compte utilisateur machine est un type particulier de compte utilisé par une application ou une instance de machine virtuelle (VM), et non par une personne. Pour les utilisateurs machine, Google Cloud fournit des comptes de service. (Les comptes de service sont décrits plus en détail plus loin dans ce document.)
Groupe
Les groupes vous permettent de regrouper plusieurs utilisateurs. Vous pouvez utiliser des groupes pour gérer une liste de diffusion ou appliquer un même contrôle d'accès ou une configuration commune à plusieurs utilisateurs.
Cloud Identity et Google Workspace identifient les groupes par adresse e-mail, par exemple billing-admins@example.com. À l'instar de l'adresse e-mail principale d'un utilisateur, l'adresse e-mail d'un groupe doit utiliser l'un des domaines (principal, secondaire ou d'alias) du compte Cloud Identity ou Google Workspace. L'adresse e-mail ne doit pas nécessairement correspondre à une boîte aux lettres, sauf si le groupe est utilisé comme liste de diffusion. L'authentification s'effectue toujours avec l'adresse e-mail de l'utilisateur plutôt que celle du groupe. Par conséquent, l'utilisateur ne peut pas se connecter avec une adresse e-mail de groupe.
Un groupe peut avoir les entités suivantes en tant que membres :
- Utilisateurs (utilisateurs gérés ou comptes personnels)
- Autres groupes
- Comptes de service
Contrairement à une unité organisationnelle, un groupe n'agit pas comme un conteneur :
- Un utilisateur ou un groupe peut être membre de plusieurs groupes.
- La suppression d'un groupe ne supprime aucun des utilisateurs membres ou des groupes.
Les groupes peuvent contenir des membres de n'importe quel compte Cloud Identity ou Google Workspace, ainsi que des comptes personnels. Vous pouvez utiliser le paramètre interdire les membres externes à votre entreprise pour limiter les membres aux comptes utilisateur du même compte Cloud Identity ou Google Workspace.
Identités externes
En fédérant un compte Cloud Identity ou Google Workspace avec un fournisseur d'identité externe, vous pouvez permettre aux employés d'utiliser leur identité et leurs identifiants existants pour se connecter aux services Google.
Au niveau de base, la fédération implique de configurer l'authentification unique en utilisant SAML, qui associe les identités dans Cloud Identity ou Google Workspace aux identités gérées par votre fournisseur d'identité externe. Pour associer une identité telle que alice@example.com et l'activer pour l'authentification unique à Google, vous devez remplir deux conditions préalables :
- Votre fournisseur d'identité externe doit reconnaître l'identité
alice@example.comet autoriser son utilisation pour l'authentification unique. - Votre compte Cloud Identity ou Google Workspace doit contenir un compte utilisateur dont l'identité est
alice@example.com. Ce compte utilisateur doit exister avant la première tentative d'authentification unique.
Plutôt que de créer et de gérer manuellement des comptes utilisateur dans Cloud Identity ou Google Workspace, vous pouvez automatiser le processus en associant l'authentification unique SAML à la gestion automatique des comptes utilisateur. La gestion automatique des comptes utilisateur consiste à synchroniser un sous-ensemble ou l'ensemble des utilisateurs et des groupes d'une source externe faisant autorité avec Cloud Identity ou Google Workspace.
En fonction de votre choix de fournisseur d'identité, l'authentification unique SAML et la gestion automatique des comptes utilisateur peuvent être gérés par le même composant logiciel ou nécessiter des composants distincts. Le modèle de domaine fait donc la distinction entre un fournisseur d'identité SAML et une source externe faisant autorité.
Fournisseur d'identité externe SAML
Le fournisseur d'identité externe est le seul système d'authentification. Il offre à vos employés une expérience d'authentification unique couvrant l'ensemble des applications. Étant externe à Google, il est appelé fournisseur d'identité externe.
Lorsque vous activez l'authentification unique, Cloud Identity ou Google Workspace relaie les décisions d'authentification au fournisseur d'identité SAML. En termes SAML, Cloud Identity ou Google Workspace font office de fournisseur de services qui fait confiance au fournisseur d'identité SAML pour vérifier l'identité d'un utilisateur en son nom.
Chaque compte Cloud Identity ou Google Workspace ne peut faire référence qu'à un seul fournisseur d'identité externe. Plusieurs comptes Cloud Identity ou Google Workspace peuvent faire référence à différents fournisseurs d'identité SAML, mais il n'est pas possible qu'un seul compte Cloud Identity ou Google Workspace utilise plusieurs fournisseurs d'identité SAML.
Les fournisseurs d'identité externes couramment utilisés incluent Active Directory Federation Services (AD FS), Azure AD, Okta ou Ping Identity.
Source externe faisant autorité
La source faisant autorité pour les identités est le seul système que vous utilisez pour créer, gérer et supprimer les identités de vos employés. Étant externe à Google, elle est appelée source externe faisant autorité.
À partir de la source externe faisant autorité, les comptes utilisateur et les groupes peuvent être gérés automatiquement dans Cloud Identity ou Google Workspace. La gestion des comptes peut être gérée par la source faisant autorité elle-même ou par le biais d'un middleware.
Pour que la gestion automatique des comptes utilisateur soit efficace, les utilisateurs doivent disposer d'une identité reconnue par votre fournisseur d'identité SAML. Si vous mappez des identités (par exemple, si vous mappez l'identité alice@example.com dans Cloud Identity ou Google Workspace avec u12345@corp.example.com dans votre fournisseur d'identité SAML), le fournisseur d'identité SAML et le middleware de gestion des comptes doivent effectuer le même mappage.
Compte utilisateur externe
Les fournisseurs d'identité externes sont supposés disposer du concept de compte utilisateur assurant le suivi du nom, des attributs et de la configuration.
La source faisant autorité (ou le middleware) doit gérer tous les comptes utilisateur externes (ou un sous-ensemble des comptes) vers Cloud Identity ou Google Workspace afin de faciliter la connexion. Dans de nombreux cas, il est suffisant de propager uniquement un sous-ensemble des attributs de l'utilisateur (adresse e-mail, prénom et nom, par exemple) à Cloud Identity ou Google Workspace afin de limiter la redondance des données.
Groupe externe
Si votre fournisseur d'identité externe accepte la notion de groupe, vous pouvez éventuellement mapper ces groupes à des groupes dans Cloud Identity ou Google Workspace.
Le mappage et le provisionnement automatique des groupes sont facultatifs et ne sont pas requis pour l'authentification unique. En revanche, ces deux étapes peuvent s'avérer utiles si vous souhaitez réutiliser des groupes existants pour contrôler l'accès dans Google Workspace ou Google Cloud.
Google Cloud
Comme tous les autres services Google, Google Cloud utilise Google Sign-In pour authentifier les utilisateurs. Google Cloud s'intègre également parfaitement à Google Workspace et Cloud Identity pour vous permettre de gérer efficacement les ressources.
Google Cloud introduit la notion de nœuds d'organisation, de dossiers et de projets. Ces entités sont principalement utilisées pour gérer l'accès et la configuration. Elles ne sont donc pertinentes que dans le contexte de la gestion des identités. Toutefois, Google Cloud inclut également un type de compte utilisateur supplémentaire : les comptes de service. Les comptes de service appartiennent à des projets et jouent un rôle essentiel dans la gestion des identités.
Nœud d'organisation
Une organisation est le nœud racine de la hiérarchie des ressources Google Cloud et un conteneur pour les projets et les dossiers. Les organisations vous permettent de structurer vos ressources de manière hiérarchique et sont essentielles pour les gérer de manière centralisée et efficace.
Chaque organisation appartient à un seul compte Cloud Identity ou Google Workspace. Le nom de l'organisation est dérivé du nom de domaine principal du compte Cloud Identity ou Google Workspace correspondant.
Dossier
Les dossiers sont des nœuds de la hiérarchie des ressources Google Cloud et peuvent contenir des projets, d'autres dossiers ou une combinaison des deux. Vous utilisez des dossiers pour regrouper des ressources partageant des stratégies de gestion de l'authentification et des accès (IAM) ou des règles d'administration communes. Ces règles s'appliquent automatiquement à tous les projets du dossier et sont également héritées par les dossiers enfants.
Les dossiers sont similaires aux unités organisationnelles mais ne sont pas liés. Les unités organisationnelles vous aident à gérer les utilisateurs et à appliquer une configuration ou des règles communes aux utilisateurs, tandis que les dossiers vous permettent de gérer des projets Google Cloud et d'appliquer des configurations ou des règles communes à des projets.
Projet
Un projet est un conteneur de ressources. Les projets jouent un rôle essentiel dans la gestion des API, la facturation et la gestion de l'accès aux ressources.
Dans le contexte de la gestion des identités, les projets sont pertinents, car ils sont les conteneurs des comptes de service.
Compte de service
Un compte de service (ou compte de service Google Cloud) est un type particulier de compte utilisateur destiné à être utilisé par des applications et d'autres types d'utilisateurs machine.
Chaque compte de service appartient à un projet Google Cloud. Comme pour les comptes utilisateur gérés, les administrateurs peuvent totalement contrôler le cycle de vie et la configuration d'un compte de service.
Les comptes de service utilisent également une adresse e-mail comme identité, mais contrairement aux comptes utilisateur gérés, l'adresse e-mail utilise toujours un domaine appartenant à Google, tel que developer.gserviceaccount.com.
Les comptes de service ne participent pas à la fédération et ne possèdent pas de mot de passe. Sur Google Cloud, vous utilisez IAM pour contrôler l'autorisation dont dispose un compte de service sur une ressource de calcul telle qu'une machine virtuelle (VM) ou une fonction Cloud, ce qui vous évite de gérer des identifiants. En dehors de Google Cloud, vous pouvez utiliser des clés de compte de service pour permettre à une application de s'authentifier à l'aide d'un compte de service.
Compte de service Kubernetes
Les comptes de service Kubernetes sont un concept de Kubernetes et sont pertinents lorsque vous utilisez Google Kubernetes Engine (GKE). À l'instar des comptes de service Google Cloud, les comptes de service Kubernetes sont destinés à être utilisés par des applications, et non par des humains.
Les comptes de service Kubernetes peuvent être utilisés pour l'authentification lorsqu'une application appelle l'API Kubernetes d'un cluster Kubernetes, mais ils ne peuvent pas être utilisés en dehors du cluster. Ils ne sont pas reconnus par les API Google et ne remplacent donc pas un compte de service Google Cloud.
Lorsque vous déployez une application en tant que pod Kubernetes, vous pouvez associer le pod à un compte de service. Cette association permet à l'application d'utiliser l'API Kubernetes sans avoir à configurer ni à gérer de certificats ou d'autres identifiants.
En utilisant Workload Identity, vous pouvez associer un compte de service Kubernetes à un compte de service Google Cloud. Cette association permet à une application de s'authentifier auprès des API Google, à nouveau sans avoir à gérer de certificats ni d'autres identifiants.
Étape suivante
- Consultez nos architectures de référence pour la gestion des identités.