Utiliser la fédération d'identité de personnel pour l'authentification des utilisateurs Looker (Google Cloud Core)

La fédération des identités des employés vous permet d'utiliser un fournisseur d'identité externe (IdP) pour authentifier des utilisateurs et des groupes d'utilisateurs dans une instance Looker (Google Cloud Core). Grâce à la fédération des identités des employés, les utilisateurs de votre organisation peuvent utiliser l'authentification unique (SSO) pour accéder à Looker (Google Cloud Core) sans que vous ayez à provisionner ni à synchroniser des comptes Google (comptes Cloud Identity ou Google Workspace) pour chaque utilisateur.

La fédération des identités des employés est compatible avec les fournisseurs d'identité externes qui utilisent OpenID Connect (OIDC) ou SAML 2.0, tels que Microsoft Entra ID (anciennement Azure AD), Okta, PingIdentity, etc.

Pendant la preview de la fonctionnalité, seules les instances Looker (Google Cloud Core) qui utilisent des connexions sécurisées publiques sont compatibles.

Fonctionnement de la fédération des identités des employés avec Looker (Google Cloud Core)

Lorsque vous configurez la fédération des identités des employés pour une instance Looker (Google Cloud Core), le processus suivant se produit :

  1. Authentification : un utilisateur accède à l'URL de votre instance Looker (Google Cloud Core). Si le paramètre Contourner la page de connexion est activé, l'utilisateur est automatiquement redirigé vers le Google Cloud portail de connexion (https://auth.cloud.google/authorize), qui le redirige vers votre fournisseur d'identité externe pour l'authentification.
  2. Échange de jetons : une fois que l'utilisateur s'est authentifié auprès de votre fournisseur d'identité, celui-ci renvoie une assertion d'authentification au Google Cloud service de jetons de sécurité (STS). Le STS échange l'assertion contre un jeton d'accès fédéré et un jeton d'ID.
  3. Autorisation : Looker (Google Cloud Core) vérifie que le compte principal fédéré dispose de l'autorisation Identity and Access Management (IAM) requise (looker.instances.login) sur l'instance.
  4. Provisionnement et attribution de rôles : Looker (Google Cloud Core) crée le compte utilisateur lors de la première connexion (provisionnement juste à temps) et applique les mappages de groupe à rôle et les attributs utilisateur en fonction des revendications qu'il reçoit de votre fournisseur d'identité.

Avant de commencer

Avant de configurer la fédération des identités des employés pour Looker (Google Cloud Core), assurez-vous de disposer des rôles et configurations suivants :

Rôles IAM requis

Pour configurer la fédération des identités des employés et créer des instances Looker (Google Cloud Core), vous avez besoin des rôles suivants :

API requises

Activez les API suivantes dans votre Google Cloud projet :

Étape 1 : Configurer un pool et un fournisseur d'identités des employés

Les pools et fournisseurs d'identités des employés sont créés au niveau de l' Google Cloud organisation, et non au niveau du projet.

Pour configurer un pool et un fournisseur d'identités des employés, procédez comme suit :

  1. Créez un pool d'identités des employés en suivant les instructions de la page de documentation Configurer la fédération des identités des employés.
  2. Créez un fournisseur de pool d'identités des employés pour votre fournisseur d'identité OIDC ou SAML 2.0 :
    • Pour les fournisseurs OIDC, consultez Configurer la fédération des identités des employés OIDC.
    • Pour les fournisseurs SAML, consultez Configurer la fédération des identités des employés SAML 2.0.
    • Définissez les mappages d'attributs suivants immédiatement lors de la création du fournisseur :
      • Adresse e-mail : mappez la revendication d'adresse e-mail de votre fournisseur d'identité sur google.email. Ce mappage est obligatoire pour l'identification des utilisateurs. L'authentification échouera si ce mappage est manquant.
      • Nom et prénom : mappez les revendications de nom et de prénom de votre fournisseur d'identité sur attribute.given_name (prénom) et attribute.family_name (nom). Ces mappages sont obligatoires pour renseigner les profils utilisateur Looker. L'authentification échouera si ces mappages sont manquants.

  3. Vous pouvez également configurer les mappages d'attributs suivants :

    • Groupes : mappez la revendication de groupe de votre fournisseur d'identité (par exemple, assertion.groups) sur google.groups. Ce mappage est obligatoire si vous prévoyez d'activer la mise en miroir des groupes et de mapper les groupes du fournisseur d'identité sur les rôles Looker. Pour les fournisseurs OIDC, assurez-vous que la configuration de votre fournisseur demande également le champ d'application groups si votre fournisseur d'identité l'exige (consultez Configurer la fédération des identités des employés pour les exigences spécifiques au fournisseur d'identité).
    • Attributs personnalisés : mappez les revendications personnalisées du fournisseur d'identité sur attribute.<attribute_name>. Vous pouvez utiliser ces attributs mappés dans Looker (Google Cloud Core) pour paramétrer les connexions à la base de données et appliquer des filtres d'accès aux données au niveau des lignes.

Configurer une durée de session étendue et la synchronisation en arrière-plan

Pour prendre en charge les sessions de navigateur ininterrompues, les livraisons programmées de longue durée, l'accès aux clés API utilisateur et les intégrations de connecteurs, procédez comme suit :

  1. Configurez la synchronisation des attributs en arrière-plan sur le fournisseur de votre pool d'employés afin qu'il Google Cloud puisse actualiser périodiquement les attributs utilisateur et les appartenances aux groupes en arrière-plan :
    • Pour les fournisseurs OIDC : configurez le flux de code d'autorisation OIDC avec le champ d'application offline_access (qui utilise des jetons d'actualisation pour actualiser périodiquement les attributs utilisateur et les appartenances aux groupes) ou le provisionnement SCIM 2.0. Si les utilisateurs appartiennent à un grand nombre de groupes qui dépassent les limites de taille des jetons OIDC, configurez le provisionnement SCIM 2.0 pour synchroniser les appartenances aux groupes avec Google Cloud.
    • Pour les fournisseurs SAML : configurez le provisionnement SCIM 2.0 sur le fournisseur de votre pool d'employés. Étant donné que les assertions SAML ne fournissent pas de jetons d'actualisation de manière native, SCIM 2.0 est requis pour activer les livraisons et les alertes programmées hors connexion.

  2. Configurez une règle de durée de session étendue pour votre pool d'employés à l'aide des liaisons cloud Access Context Manager, et définissez la règle sur 90 jours (7 776 000 secondes).

    Cette règle définit la durée maximale de la session et la validité du jeton d'actualisation sur 90 jours. Si une règle de durée de session étendue n'est pas configurée ou si elle est définie sur une durée plus courte, la validité du jeton d'actualisation du pool d'employés est prioritaire sur les paramètres de durée de la session de Looker , ce qui oblige les sessions de navigateur, les programmations hors connexion, les clés API utilisateur et les applications connectées à nécessiter une nouvelle authentification à l'expiration du jeton d'actualisation.

Étape 2 : Accorder des autorisations IAM aux comptes principaux des employés

Pour permettre aux utilisateurs des employés de se connecter à votre instance Looker (Google Cloud Core), accordez le rôle IAM Utilisateur d'instance Looker (roles/looker.instanceUser) ou Administrateur Looker (roles/looker.admin) à vos comptes principaux ou groupes d'employés.

Vous pouvez accorder des rôles à des utilisateurs individuels, à des groupes entiers ou à tous les comptes principaux d'un pool d'employésà l'aide des identifiants principaux suivants :

  • Utilisateur unique des employés : 

    principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_ID

  • Groupe d'employés : 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID

  • Tous les comptes principaux d'un pool d'employés : 

    principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/*

Pour en savoir plus sur l'attribution des rôles IAM, consultez la page de documentation Contrôle des accès avec IAM dans Looker (Google Cloud Core).

Étape 3 : Sélectionner la fédération des identités des employés comme méthode d'authentification principale

Vous pouvez sélectionner la fédération des identités des employés comme méthode d'authentification principale lorsque vous créez une instance Looker (Google Cloud Core) ou en modifiant une instance existante.

Lors de la création d'une instance

Lorsque vous créez une instance Looker (Google Cloud Core), vous pouvez sélectionner la fédération des identités des employés comme méthode d'authentification principale :

Console

  1. Dans la console Google Cloud, accédez à la page Looker (Google Cloud Core).

    Accéder à Looker (Google Cloud Core)

  2. Cliquez sur CRÉER UNE INSTANCE.
  3. Configurez le nom, la région et l'édition de l'instance comme décrit dans la documentation sur la création d'instances qui utilisent des connexions sécurisées publiques, des connexions Private Service Connect ou des connexions d'accès aux services privés.
  4. Dans la section Authentification, sélectionnez Fédération des identités des employés (SAML/OIDC) comme méthode d'authentification principale.
  5. Cliquez sur Créer.

Pour définir OAuth comme méthode d'authentification secondaire, modifiez la configuration de l'instance une fois celle-ci créée.

Lors de la modification d'une instance existante

Si vous disposez d'une instance Looker (Google Cloud Core), vous pouvez modifier sa configuration pour sélectionner la fédération des identités des employés comme méthode d'authentification principale ou définir OAuth comme méthode d'authentification secondaire :

Console

  1. Dans la console Google Cloud, accédez à la page Looker (Google Cloud Core).

    Accéder à Looker (Google Cloud Core)

  2. Cliquez sur le nom de l'instance que vous souhaitez modifier.
  3. Dans l'onglet Détails de l'instance, cliquez sur Modifier.
  4. Dans la section Authentification, sélectionnez Fédération des identités des employés (SAML/OIDC) comme méthode d'authentification principale.
  5. (Facultatif) Pour autoriser OAuth comme méthode d'authentification secondaire, activez le bouton Activer l'authentification OAuth secondaire.
  6. Cliquez sur Enregistrer.

Étape 4 : Configurer les paramètres de la fédération des identités des employés dans Looker

Une fois votre instance Looker (Google Cloud Core) créée, un administrateur peut configurer les mappages d'attributs utilisateur, la mise en miroir des groupes et les options de connexion sur la page Authentification des employés du panneau d'administration de Looker.

  1. Connectez-vous à votre instance Looker (Google Cloud Core) avec un compte disposant du rôle Looker Administrateur.
  2. Dans le menu de navigation de gauche, sélectionnez Administrateur > Authentification > Identité des employés.
  3. Configurez les paramètres décrits dans les sections suivantes.

Pour en savoir plus sur les paramètres suivants, consultez la documentation de la page Authentification des employés.

Fusionner des comptes utilisateur

Dans le champ Fusionner les utilisateurs à l'aide de, sélectionnez les systèmes d'authentification à partir desquels les comptes utilisateur existants doivent être fusionnés lorsqu'un utilisateur se connecte pour la première fois avec la fédération des identités des employés.

Les systèmes compatibles pour la fusion sont les suivants :

  • Google
  • SAML
  • OIDC

Contourner la page de connexion

L'option Contourner la page de connexion permet de contrôler si les utilisateurs non authentifiés sont automatiquement redirigés vers le portail d'authentification unique de votre entreprise :

  • Activé (par défaut) : lorsque les utilisateurs accèdent à l'URL de votre instance, ils sont automatiquement redirigés vers l'écran de connexion de votre fournisseur d'identité sans voir la page de connexion Looker.
  • Désactivé : les utilisateurs voient la page de connexion Looker et peuvent choisir parmi les options d'authentification disponibles.

Cliquez sur Enregistrer la configuration pour appliquer vos paramètres.

Mappage des attributs utilisateur

Mappez les revendications de votre assertion de fournisseur d'identité sur les attributs utilisateur Looker. Les attributs utilisateur peuvent être utilisés pour de nombreuses choses, par exemple pour paramétrer les connexions à la base de données et appliquer des filtres de sécurité au niveau des lignes.

  • Dans la section Mappage des attributs, mappez les attributs des employés Google sur les attributs utilisateur Looker correspondants (par exemple, mappez attribute.department sur un attribut utilisateur department dans Looker).

Groupes et rôles

Vous pouvez gérer les rôles utilisateur via la mise en miroir des groupes ou les attributions de rôles par défaut :

  • Mettre en miroir les groupes du fournisseur d'identité : lorsque ce paramètre est activé, Looker (Google Cloud Core) crée des groupes Looker qui mettent en miroir les groupes transmis dans l'assertion de jeton du fournisseur d'identité.
    • Dans le tableau Mappage des groupes, mappez les noms de groupes de fournisseurs d'identité externes sur les groupes Looker et attribuez les rôles Looker appropriés (par exemple, Lecteur, Utilisateur ou Développeur).
  • Rôle par défaut du nouvel utilisateur : si la mise en miroir des groupes n'est pas utilisée ou ne correspond pas à un utilisateur, spécifiez le rôle par défaut à accorder aux nouveaux utilisateurs lors de leur première connexion.
  • Groupe par défaut du nouvel utilisateur : si la mise en miroir des groupes n'est pas utilisée ou ne correspond pas à un utilisateur, spécifiez le groupe par défaut à attribuer aux nouveaux utilisateurs.

Gestion des sessions et validité des jetons

Les sessions et les jetons utilisateur dans Looker (Google Cloud Core) sont régis par la durée de la session et la validité du jeton d'actualisation configurées dans la règle de votre pool d'identités des employés (par exemple, une règle de durée de session étendue) :

  • Sessions de navigateur : les paramètres de durée de la session de Looker sont compatibles avec les sessions d'une durée maximale de 30 jours lorsque vous utilisez des sessions persistantes. Toutefois, la validité du jeton d'actualisation du pool d'identités des employés est prioritaire si elle est inférieure à la durée de la session configurée dans Looker. Lorsque le jeton d'actualisation expire, l'utilisateur doit se reconnecter. Nous vous recommandons de définir une validité de jeton d'actualisation de 90 jours dans votre règle de durée de session étendue.
  • Livraisons et alertes programmées (jobs hors connexion) : les jobs en arrière-plan s'exécutent tant que le propriétaire de la programmation dispose d'un jeton de fournisseur d'identité actif. Si un créateur de programmation ou d'alerte ne se connecte pas à l'instance pendant plus de 90 jours (ou la durée configurée dans la règle de session de votre pool d'employés), sa session hors connexion expire et les livraisons ou alertes programmées appartenant à cet utilisateur sont mises en pause. Pour reprendre les programmations ou alertes mises en pause, le propriétaire doit se connecter à l'instance ou un administrateur doit attribuer la propriété de la programmation.
  • Serveur et connecteurs OAuth Looker : les intégrations qui utilisent le serveur OAuth Looker (telles que Data Studio, les feuilles connectées et les connecteurs tiers) utilisent un jeton d'actualisation de 30 jours (ou un jeton d'actualisation sans expiration dans Data Studio). Si la durée de la session du pool d'employés est inférieure à 90 jours, les utilisateurs devront peut-être se réauthentifier auprès de Looker à l'expiration de la durée de la session.
  • Clés API utilisateur : les jetons d'accès à l'API générés par les clés API utilisateur sont valides pendant une heure et nécessitent une session de fournisseur d'identité utilisateur active. Si la session de fournisseur d'identité de l'utilisateur expire (tous les 90 jours ou en fonction de la durée de session du pool d'employés), l'utilisateur doit se reconnecter à l'instance pour continuer à utiliser ses clés API.
  • Clés API de compte de service : les jetons d'accès à l'API de compte de service ne sont pas affectés par les règles de session du pool d'employés.

Étape suivante