Utiliser Google OAuth pour l'authentification des utilisateurs de Looker (Google Cloud Core)

Google OAuth est utilisé conjointement avec Identity and Access Management (IAM) pour authentifier les utilisateurs de Looker (Google Cloud Core).

Lorsque vous utilisez OAuth pour l'authentification, Looker (Google Cloud Core) authentifie les utilisateurs via le protocole OAuth 2.0. Vous pouvez utiliser n'importe quel client OAuth 2.0. Par exemple, cette page vous explique comment configurer l'authentification pour une instance Looker (Google Cloud Core) en utilisant la console Google Cloud pour créer des identifiants OAuth.

Si une autre méthode est la méthode d'authentification principale, Google OAuth est par défaut la méthode d'authentification de secours.

Authentification et autorisation avec OAuth et IAM

Lorsqu'ils sont utilisés avec OAuth, les rôles IAM Looker (Google Cloud Core) fournissent les niveaux d'authentification et d'autorisation suivants pour toutes les instances Looker (Google Cloud Core) d'un projet Google Cloud donné. Attribuez l'un des rôles IAM suivants à chacun de vos comptes principaux, en fonction des niveaux d'accès que vous souhaitez leur accorder :

Rôle IAM Authentification Autorisation
Utilisateur d'instance Looker (roles/looker.instanceUser)

Peut se connecter aux instances Looker (Google Cloud Core)

 Lors de la première connexion à Looker (Google Cloud Core), le rôle Looker par défaut défini dans Rôles pour les nouveaux utilisateurs est attribué.

Vous ne pouvez pas accéder aux ressources Looker (Google Cloud Core) dans la console Google Cloud .
Lecteur Looker (roles/looker.viewer) Peut se connecter aux instances Looker (Google Cloud Core) Lors de la première connexion à Looker (Google Cloud Core), le rôle Looker par défaut défini dans Rôles pour les nouveaux utilisateurs est attribué.

Peut afficher la liste des instances Looker (Google Cloud Core) et les détails des instances dans la console Google Cloud
Administrateur Looker (roles/looker.admin) Peut se connecter aux instances Looker (Google Cloud Core) Lors de leur première connexion à Looker (Google Cloud Core), les utilisateurs se voient attribuer l'ensemble de rôles Looker par défaut défini dans Rôles pour les nouveaux utilisateurs.

