Como avaliar o impacto da consolidação da conta de usuário na federação

Se você planeja federar o Cloud Identity ou o G Suite com um provedor de identidade externo (IdP, na sigla em inglês), mas ainda precisa consolidar contas pessoais, este documento ajuda você a entender e avaliar a interação entre federação e consolidação. Este documento também mostra como configurar a federação de uma forma que não interfere na sua capacidade de consolidar contas pessoais existentes.

Interação entre federação e consolidação de contas de usuário

Em uma configuração federada, você conecta o Cloud Identity ou o G Suite a uma origem autorizada externa para que a origem autorizada possa provisionar automaticamente as contas de usuário no Cloud Identity ou no G Suite.

Esses elementos geralmente se aplicam a uma configuração federada:

  1. A origem autorizada é a única fonte de identidades.
  2. Não há contas de usuário no Cloud Identity ou no G Suite além das provisionadas pela origem autorizada.
  3. O provedor de identidade SAML não permite o Logon único (SSO, na sigla em inglês) do Google para outras identidades além das para as quais a origem autorizada provisionou contas de usuário.

Esses elementos refletem as práticas recomendadas para unir o Google Cloud a um provedor de identidade externo, mas causam problemas quando você quer migrar contas de consumidor existentes:

  1. As contas de consumidor existentes não se partem da origem autorizada. Essas contas já existem e agora precisam ser vinculadas a uma identidade conhecida pela origem autorizada.
  2. As contas pessoais existentes, depois de migradas para o Cloud Identity ou o G Suite, são contas de usuário que não foram aprovisionadas pela origem autorizada. A origem autorizada precisa reconhecer e "adotar" essas contas migradas.
  3. As identidades das contas pessoais existentes podem ser desconhecidas para o provedor de identidade SAML, mas elas ainda precisam ter permissão para usar o Logon único.

Para permitir que as contas pessoais existentes sejam consolidadas, você precisa configurar temporariamente a federação de uma forma que seja segura para a consolidação da conta.

Como tornar a federação segura para consolidar contas

A tabela a seguir lista os requisitos a serem considerados para tornar a federação segura para a consolidação da conta. Se você planeja usar um IdP externo, mas ainda precisa consolidar contas pessoais existentes, verifique se sua configuração atende a esses requisitos inicialmente. Depois de concluir a migração das contas pessoais existentes, você poderá alterar a configuração porque os requisitos não serão mais retidos.

Requisito Motivo
Permitir Logon único para identidades com contas pessoais A migração de uma conta pessoal requer uma transferência de conta. Um administrador do Cloud Identity ou do G Suite inicia a transferência da conta, mas, para concluir a transferência, o proprietário da conta de consumidor precisa autorizar a transferência. Como administrador, você tem controle limitado sobre quando o consentimento será expresso e, portanto, quando a transferência será realizada.

Depois que o proprietário expressa o consentimento e a transferência é concluída, todos os logins subsequentes estão sujeitos ao Logon único usando seu IdP externo.

Para que o Logon único seja bem-sucedido, independentemente de quando a transferência for concluída, verifique se o IdP externo permite logins únicos para as identidades de todas as contas pessoais que você planeja migrar.

Impedir o aprovisionamento automático de usuários para identidades com contas pessoais Se você provisionar uma conta de usuário para uma identidade que já tem uma conta pessoal, crie uma conta conflitante. Uma conta conflitante impede que você transfira a propriedade, a configuração e os dados associados da conta pessoal para o Cloud Identity ou o G Suite.

O comportamento padrão de muitos IdPs externos é criar contas de usuário proativamente no Cloud Identity ou no G Suite. Esse comportamento pode fazer com que contas conflitantes sejam criadas acidentalmente.

Ao evitar o aprovisionamento automático de usuários para identidades com contas pessoais existentes, você evita criar contas conflitantes acidentalmente e garante que as contas pessoais possam ser transferidas corretamente.

