Usar a federação de identidade de colaboradores para autenticação de usuários do Looker (Google Cloud Core)

A federação de identidade de colaboradores permite que você use um provedor de identidade externo (IdP) para autenticar usuários e grupos de usuários em uma instância do Looker (Google Cloud Core). Ao usar a federação de identidade de colaboradores, os usuários da sua organização podem usar o logon único (SSO) para acessar o Looker (Google Cloud Core) sem que você precise provisionar ou sincronizar contas do Google (contas do Cloud Identity ou do Google Workspace) para cada usuário.

A federação de identidade de colaboradores oferece suporte a IdPs externos que usam o OpenID Connect (OIDC) ou o SAML 2.0, como o ID do Microsoft Entra (antigo Azure AD), Okta, PingIdentity e outros.

Durante a prévia do recurso, apenas instâncias do Looker (Google Cloud Core) que usam conexões seguras públicas são aceitas.

Como a federação de identidade de colaboradores funciona com o Looker (Google Cloud Core)

Quando você configura a federação de identidade de colaboradores para uma instância do Looker (Google Cloud Core), o processo a seguir ocorre:

  1. Autenticação:um usuário navega até o URL da instância do Looker (Google Cloud Core). Se a configuração Ignorar página de login estiver ativada, o usuário será redirecionado automaticamente para o Google Cloud portal de login (https://auth.cloud.google/authorize), que o redireciona para o IdP externo para autenticação.
  2. Troca de token:depois que o usuário se autentica com o IdP, ele retorna uma declaração de autenticação para o Google Cloud Security Token Service (STS). O STS troca a declaração por um token de acesso federado e um token de ID.
  3. Autorização:o Looker (Google Cloud Core) verifica se o principal federado tem a permissão necessária do Identity and Access Management (IAM) (looker.instances.login) na instância.
  4. Provisionamento e atribuição de papéis:o Looker (Google Cloud Core) cria a conta de usuário no primeiro login (provisionamento Just-In-Time) e aplica mapeamentos de grupo para função e atributos de usuário com base nas declarações que recebe do IdP.

Antes de começar

Antes de configurar a federação de identidade de colaboradores para o Looker (Google Cloud Core), verifique se você tem as seguintes funções e configurações:

Papéis do IAM obrigatórios

Para configurar a federação de identidade de colaboradores e criar instâncias do Looker (Google Cloud Core), você precisa das seguintes funções:

APIs necessárias

Ative as APIs a seguir no Google Cloud projeto:

Etapa 1: configurar um pool de identidade de colaboradores e um provedor

Os pools e provedores de identidade de colaboradores são criados no Google Cloud nível da organização, não do projeto.

Conclua as etapas a seguir para configurar um pool de identidade de colaboradores e um provedor:

  1. Crie um pool de identidade de colaboradores seguindo as instruções na página de documentação Configurar a federação de identidade de colaboradores.
  2. Crie um provedor de pool de identidade de colaboradores para o IdP OIDC ou SAML 2.0:
    • Para provedores OIDC, consulte Configurar a federação de identidade de colaboradores do OIDC.
    • Para provedores SAML, consulte Configurar a federação de identidade de colaboradores do SAML 2.0.
    • Defina os seguintes mapeamentos de atributos imediatamente durante a criação do provedor:
      • E-mail:mapeie a declaração de e-mail do IdP para google.email. Esse mapeamento é obrigatório para identificação do usuário. A autenticação falhará se esse mapeamento estiver ausente.
      • Nome e sobrenome:mapeie as declarações de nome e sobrenome do IdP para attribute.given_name (nome) e attribute.family_name (sobrenome). Esses mapeamentos são obrigatórios para preencher os perfis de usuário do Looker. A autenticação falhará se esses mapeamentos estiverem ausentes.

  3. Opcionalmente, configure os seguintes mapeamentos de atributos também:

    • Grupos:mapeie a declaração de grupo do IdP (por exemplo, assertion.groups) para google.groups. Esse mapeamento é necessário se você planeja ativar o espelhamento de grupos e mapear grupos de IdP para funções do Looker. Para provedores OIDC, verifique se a configuração do provedor também solicita o escopo groups se o IdP exigir (consulte Configurar a federação de identidade de colaboradores para requisitos específicos do IdP).
    • Atributos personalizados: Mapeie declarações personalizadas do IdP para attribute.<attribute_name>. É possível usar esses atributos mapeados no Looker (Google Cloud Core) para parametrizar conexões de banco de dados e aplicar filtros de acesso a dados no nível da linha.

Configurar a duração estendida da sessão e a sincronização em segundo plano

Para oferecer suporte a sessões de navegador ininterruptas, entregas programadas de longa duração, acesso à chave de API do usuário e integrações de conector, siga estas etapas:

  1. Configure a sincronização de atributos em segundo plano no provedor de pool de força de trabalho para Google Cloud atualizar periodicamente os atributos do usuário e as associações de grupo em segundo plano:
    • Para provedores OIDC: configure o fluxo de código de autorização do OIDC com o escopo offline_access (que usa tokens de atualização para atualizar periodicamente os atributos do usuário e as associações de grupo) ou o provisionamento SCIM 2.0. Se os usuários pertencerem a um grande número de grupos que excedem os limites de tamanho do token OIDC, configure o provisionamento SCIM 2.0 para sincronizar as associações de grupo com Google Cloud.
    • Para provedores SAML:configure o provisionamento SCIM 2.0 no provedor de pool de força de trabalho. Como as declarações SAML não fornecem tokens de atualização de forma nativa, o SCIM 2.0 é necessário para ativar entregas e alertas programados off-line.

  2. Configure an política de duração estendida da sessão para o pool de força de trabalho usando vinculações de nuvem do Access Context Manager e defina a política como 90 dias (7.776.000 segundos).

    Essa política define a duração máxima da sessão e a validade do token de atualização como 90 dias. Se uma política de duração estendida da sessão não estiver configurada ou estiver definida para uma duração menor, a validade do token de atualização do pool de força de trabalho terá precedência sobre as configurações de duração da sessão do Looker, fazendo com que as sessões do navegador, as programações off-line, as chaves de API do usuário e os aplicativos conectados exijam uma nova autenticação quando o token de atualização expirar.

Etapa 2: conceder permissões do IAM aos principais da força de trabalho

Para permitir que os usuários da força de trabalho façam login na instância do Looker (Google Cloud Core), conceda o papel do IAM de usuário da instância do Looker (roles/looker.instanceUser) ou administrador do Looker (roles/looker.admin) aos principais ou grupos da força de trabalho.

É possível conceder papéis a usuários individuais, grupos inteiros ou todos os principais em um pool de força de trabalho pool usando os seguintes identificadores principais:

  • Usuário único da força de trabalho : 

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

  • Grupo de força de trabalho : 

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

  • Todos os principais em um pool de força de trabalho : 

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

Para mais informações sobre como atribuir papéis do IAM, consulte a página de documentação Controle de acesso do Looker (Google Cloud Core) com o IAM.

Etapa 3: selecionar a federação de identidade de colaboradores como o método de autenticação principal

É possível selecionar a federação de identidade de colaboradores como o método de autenticação principal ao criar uma instância do Looker (Google Cloud Core) ou editar uma instância atual.

Durante a criação da instância

Ao criar uma instância do Looker (Google Cloud Core), é possível selecionar a federação de identidade de colaboradores como o método de autenticação principal:

Console

  1. No console do Google Cloud, acesse a página Looker (Google Cloud Core).

    Acessar o Looker (Google Cloud Core)

  2. Clique em CRIAR INSTÂNCIA.
  3. Conclua a configuração do nome, da região e da edição da instância, conforme descrito na documentação para criar instâncias que usam conexões seguras públicas, conexões do Private Service Connect ou conexões de acesso a serviços privados.
  4. Na seção Autenticação, selecione Federação de identidade de colaboradores (SAML/OIDC) como o método de autenticação principal.
  5. Clique em Criar.

Para definir o OAuth como um método de autenticação secundário, edite a configuração da instância depois que ela for criada.

Ao editar uma instância atual

Se você tiver uma instância do Looker (Google Cloud Core), poderá editar a configuração da instância para selecionar a federação de identidade de colaboradores como o método de autenticação principal ou definir o OAuth como o método de autenticação secundário:

Console

  1. No console do Google Cloud, acesse a página Looker (Google Cloud Core).

    Acessar o Looker (Google Cloud Core)

  2. Clique no nome da instância que você quer editar.
  3. Na guia Detalhes da instância, clique em Editar.
  4. Na seção Autenticação, selecione Federação de identidade de colaboradores (SAML/OIDC) como o método de autenticação principal.
  5. (Opcional) Para permitir o OAuth como um método de autenticação secundário, ative a opção Ativar OAuth secundário.
  6. Clique em Salvar.

Etapa 4: configurar as definições de identidade de colaboradores no Looker

Depois que a instância do Looker (Google Cloud Core) for criada, um administrador poderá configurar mapeamentos de atributos do usuário, espelhamento de grupos e opções de login na página Autenticação de colaboradores do painel de administração do Looker.

  1. Faça login na instância do Looker (Google Cloud Core) com uma conta que tenha o papel de administrador do Looker.
  2. No menu de navegação à esquerda, selecione Administrador > Autenticação > Identidade de colaboradores.
  3. Configure as definições descritas nas seções a seguir.

Consulte a documentação da página Autenticação de colaboradores para mais informações sobre as seguintes configurações.

Mesclar contas de usuário

No campo Mesclar usuários usando, selecione os sistemas de autenticação em que as contas de usuário atuais serão mescladas quando um usuário fizer login pela primeira vez com a federação de identidade de colaboradores.

Os sistemas aceitos para mesclagem incluem o seguinte:

  • Google
  • SAML
  • OIDC

Ignorar página de login

A opção Ignorar página de login controla se os usuários não autenticados são redirecionados automaticamente para o portal de SSO da empresa:

  • Ativado (padrão) : quando os usuários navegam até o URL da instância, eles são redirecionados automaticamente para a tela de login do IdP sem ver a página de login do Looker.
  • Desativado:os usuários veem a página de login do Looker e podem escolher entre as opções de autenticação disponíveis.

Clique em Salvar configuração para aplicar as configurações.

Mapeamento de atributos do usuário

Mapeie as declarações da declaração do IdP para os atributos do usuário do Looker. Os atributos do usuário podem ser usados para muitas coisas, como parametrizar conexões de banco de dados e aplicar filtros de segurança no nível da linha.

  • Na seção Mapeamento de atributos, mapeie os atributos da força de trabalho do Google para atributos de usuário do Looker correspondentes (por exemplo, mapeando attribute.department para um atributo de usuário department no Looker).

Grupos e papéis

É possível gerenciar as funções do usuário por meio do espelhamento de grupos ou das atribuições de função padrão:

  • Espelhar grupos do IdP:quando essa configuração está ativada, o Looker (Google Cloud Core) cria grupos do Looker que espelham grupos transmitidos na declaração de token do IdP.
    • Na tabela Mapeamento de grupos , mapeie os nomes de grupos externos do IdP para grupos do Looker e atribua funções adequadas do Looker (como leitor, usuário ou desenvolvedor).
  • Função função do usuário do novo usuário:se o espelhamento de grupos não for usado ou não corresponder a um usuário, especifique a função padrão a ser concedida aos novos usuários no primeiro login.
  • Grupo padrão do novo usuário:se o espelhamento de grupos não for usado ou não corresponder a um usuário, especifique o grupo padrão a ser atribuído aos novos usuários.

Gerenciamento de sessões e validade do token

As sessões e os tokens de usuário no Looker (Google Cloud Core) são regidos pela duração da sessão e pela validade do token de atualização configurados na política do pool de identidade de colaboradores (como uma política de duração estendida da sessão):

  • Sessões do navegador: as configurações de duração da sessão do Looker oferecem suporte a sessões de até 30 dias ao usar sessões persistentes. No entanto, a validade do token de atualização do pool de identidade de colaboradores tem precedência se a validade for menor que a duração da sessão configurada no Looker. Quando o token de atualização expira, o usuário precisa fazer login novamente. Recomendamos que você defina uma validade de token de atualização de 90 dias na política de duração estendida da sessão.
  • Entregas e alertas programados (jobs off-line) : os jobs em segundo plano são executados enquanto o proprietário da programação tiver um token de IdP ativo. Se um criador de programação ou alerta não fizer login na instância por mais de 90 dias (ou a duração configurada na política de sessão do pool de força de trabalho), a sessão off-line vai expirar, e as entregas ou alertas programados de propriedade desse usuário serão pausados. Para retomar programações ou alertas pausados, o proprietário precisa fazer login na instância ou um administrador precisa atribuir a propriedade da programação.
  • Servidor e conectores OAuth do Looker:as integrações que usam o servidor OAuth do Looker (como o Data Studio, o Planilhas Conectadas e conectores de terceiros) usam um token de atualização de 30 dias (ou um token de atualização não expirado no Data Studio). Se a duração da sessão do pool de força de trabalho estiver definida como menos de 90 dias, os usuários poderão precisar fazer a autenticação novamente com o Looker quando a duração da sessão expirar.
  • Chaves de API do usuário:os tokens de acesso à API gerados por chaves de API do usuário são válidos por 1 hora e exigem uma sessão de IdP de usuário ativa. Se a sessão do IdP do usuário expirar (a cada 90 dias ou com base na duração da sessão do pool de força de trabalho), o usuário precisará fazer login na instância novamente para continuar usando as chaves de API.
  • Chaves de API da conta de serviço:os tokens de acesso à API da conta de serviço não são afetados pelas políticas de sessão do pool de força de trabalho.

A seguir