Vérifié à chaque connexion à Looker (Google Cloud Core) qui utilise l'OAuth principal ou l'OAuth de secours et chaque fois que l'utilisateur appelle l'API Looker, ce rôle (ou un rôle personnalisé incluant l'autorisation looker.instances.update) accorde également le rôle Administrateur via IAM dans l'instance.

Le rôle Administrateur via IAM contient toutes les autorisations et fonctionnalités du rôle Looker Administrateur. Ce rôle ne peut pas être supprimé ni réattribué dans l'instance Looker (Google Cloud Core). Pour supprimer le rôle Administrateur via IAM, réattribuez au compte principal un rôle IAM autre que "Administrateur Looker" (roles/looker.admin). Les modifications apportées aux rôles IAM sont automatiquement synchronisées avec l'instance Looker (Google Cloud Core), même si l'utilisateur se connecte avec un fournisseur d'identité tiers après la modification. Pour en savoir plus, consultez la section Rôle d'administrateur Looker et rôle d'administrateur Looker via IAM.

Tant que le jeton d'actualisation OAuth d'un utilisateur est valide, son rôle est indiqué comme Administrateur via IAM dans Looker (Google Cloud Core), même si cet utilisateur se connecte ultérieurement avec un fournisseur d'identité tiers. Si le jeton d'actualisation OAuth expire ou est révoqué, l'utilisateur doit utiliser OAuth pour se reconnecter à l'instance afin de récupérer le rôle Administrateur via IAM.

Peut effectuer toutes les tâches d'administration pour Looker (Google Cloud Core) dans la console Google Cloud

De plus, les comptes utilisateur disposant du rôle owner pour un projet peuvent se connecter à toutes les instances Looker (Google Cloud Core) de ce projet et les administrer. Ces utilisateurs se verront attribuer le rôle Looker Administrateur.

Si les rôles prédéfinis ne fournissent pas l'ensemble d'autorisations souhaité, vous pouvez également créer vos propres rôles personnalisés.

Les comptes Looker (Google Cloud Core) sont créés lors de la première connexion à une instance Looker (Google Cloud Core).

Rôle d'administrateur Looker et rôle d'administrateur Looker via IAM

Deux rôles d'une instance Looker (Google Cloud Core) utilisent l'ensemble d'autorisations d'administrateur et confèrent les mêmes droits d'administrateur dans l'instance. Le tableau suivant récapitule les similitudes et les différences entre les deux rôles.

Propriété Rôle d'administrateur Looker Rôle d'administrateur depuis IAM Looker
Source fiable Accordé par un autre administrateur de l'instance Looker (Google Cloud Core) Directement lié au rôle IAM d'administrateur Looker
Peut être ajouté ou supprimé dans une instance Looker (Google Cloud Core) ? Oui Non
Peut être ajouté ou supprimé avec IAM ? Non Oui
Autorisations dans Looker (Google Cloud Core) Toutes les autorisations Toutes les autorisations
Autorisations dans la console Google Cloud Aucun Accès complet à toutes les ressources Looker (Google Cloud Core)
Validation des rôles En continu dans l'instance Looker (Google Cloud Core) À chaque connexion à l'instance Looker (Google Cloud Core) et à chaque appel d'API Looker.

La propagation des modifications apportées à un rôle avec IAM peut prendre plusieurs minutes.
Champ d'application Instance Looker (Google Cloud Core) individuelle Toutes les instances Looker (Google Cloud Core) d'un projet Google Cloud

Un utilisateur peut disposer des rôles Looker Administrateur et Administrateur via IAM. Par conséquent, si vous souhaitez révoquer les droits d'administrateur, veillez à supprimer à la fois le rôle IAM et le rôle Administrateur dans l'instance Looker (Google Cloud Core).

Configurer OAuth dans l'instance Looker (Google Cloud Core)

Dans l'instance Looker (Google Cloud Core), la page Authentification Google de la section Authentification du menu Admin vous permet de configurer certains paramètres Google OAuth. Vous devez disposer du rôle Looker Admin.

Fusionner des comptes utilisateur

Dans le champ Fusionner les utilisateurs à l'aide de, spécifiez la méthode à utiliser pour fusionner une première connexion OAuth avec un compte utilisateur existant. Lorsqu'un utilisateur se connecte pour la première fois avec OAuth, cette option le connecte à son compte existant en recherchant le compte correspondant à son adresse e-mail. Si l'utilisateur n'a pas de compte, un compte utilisateur sera créé.

Vous pouvez fusionner des utilisateurs à partir des systèmes suivants :

  • SAML
  • OIDC

Si vous avez plusieurs systèmes en place, vous pouvez spécifier plusieurs systèmes par lesquels fusionner dans ce champ. Looker (Google Cloud Core) recherche les utilisateurs dans les systèmes listés dans l'ordre dans lequel ils sont spécifiés. Par exemple, si vous avez d'abord créé des utilisateurs à l'aide d'OIDC, puis que vous avez utilisé SAML, lorsqu'un utilisateur tente de se connecter avec OAuth pour la première fois, Looker (Google Cloud Core) recherche d'abord l'utilisateur à l'aide d'OIDC. S'il ne trouve pas de correspondance pour l'utilisateur avec OIDC, il recherche l'utilisateur à l'aide de SAML.

Si vous ne souhaitez pas que Looker (Google Cloud Core) fusionne les utilisateurs, laissez ce champ vide.

Migrer entre des fournisseurs d'identité OIDC

Lorsque vous migrez d'un fournisseur d'identité OIDC vers un autre (par exemple, lors de la transition de PingFederate vers Okta), l'option de fusion de comptes décrite dans Fusionner des comptes utilisateur ne s'applique pas. La fusion ne s'applique que lorsque vous passez d'un type d'authentification à un autre (par exemple, de SAML à OIDC).

Looker (Google Cloud Core) utilise la revendication sub de la charge utile OIDC pour renseigner l'attribut utilisateur oidc_user_id, qui identifie de manière unique les comptes utilisateur OIDC. Pour empêcher Looker (Google Cloud Core) de générer des comptes utilisateur en double lors d'une migration OIDC, configurez votre nouveau fournisseur d'identité OIDC pour vous assurer que la revendication sub envoyée dans la charge utile OIDC correspond à la valeur oidc_user_id établie par votre fournisseur précédent (par exemple, la revendication sub doit contenir l'adresse e-mail de l'utilisateur au lieu d'un UUID nouvellement généré).