Se você identificou contas de consumidor sem uma identidade correspondente no IdP externo que você considera legítimas e quer migrar para o Cloud Identity ou o G Suite, verifique se a configuração de federação não interfere na sua capacidade de migrar essas contas pessoais.

Requisito Motivo
Impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo Se você tiver uma conta de usuário no Cloud Identity ou no G Suite que não tenha uma identidade correspondente no seu IdP externo, ele poderá considerá-la órfã e suspender ou excluí-la.

Ao impedir que o IdP externo suspenda ou exclua contas migradas sem corresponder à identidade no IdP externo, você evita perder a configuração e os dados associados às contas afetadas e garante que pode reconciliar as contas manualmente.

Como tornar a federação do Azure AD segura para a consolidação de contas

Se você pretende federar o Cloud Identity ou o G Suite com o Azure AD, use o app de galeria G Suite .

Quando você ativa o provisionamento, o Azure AD ignora contas existentes no Cloud Identity ou no G Suite que não têm uma contraparte no Azure AD. Portanto, o requisito de impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo é sempre atendida.

Dependendo de como você configurar o aplicativo de galeria, ainda será necessário fazer o seguinte:

Existem várias maneiras de atender a esses requisitos. Cada uma tem vantagens e desvantagens.

Abordagem 1: não configurar o provisionamento

Nessa abordagem, você configura o aplicativo de galeria para processar o Logon único, mas não configura o aprovisionamento automático de usuários. Ao não configurar o aprovisionamento de usuários, você impede o provisionamento automático de usuários para identidades com contas pessoais.

Para permitir o Logon único para identidades com contas pessoais, atribua o aplicativo a todas as identidades que possam precisar acessar os serviços do Google, mesmo que as contas pessoais existentes ainda estejam sujeitas à migração.

Para um usuário que já tem uma conta pessoal, a conta de usuário do Cloud Identity ou do G Suite correspondente é criada automaticamente quando a solicitação de transferência é aceita. Esse usuário pode usar o Logon único imediatamente.

Para usuários que não têm uma conta de usuário no Cloud Identity ou no G Suite, é necessário criar uma manualmente.

Embora essa abordagem atenda aos requisitos e seja menos complexa de configurar, ela vem com a limitação de que qualquer alteração de atributo ou suspensão de usuário realizada no Azure AD não será propagada para o Cloud Identity ou o G Suite.

Abordagem 2: dois aplicativos com atribuição manual

Nessa abordagem, você supera a limitação de ter que criar manualmente contas de usuário no G Suite ou no Cloud Identity para usuários que não têm uma conta. A ideia é usar dois apps de galeria, um para provisionamento e outro para Logon único:

  • O primeiro aplicativo é usado exclusivamente para provisionar usuários e grupos e tem o Logon único desativado. Ao atribuir usuários a esse aplicativo, você controla quais contas estão sendo provisionadas para o Cloud Identity ou o G Suite.
  • O segundo aplicativo é usado exclusivamente para conexão única e não está autorizado a provisionar usuários. Ao atribuir usuários a esse aplicativo, você controla quais usuários têm permissão para fazer logon.

Use esse dois aplicativos e atribua usuários da seguinte maneira:

Abordagem 3: dois aplicativos com a criação de usuário desativada

Ao configurar o provisionamento, você precisa autorizar o Azure AD a acessar o Cloud Identity ou o G Suite usando uma conta do Cloud Identity ou do G Suite. É melhor usar uma conta de superadministrador dedicada, exclusiva para esse fim, uma vez que essas contas estão isentas do Logon único. Como as configurações de SSO não são válidas para elas, o uso de senhas para login continuará sendo necessário.

No entanto, para esse cenário, é possível configurar o Azure AD para que seja usada uma conta mais restrita para migração, sem permissão para criar usuários. Dessa forma, você impede que o Azure provisione automaticamente contas de usuário para identidades com contas pessoais, independentemente dos usuários atribuídos ao aplicativo de provisionamento.