Si vous ne pouvez pas conserver des revendications sub identiques sur le nouveau fournisseur d'identité, de nouveaux comptes utilisateur seront créés. Dans ce scénario, vous pouvez utiliser l'API Looker pour récupérer le contenu favori et réattribuer les planifications des anciens comptes utilisateur aux nouveaux comptes utilisateur avant de supprimer les anciens comptes.

Dupliquer les groupes Google

Si vous disposez de groupes Google gérés, Looker (Google Cloud Core) peut créer des groupes Looker qui reflètent l'appartenance à vos groupes Google. Cela signifie que vous n'avez pas besoin de configurer les utilisateurs directement dans Looker (Google Cloud Core), mais que vous pouvez gérer leur accès en gérant l'appartenance aux groupes Google. De plus, les groupes Looker peuvent être utilisés pour attribuer des rôles aux membres du groupe, définir des contrôles d'accès au contenu, contrôler l'accès aux fonctionnalités et aux données, et attribuer des attributs utilisateur.

Pour que la mise en miroir des groupes fonctionne correctement, les utilisateurs doivent disposer de l'autorisation VIEW_MEMBERSHIP, qui leur permet d'afficher les membres des groupes Google auxquels ils appartiennent. Pour accorder cette autorisation dans les paramètres de l'interface utilisateur de Google Groupes, définissez le champ Qui peut voir les membres sur Membres du groupe.

Les groupes Looker mis en miroir (ainsi que les rôles et accès associés) sont appliqués aux nouveaux utilisateurs lors de leur première connexion à l'instance Looker (Google Cloud Core). Les groupes ne sont pas appliqués aux utilisateurs existants, et ne sont pas appliqués une nouvelle fois s'ils sont supprimés du compte d'un utilisateur dans Looker (Google Cloud core) après la connexion initiale de l'utilisateur.

Le rôle Looker Administrateur via IAM, qui est automatiquement attribué aux utilisateurs disposant du rôle Administrateur Looker dans le système IAM, remplace la mise en miroir des groupes. Les utilisateurs disposant du rôle Administrateur Looker dans le système IAM se voient automatiquement attribuer le rôle Administrateur via IAM dans Looker (Google Cloud Core), quels que soient leurs groupes d'appartenance. De plus, ces utilisateurs seront attribués à des groupes mis en miroir, et recevront des rôles et des accès via le processus de mise en miroir standard.

Nous vous recommandons de n'activer la mise en miroir des groupes que pour la méthode d'authentification principale de Looker (Google Cloud Core). Si vous utilisez OAuth comme méthode d'authentification de secours, n'activez pas la mise en miroir des groupes pour OAuth. Si vous activez la mise en miroir des groupes pour les méthodes d'authentification principale et secondaire, les comportements suivants se produiront :

  • Si un utilisateur possède des identités fusionnées, la mise en miroir des groupes correspondra à la méthode d'authentification principale, quelle que soit la méthode d'authentification réellement utilisée pour se connecter.
  • Si un utilisateur n'a pas fusionné ses identités, la mise en miroir des groupes correspondra à la méthode d'authentification utilisée pour se connecter.

Étapes pour activer les groupes mis en miroir