Uma conta de usuário de administrador restrita no Cloud Identity ou no G Suite precisa ter apenas os seguintes privilégios:

  • Unidades organizacionais > Leitura
  • Usuários > Leitura
  • Usuários > Atualização
  • Grupos

Uma desvantagem dessa abordagem é que você precisará criar contas no Cloud Identity ou no G Suite manualmente para usuários sem contas não gerenciadas.

Federar com o Azure AD: comparação

A tabela a seguir resume as abordagens.

Permitir Logon único para identidades com contas pessoais Impedir o aprovisionamento automático de usuários para identidades com contas pessoais Impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo Aprovisionamento automático de novas contas Atualizar automaticamente as contas migradas
Abordagem 1: sem provisionamento X X
Abordagem 2: dois aplicativos com atribuição manual Propenso a erros manuais
Abordagem 3: dois aplicativos com a criação de usuário desativada X

Como tornar a federação do Active Directory segura para a consolidação de contas

Se você planeja federar o Cloud Identity ou o G Suite com o Active Directory, pode usar o Google Cloud Directory Sync e os Serviços de federação do Active Directory (AD FS). Ao configurar o Cloud Directory Sync e o AD FS, você precisa fazer o seguinte:

Existem várias maneiras de atender a esses requisitos. Cada uma tem vantagens e desvantagens.

Abordagem 1: desativar o Cloud Directory Sync

Nessa abordagem, você configura o Logon único com o AD FS, mas não ativa o Cloud Directory Sync até terminar de migrar as contas de usuário não gerenciadas. Ao desativar o Cloud Directory Sync, você impede o provisionamento automático de usuários para identidades com contas pessoais.

Para permitir o Logon único para identidades com contas pessoais, crie uma política de controle de acesso personalizada no AD FS e atribua todas as identidades que possam precisar de acesso aos serviços do Google, mesmo que As contas pessoais existentes ainda estão sujeitas à migração.

Para um usuário que já tem uma conta pessoal, a conta de usuário do Cloud Identity ou do G Suite correspondente é criada automaticamente quando a solicitação de transferência é aceita. Ao usar a política de controle de acesso personalizado, você garante que o usuário possa usar imediatamente o Logon único.

Para usuários que não têm uma conta de usuário no Cloud Identity ou no G Suite, é necessário criar uma manualmente.

Embora essa abordagem atenda aos requisitos e seja menos complexa de configurar, ela vem com a limitação de que qualquer alteração de atributo ou suspensão de usuário realizada no Active Directory não será propagada para o Cloud Identity ou o G Suite.

Abordagem 2: Cloud Directory Sync com atribuição manual

Nessa abordagem, você supera a limitação de ter que criar manualmente contas de usuário no Cloud Identity ou no G Suite para usuários que não têm uma conta existente:

Uma limitação importante dessa abordagem é que não é possível impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo. Portanto, a abordagem é aplicável somente se você não tiver nenhuma conta de consumidor sem uma identidade correspondente no IdP externo.

Abordagem 2: não permitir a criação de usuários pelo Cloud Directory Sync

Ao configurar o provisionamento, você precisa autorizar o Cloud Directory Sync a acessar o Cloud Identity ou o G Suite. É melhor usar uma conta de superadministrador dedicada, exclusiva para esse fim, uma vez que essas contas estão isentas do Logon único. Como as configurações de SSO não são válidas para elas, o uso de senhas para login continuará sendo necessário.

No entanto, para esse cenário, é possível fazer com que o Cloud Directory Sync use uma conta mais restrita para a migração, que não permita a criação de usuários. Dessa forma, você impede que o Cloud Directory Sync provisione automaticamente contas de usuário para identidades com contas pessoais e exclua contas migradas sem uma identidade correspondente no IdP externo.