Pour activer la mise en miroir de groupes, procédez comme suit :

  1. Dans la console Google Cloud , activez l'API Cloud Identity dans le projet Google Cloud qui contient votre client OAuth. Vous devez disposer du rôle IAM Administrateur Service Usage (roles/serviceusage.serviceUsageAdmin) pour activer les API.

    Activer l'API

  2. Dans la console Google Cloud , mettez à jour l'écran de consentement du client OAuth pour ajouter le champ d'application https://www.googleapis.com/auth/cloud-identity.groups.readonly. Vous devez disposer de l'autorisation IAM clientauthconfig.clients.update pour ajouter des niveaux d'accès. Pour mettre à jour l'écran de consentement, procédez comme suit :

    • Accédez au client OAuth.
    • Sélectionnez la page Accès aux données.
    • Cliquez sur le bouton Ajouter ou supprimer des habilitations. Le panneau Mettre à jour les champs d'application sélectionnés s'ouvre.
    • Recherchez le champ d'application https://www.googleapis.com/auth/cloud-identity.groups.readonly, puis cochez la case à côté.
    • Cliquez sur le bouton Mettre à jour pour ajouter le champ d'application.

    • Fermez le panneau, puis cliquez sur Enregistrer sur la page Accès aux données pour enregistrer le champ d'application.

  3. Dans l'instance Looker (Google Cloud Core), activez l'option Mettre en miroir les groupes Google sur la page Authentification Google. Cette option est désactivée par défaut. Remplissez les champs suivants :

    • Dans le champ Nom du groupe Looker, ajoutez un nom pour le groupe Looker. Il s'agit du nom qui s'affichera sur la page Groupes de Looker (Google Cloud Core).
    • Dans le champ ID du groupe Google, saisissez le nom ou l'adresse e-mail du groupe Google que vous souhaitez dupliquer.
    • Dans le champ Rôle, saisissez le ou les rôles Looker que vous souhaitez attribuer aux membres de ce groupe.

Looker (Google Cloud Core) crée un groupe Looker pour chaque groupe Google ajouté à la page Authentification Google. Vous pouvez afficher ces groupes Looker sur la page Groupes de Looker (Google Cloud Core).

Modifier des groupes dupliqués

Lorsque vous modifiez l'appartenance à un groupe Google, ces modifications sont automatiquement propagées à l'appartenance au groupe Looker mis en miroir et validées lors de la prochaine connexion de chaque utilisateur.

Si vous modifiez les champs Nom personnalisé ou Rôle attribués à un groupe sur la page Authentification Google, cela modifie l'affichage du nom du groupe Looker dupliqué sur la page Groupes de Looker (Google Cloud Core) ou les rôles attribués au groupe, mais cela ne modifie pas les membres du groupe.

Si vous remplacez le nom ou l'adresse e-mail dans le champ ID du groupe Google de la page Authentification Google par l'ID d'un nouveau groupe Google, les membres du groupe Looker mis en miroir sont remplacés par les membres du nouveau groupe Google, mais le nom et les rôles du groupe sont conservés tels qu'ils sont définis sur la page Authentification Google.

Toute modification apportée à un groupe mis en miroir sera appliquée aux utilisateurs de ce groupe lors de leur prochaine connexion à Looker (Google Cloud Core).

Désactiver les groupes mis en miroir

Si vous souhaitez arrêter la mise en miroir de vos groupes Google dans Looker (Google Cloud Core), désactivez l'option Mettre en miroir les groupes Google sur la page Authentification Google de l'instance Looker (Google Cloud Core). Si vous désactivez le bouton bascule, le comportement suivant se produit :

  • Tout groupe Google miroir sans utilisateur est supprimé immédiatement.
  • Tout groupe Google miroir qui contient des utilisateurs est marqué comme orphelin. Si aucun utilisateur de ce groupe ne se connecte dans un délai de 31 jours, le groupe est supprimé. Il n'est plus possible d'ajouter ni de supprimer des utilisateurs des groupes Google orphelins.

Gestion avancée des rôles

Si l'option Miroir Google Groupes est activée, la page Authentification Google affiche les paramètres Gestion avancée des rôles. Les options de cette section déterminent la flexibilité dont disposent les administrateurs Looker lorsqu'ils configurent des groupes et des utilisateurs Looker qui ont été mis en miroir depuis Google.

Si vous souhaitez que la configuration de vos groupes et utilisateurs Looker corresponde strictement à celle de vos groupes Google, activez toutes les options de gestion avancée des rôles. Lorsque toutes les options sont activées, les administrateurs Looker ne peuvent pas modifier l'appartenance à des groupes dupliqués et ne peuvent attribuer des rôles aux utilisateurs que via Google Groupes.