Uma conta de usuário de administrador restrita no Cloud Identity ou no G Suite deve ter apenas os seguintes privilégios:

  • Unidades organizacionais
  • Usuários > Leitura
  • Usuários > Atualização
  • Grupos
  • Gerenciamento de esquema
  • Gerenciamento de domínios

Uma desvantagem dessa abordagem é que você precisará criar contas no Cloud Identity ou no G Suite manualmente para usuários sem contas não gerenciadas.

Federar com o Active Directory: comparação

A tabela a seguir resume as abordagens.

Permitir Logon único para identidades com contas pessoais Impedir o aprovisionamento automático de usuários para identidades com contas pessoais Impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo Aprovisionamento automático de novas contas Atualizar automaticamente as contas migradas
Abordagem 1: não configurar o provisionamento X X
Abordagem 2: GCDS com atribuição manual Propenso a erros manuais X
Abordagem 2: proibir a criação de usuários pelo GCDS X

Como tornar a federação do Okta segura para consolidar contas

Para federar o Cloud Identity ou o G Suite com o Okta, use os aplicativos do G Suite ou do Google Cloud da biblioteca de aplicativos disponível na interface de administração do Okta. Como os aplicativos têm recursos complementares, talvez seja necessário usá-los em conjunto:

Quando você usa o aplicativo do G Suite para aprovisionamento, o Okta ignora todos os usuários existentes no Cloud Identity ou no G Suite que não têm uma versão correspondente. Portanto, o requisito de impedir a exclusão de contas migradas sem uma identidade correspondente no IdP é sempre atendido.

Dependendo de como configurar o Okta, você ainda precisará fazer o seguinte:

Existem várias maneiras de atender a esses requisitos. Cada uma tem vantagens e desvantagens.

Abordagem 1: não configurar o provisionamento

Nessa abordagem, você configura o aplicativo do G Suite ou do Google Cloud para lidar com o Logon único, mas não configura o provisionamento. Ao não configurar o aprovisionamento de usuários, você impede o aprovisionamento automático de usuários para identidades com contas pessoais.

Para permitir o Logon único para identidades com contas pessoais, atribua o aplicativo a todas as identidades que possam precisar acessar os serviços do Google, mesmo que as contas pessoais existentes ainda estejam sujeitas à migração. Os ícones do G Suite ou do Google Cloud aparecem na página inicial do Okta de todas as identidades atribuídas ao aplicativo. No entanto, o login falhará a menos que uma conta de usuário correspondente exista no lado do Google.

Para um usuário que já tem uma conta pessoal, a conta de usuário do Cloud Identity ou do G Suite correspondente é criada automaticamente quando a solicitação de transferência é aceita. Esse usuário pode usar o Logon único imediatamente.

Embora essa abordagem atenda aos requisitos e seja menos complexa de configurar, ela vem com a limitação de que qualquer alteração de atributo ou suspensão de usuário realizada no Okta não será propagada para o Cloud Identity ou o G Suite. Outra desvantagem dessa abordagem é que você precisa criar contas manualmente no Cloud Identity ou no G Suite para todos os usuários que não têm uma conta pessoal.

Abordagem 2: provisão com atribuição manual

Nessa abordagem, você configura o aplicativo do G Suite para lidar com o Logon único e o provisionamento, mas só ativa os seguintes recursos de provisionamento:

  • Criar usuários
  • Atualizar atributos do usuário
  • Desativar usuários

Para adicionar o ícone do Google Cloud às páginas iniciais dos usuários do Okta, é possível configurar o aplicativo do Google Cloud. Ao atribuir identidades ao aplicativo, inclua as identidades que precisam de acesso aos serviços do Google, mas exclua todas as identidades conhecidas por ter uma conta de consumidor. Dessa forma, você impede o aprovisionamento automático de usuários para identidades com contas pessoais.

Assim que um usuário aceitar uma solicitação de transferência, atribua-o ao aplicativo para que ele possa usar o Logon único e acessar o G Suite ou o Google Cloud.

Uma desvantagem dessa abordagem é que qualquer erro que você cometa na atribuição pode levar imediatamente à criação de uma conta conflitante, o que torna essa abordagem muito mais arriscada do que outras.

O uso dessa abordagem também pode levar a bloqueios temporários de contas migradas, o que é outra desvantagem. Depois de aceitar uma solicitação de transferência, para qualquer login subsequente o usuário precisará usar o Okta. Essas tentativas de login apresentarão falha até que você tenha atribuído o usuário ao aplicativo no Okta.

Abordagem 3: provisão com a criação de usuário desativada

Nessa abordagem, você configura o G Suite para lidar com o Logon único e o provisionamento, mas ativa apenas os seguintes recursos de provisionamento:

  • Atualizar atributos do usuário
  • Desativar usuários

Você deixa a opção Criar usuários desativada.

Para adicionar o ícone do Google Cloud às páginas iniciais dos usuários do Okta, é possível configurar o aplicativo do Google Cloud. Você atribui todas as identidades que precisam acessar os serviços do Google ao app. Inclua identidades com contas pessoais existentes para permitir o Logon único para identidades com contas pessoais.

Ao impedir que o Okta crie contas, você impede que o Okta provisione automaticamente contas de usuário para identidades com contas pessoais. Ao mesmo tempo, essa configuração ainda permite que o Okta propague alterações de atributos e suspensões de usuários para o Cloud Identity ou o G Suite.

Para identidades que não têm uma conta de usuário correspondente no Cloud Identity ou no G Suite, o Okta pode exibir uma mensagem de erro no Admin Console do Okta:

Mensagem de erro do Okta.

Para um usuário que já tem uma conta pessoal, a conta de usuário do Cloud Identity ou do G Suite correspondente é criada automaticamente quando a solicitação de transferência é aceita. Esse usuário pode usar o Logon único imediatamente. Embora a conta de usuário esteja funcionando no momento, o Okta talvez ainda não exiba um ícone na página inicial do usuário e continue exibindo a mensagem de erro na IU do administrador. Para corrigir isso, repita a tarefa de atribuição no painel do administrador do Okta:

Essa abordagem impede que o Okta provisione automaticamente contas de usuário para identidades com contas pessoais, mas ainda permite Logon único para identidades com contas pessoais. A abordagem também é menos propensa a erros de configuração acidentais do que a segunda abordagem. Uma desvantagem é que, para usuários sem contas pessoais, você precisa criar manualmente contas de usuário no Cloud Identity ou no G Suite.

Abordagem 4: dois aplicativos com atribuição manual

É possível superar algumas das desvantagens das abordagens anteriores usando dois aplicativos, um para provisionamento e outro para Logon único:

  • Configure o aplicativo G Suite para lidar apenas com provisionamento. A funcionalidade de Logon único do aplicativo não é usada. Ao atribuir usuários a esse aplicativo, você controla quais contas estão sendo provisionadas para o Cloud Identity ou o G Suite. Para garantir que esse aplicativo fique efetivamente oculto para os usuários, ative a opção Não exibir ícone do aplicativo aos usuários.
  • Configure o aplicativo Google Cloud ou outra instância do aplicativo G Suite somente para fins de Logon único. Ao atribuir usuários a este aplicativo, você controla quem tem permissão para fazer login e quem vê o ícone do Google Cloud na página inicial do Okta.

Use esse dois aplicativos e atribua usuários da seguinte maneira:

Federar com o Okta: comparação

A tabela a seguir resume as abordagens.

Permitir Logon único para identidades com contas pessoais Impedir o aprovisionamento automático de usuários para identidades com contas pessoais Impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo Aprovisionamento automático de novas contas Atualizar automaticamente as contas migradas
Abordagem 1: sem provisionamento X X
Abordagem 2: provisão com atribuição manual X Arriscado
Abordagem 3: provisão com a criação de usuário desativada X
Abordagem 4: dois aplicativos com atribuição manual Arriscado

A seguir