Si vous souhaitez bénéficier d'une plus grande flexibilité pour personnaliser vos groupes dans Looker (Google Cloud Core), désactivez ces options. Vos groupes Looker (Google Cloud Core) refléteront toujours la configuration de vos groupes Google, mais vous pourrez effectuer des tâches supplémentaires de gestion des groupes et des utilisateurs dans Looker (Google Cloud Core), comme ajouter des utilisateurs Google à des groupes Looker ou attribuer des rôles Looker directement à des utilisateurs Google.

Pour les instances Looker (Google Cloud Core), ces options sont désactivées par défaut.

La section Gestion avancée des rôles contient les options suivantes :

  • Empêcher les utilisateurs Google individuels de recevoir des rôles directs : l'activation de cette option empêche les administrateurs Looker d'attribuer des rôles Looker directement aux utilisateurs Google. Les utilisateurs Google ne recevront des rôles que s'ils sont membres d'un groupe. Si les utilisateurs Google sont autorisés à rejoindre des groupes Looker intégrés (non dupliqués), ils peuvent toujours hériter de leurs rôles à la fois des groupes Google dupliqués et des groupes Looker intégrés. Les rôles qui étaient auparavant attribués directement aux utilisateurs Google seront supprimés lors de leur prochaine connexion.

    Si cette option est désactivée, les administrateurs Looker peuvent attribuer des rôles Looker directement aux utilisateurs Google dans l'instance Looker (Google Cloud Core).

  • Empêcher l'adhésion directe à des groupes autres que Google : cette option empêche les administrateurs Looker d'ajouter des membres de groupes mis en miroir directement à des groupes Looker intégrés qui ne font pas partie de la configuration du groupe mis en miroir sur la page Authentification Google.

    Si cette option est sélectionnée, tous les utilisateurs Google qui ont été précédemment attribués à des groupes Looker intégrés seront supprimés de ces groupes lors de leur prochaine connexion.

    Si cette option est décochée, les administrateurs Looker peuvent ajouter des utilisateurs Google directement aux groupes Looker intégrés.

  • Empêcher l'héritage des rôles depuis des groupes autres que Google : cette option empêche les membres des groupes mis en miroir d'hériter des rôles des groupes Looker intégrés. Si les groupes Google dupliqués sont autorisés à être membres de groupes Looker intégrés, les utilisateurs Google peuvent rester membres de n'importe quel groupe Looker intégré. Les utilisateurs Google qui ont précédemment hérité de rôles d'un groupe Looker intégré perdront ces rôles lors de leur prochaine connexion.

    Si cette option est désactivée, les groupes mis en miroir ou les utilisateurs Google ajoutés en tant que membres d'un groupe Looker intégré hériteront des rôles attribués au groupe Looker intégré.

  • Auth Requires Role (L'authentification nécessite un rôle) : si cette option est activée, les utilisateurs Google doivent se voir attribuer un rôle Looker. Les utilisateurs Google auxquels aucun rôle n'est attribué ne pourront pas se connecter à Looker (Google Cloud Core).

    Si cette option est désactivée, les utilisateurs Google peuvent s'authentifier auprès de Looker (Google Cloud Core) même si aucun rôle ne leur est attribué. Un utilisateur sans rôle attribué ne pourra pas voir de données ni effectuer d'actions dans Looker (Google Cloud Core), mais il pourra s'y connecter.

Définir un rôle Looker par défaut

Si le bouton Mirror Google Groups (Miroir des groupes Google) est désactivé, le paramètre Roles for new users (Rôles pour les nouveaux utilisateurs) s'affiche sur la page Google Authentication (Authentification Google). Ce paramètre vous permet de définir le rôle Looker par défaut qui sera attribué aux comptes utilisateur disposant du rôle IAM Utilisateur de l'instance Looker (roles/looker.instanceUser) ou du rôle IAM Lecteur Looker (roles/looker.viewer) lors de leur première connexion à une instance Looker (Google Cloud Core). Pour définir un rôle par défaut, procédez comme suit :

  1. Accédez à la page Authentification Google dans la section Authentification du menu Admin.
  2. Dans le paramètre Rôles pour les nouveaux utilisateurs, sélectionnez le rôle que vous souhaitez attribuer par défaut à tous les nouveaux utilisateurs. Le paramètre contient la liste de tous les rôles par défaut et rôles personnalisés de l'instance Looker (Google Cloud Core).

Les rôles d'administrateur ne peuvent pas être des rôles par défaut. Les comptes utilisateur disposant d'un rôle IAM d'administrateur Looker (roles/looker.admin) se verront attribuer le rôle Looker Administrateur via IAM lors de leur première connexion, en plus du rôle sélectionné dans le paramètre Rôles pour les nouveaux utilisateurs.

Si vous activez le bouton Synchroniser les groupes Google après avoir personnalisé le paramètre Rôles pour les nouveaux utilisateurs, les rôles attribués aux utilisateurs via le paramètre Rôles pour les nouveaux utilisateurs seront supprimés lors de leur prochaine connexion et remplacés par les rôles attribués via le paramètre Synchroniser les groupes Google.

Tester l'authentification des utilisateurs

Cliquez sur le bouton Test Google Authentication (Tester l'authentification Google) pour tester vos paramètres. Les tests redirigent vers le serveur OAuth de Google et ouvrent un onglet de navigateur. L'onglet affiche les informations suivantes :

  • Indique si Looker (Google Cloud Core) a pu communiquer avec le serveur et le valider.
  • Informations sur l'utilisateur que Looker (Google Cloud Core) obtient du serveur. Vous devez vérifier que le serveur renvoie les bons résultats.
  • Une trace montrant comment les informations ont été trouvées. Utilisez la trace pour résoudre le problème si les informations sont incorrectes. Si vous avez besoin d'informations supplémentaires, vous pouvez lire le fichier serveur XML brut.
  • Versions décodée et brute du jeton d'identité reçu. Ils peuvent être utilisés pour confirmer les informations utilisateur ainsi que la configuration Google.

Enregistrer et appliquer les paramètres

Une fois que vous avez saisi vos informations et que tous les tests sont réussis, cochez la case J'ai vérifié la configuration ci-dessus et je souhaite l'appliquer dans le monde entier, puis cliquez sur Envoyer pour enregistrer.

Ajouter des utilisateurs à une instance Looker (Google Cloud Core)

Une fois l'instance Looker (Google Cloud Core) créée, vous pouvez ajouter des utilisateurs via IAM. Pour ajouter des utilisateurs, procédez comme suit :

  1. Assurez-vous de disposer du rôle Administrateur de projet IAM ou d'un autre rôle vous permettant de gérer l'accès IAM.

  2. Accédez au projet de la console Google Cloud dans lequel réside l'instance Looker (Google Cloud Core).

  3. Accédez à la section IAM et administration > IAM de la console Google Cloud .

  4. Sélectionnez Accorder l'accès.

  5. Dans la section Ajouter des comptes principaux, ajoutez un ou plusieurs des éléments suivants :

    • Adresse e-mail du compte Google
    • un groupe Google
    • Un domaine Google Workspace

  6. Dans la section Attribuer des rôles, sélectionnez l'un des rôles IAM Looker (Google Cloud Core) prédéfinis ou un rôle personnalisé que vous avez ajouté.

  7. Cliquez sur Enregistrer.

  8. Informez les nouveaux utilisateurs de Looker (Google Cloud Core) que l'accès leur a été accordé et indiquez-leur l'URL de l'instance. Ils peuvent ensuite se connecter à l'instance, ce qui entraîne la création de leur compte. Aucune communication automatisée ne sera envoyée.

Si vous modifiez le rôle IAM d'un utilisateur, ce rôle est propagé à l'instance Looker (Google Cloud Core) en quelques minutes. Si un compte utilisateur Looker existe déjà, le rôle Looker de cet utilisateur reste inchangé.

Tous les utilisateurs doivent être provisionnés en suivant les étapes IAM décrites précédemment, à une exception près : vous pouvez créer des comptes de service réservés à l'API Looker dans l'instance Looker (Google Cloud Core).

Se connecter à Looker (Google Cloud Core) avec OAuth

La première fois qu'ils se connectent, ils sont invités à se connecter avec leur compte Google. Chaque utilisateur doit utiliser le même compte que celui indiqué par l'administrateur Looker dans le champ Ajouter des comptes principaux lorsqu'il lui a accordé l'accès. Les utilisateurs verront l'écran de consentement OAuth configuré lors de la création du client OAuth. Une fois que les utilisateurs ont accepté l'écran de consentement, leurs comptes sont créés dans l'instance Looker (Google Cloud Core) et ils sont connectés.

Ensuite, les utilisateurs seront automatiquement connectés à Looker (Google Cloud Core), sauf si leur autorisation expire ou est révoquée par l'utilisateur. Dans ces cas, les utilisateurs verront à nouveau l'écran de consentement OAuth et seront invités à autoriser l'accès.

Certains utilisateurs peuvent se voir attribuer des identifiants d'API pour récupérer un jeton d'accès à l'API. Si l'autorisation de ces utilisateurs expire ou est révoquée, leurs identifiants API cessent de fonctionner. Tous les jetons d'accès à l'API actuels cesseront également de fonctionner. Pour résoudre le problème, l'utilisateur doit réautoriser ses identifiants en se reconnectant à l'interface utilisateur Looker (Google Cloud Core) pour chaque instance Looker (Google Cloud Core) concernée. Vous pouvez également utiliser des comptes de service réservés aux API pour éviter les échecs d'autorisation des identifiants pour les jetons d'accès aux API.

Supprimer l'accès OAuth à Looker (Google Cloud Core)

Si vous disposez d'un rôle qui vous permet de gérer l'accès IAM, vous pouvez supprimer l'accès à une instance Looker (Google Cloud Core) en révoquant le rôle IAM qui l'a accordé. Si vous supprimez le rôle IAM d'un compte utilisateur, cette modification est propagée à l'instance Looker (Google Cloud Core) en quelques minutes. L'utilisateur ne pourra plus s'authentifier auprès de l'instance. Toutefois, le compte utilisateur apparaîtra toujours comme actif sur la page Utilisateurs. Pour supprimer le compte utilisateur de la page Utilisateurs, supprimez l'utilisateur dans l'instance Looker (Google Cloud Core).

Utiliser OAuth comme méthode d'authentification de secours

Si vous utilisez une autre méthode d'authentification, comme la fédération d'identité de personnel, SAML ou OpenID Connect (OIDC), vous pouvez configurer Google OAuth comme méthode d'authentification secondaire ou de secours. Cette configuration permet aux utilisateurs et aux administrateurs de continuer à s'authentifier avec des comptes Google s'ils ne peuvent pas accéder au fournisseur d'identité principal.

Configurer OAuth comme méthode de secours pour SAML ou OIDC

OAuth est la méthode d'authentification de secours lorsque SAML ou OIDC est la méthode d'authentification principale.

Pour configurer OAuth comme méthode de sauvegarde, accordez à chaque utilisateur Looker (Google Cloud Core) le rôle IAM approprié pour se connecter à l'instance.

Configurer OAuth comme méthode secondaire pour la fédération d'identité de personnel

Vous pouvez éventuellement configurer OAuth comme méthode d'authentification secondaire pour la fédération d'identité de personnel. Pour configurer OAuth comme méthode d'authentification secondaire, modifiez l'instance pour activer le paramètre Activer l'authentification OAuth secondaire.

Se connecter avec OAuth

Une fois la méthode de secours configurée, les utilisateurs peuvent y accéder en procédant comme suit :

  1. Sur la page de connexion, sélectionnez S'authentifier avec Google.
  2. Une boîte de dialogue s'affiche pour confirmer l'authentification Google. Sélectionnez Confirmer dans la boîte de dialogue.

Les utilisateurs peuvent ensuite se connecter à l'aide de leur compte Google. Lors de leur première connexion avec OAuth, ils seront invités à accepter l'écran de consentement OAuth configuré lors de la création de l'instance.

Étapes suivantes