Se você planeja federar o Cloud Identity ou o Google Workspace com um provedor de identidade externo (IdP), mas ainda precisa consolidar contas pessoais atuais, 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 Google Workspace a uma origem autoritativa externa para que a origem autoritativa possa provisionar automaticamente as contas de usuário no Cloud Identity ou no Google Workspace.
Esses elementos geralmente se aplicam a uma configuração federada:
- A origem autorizada é a única fonte de identidades.
- Não há contas de usuário no Cloud Identity ou no Google Workspace além das provisionadas pela origem autorizada.
- 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:
- 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.
- As contas pessoais existentes, depois de migradas para o Cloud Identity ou o Google Workspace, são contas de usuário que não foram aprovisionadas pela origem autorizada. A origem autorizada precisa reconhecer e "adotar" essas contas migradas.
- 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 a consolidação de 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 atuais, deve verificar inicialmente se sua configuração atende a esses requisitos. 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 Google Workspace inicia
a transferência da conta, mas, para concluir a transferência, o proprietário da
conta pessoal 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 Google Workspace.
O comportamento padrão de muitos IdPs externos é criar contas de usuário proativamente no Cloud Identity ou no Google Workspace. 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 pessoais sem uma identidade correspondente no IdP externo que você considera legítimas e quer migrar para o Cloud Identity ou o Google Workspace, deve verificar 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
Google Workspace 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 Microsoft Entra ID (antigo Azure AD) segura para a consolidação de contas
Se você planeja federar o Cloud Identity ou o Google Workspace com o Microsoft Entra ID (antigo Azure AD), use o app de galeria do Google Workspace.
Quando você ativa o provisionamento, o Microsoft Entra ID ignora as contas atuais no Cloud Identity ou no Google Workspace que não têm uma contraparte no Microsoft Entra ID. Portanto, o requisito de impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo é sempre atendido.
Dependendo de como você configurar o aplicativo de galeria, ainda será necessário fazer o seguinte:
- Permitir Logon único para identidades com contas pessoais.
- Impedir o aprovisionamento automático de usuários para identidades com contas pessoais.
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 Google Workspace 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 Google Workspace, é 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 Microsoft Entra ID não será propagada para o Cloud Identity ou o Google Workspace.
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 Cloud Identity ou no Google Workspace para usuários que não têm uma conta existente: 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 Google Workspace.
- 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:
- Atribua todas as identidades que precisam acessar os serviços do Google ao app de Logon único. Inclua identidades com contas pessoais existentes para permitir o Logon único para identidades com contas pessoais.
- Ao atribuir identidades ao aplicativo de aprovisionamento, 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.
Abordagem 3: dois aplicativos com a criação de usuário desativada
Ao configurar o provisionamento, você precisa autorizar o Microsoft Entra ID a acessar o Cloud Identity ou o Google Workspace usando uma conta do Cloud Identity ou do Google Workspace. É 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 Microsoft Entra ID use uma conta mais restrita para migração, que não permita que o Microsoft Entra ID crie 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 administrador restrita no Cloud Identity ou no Google Workspace deve 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 Google Workspace manualmente para usuários sem contas não gerenciadas.
Federação com o Microsoft Entra ID: 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 | ✅ |
Tornar a federação do Active Directory segura para a conta
Se você quiser federar o Cloud Identity ou o Google Workspace com o Active Directory, use o Google Cloud Directory Sync (GCDS) e os Serviços de Federação do Active Directory (AD FS). Ao configurar o GCDS e o AD FS, você precisa verificar o seguinte:
- 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.
Existem várias maneiras de atender a esses requisitos. Cada uma tem vantagens e desvantagens.
Abordagem 1: desativar o GCDS
Nessa abordagem, você configura o logon único com o AD FS, mas só habilita o GCDS depois de migrar as contas de usuário não gerenciadas. Ao desativar o GCDS, 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 eventualmente precisar de acesso aos serviços do Google, mesmo que as contas pessoais atuais 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 Google Workspace 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 Google Workspace, é 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 Google Workspace.
Abordagem 2: GCDS 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 Google Workspace para usuários que não têm uma conta existente:
Equivalente à abordagem 1, você permite o logon único para identidades com contas pessoais criando uma política de controle de acesso personalizada no AD FS e atribuindo todas as identidades que podem eventualmente precisar de acesso aos serviços do Google, mesmo que as contas pessoais atuais ainda estejam sujeitas à migração.
Crie um grupo no Active Directory que reflita as contas de usuário que você quer provisionar automaticamente no GCDS. Na lista de membros, inclua as identidades que precisam de acesso aos serviços do Google, mas exclua todas as identidades conhecidas por ter uma conta de consumidor.
Configure o GCDS para provisionar contas de usuário apenas para identidades que são membros desse grupo. Dessa forma, você impede o aprovisionamento automático de usuários para identidades com contas pessoais.
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 3: proibir a criação de usuários pelo GCDS
Ao configurar o provisionamento, você precisa autorizar o GCDS a acessar o Cloud Identity ou o Google Workspace. É 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, nesse caso, você pode configurar o GCDS para usar uma conta mais restrita para a migração, que não permita a criação de usuários. Dessa forma, você impede que o GCDS 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 administrador restrita no Cloud Identity ou no Google Workspace 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 Google Workspace manualmente para usuários sem contas não gerenciadas.
Federação 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 3: proibir a criação de usuários pelo GCDS | ✅ | ✅ | ✅ | X | ✅ |
Como tornar a federação do Okta segura para a consolidação de contas
Para federar o Cloud Identity ou o Google Workspace com o Okta, use o app do Google Workspace que está no catálogo de apps do Okta. Esse app pode processar o logon único e provisionar usuários e grupos para o Cloud Identity ou o Google Workspace.
Quando você usa o app do Google Workspace para provisionamento, o Okta ignora todos os usuários atuais no Cloud Identity ou no Google Workspace que não têm uma contraparte no Okta. Portanto, o requisito de impedir a exclusão de contas migradas sem uma identidade correspondente no IdP externo sempre é atendido.
Dependendo de como configurar o Okta, você ainda precisará fazer o seguinte:
- Permitir Logon único para identidades com contas pessoais.
- Impedir o aprovisionamento automático de usuários para identidades com contas pessoais.
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 Google Workspace para processar 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 Google Workspace 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 Google Workspace 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 Google Workspace. Outra desvantagem dessa abordagem é que você precisa criar contas manualmente no Cloud Identity ou no Google Workspace 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 Google Workspace 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
Ao atribuir identidades ao aplicativo, inclua aquelas que precisam de acesso aos Serviços do Google, mas exclua todas aquelas que você sabe que têm contas pessoais. 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 Google Workspace 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 Google Workspace 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
Deixe a opção Criar usuários desativada e atribua todas as identidades que precisam acessar Serviços do Google ao aplicativo. Inclua identidades com contas pessoais 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 Google Workspace.
Para identidades que não têm uma conta de usuário correspondente no Cloud Identity ou no Google Workspace, o Okta pode exibir uma mensagem de erro no Admin Console do Okta:
Para um usuário que já tem uma conta pessoal, a conta de usuário do Cloud Identity ou do Google Workspace 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 Google Workspace.
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 uma instância do aplicativo do Google Workspace para que processe apenas o 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 Google Workspace. 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 outra instância do aplicativo do Google Workspace somente para fins de logon único. Ao atribuir usuários a esse aplicativo, você controla quem tem permissão para fazer login.
Use esse dois aplicativos e atribua usuários da seguinte maneira:
- Atribua todas as identidades que precisam acessar os serviços do Google ao app de Logon único. Inclua identidades com contas pessoais existentes para permitir o Logon único para identidades com contas pessoais.
Ao atribuir identidades ao aplicativo de aprovisionamento, 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.
Sempre que um usuário aceitar uma solicitação de transferência, atribua o usuário ao aplicativo também.
Federação 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 | Risky | ✅ | ✅ | ✅ |
| Abordagem 3: provisão com a criação de usuário desativada | ✅ | ✅ | ✅ | X | ✅ |
| Abordagem 4: dois aplicativos com atribuição manual | ✅ | Risky | ✅ | ✅ | ✅ |
A seguir
- Confira como é possível configurar a federação com o Active Directory ou com o Microsoft Entra ID.
- Inicie o processo de integração preparando as contas do Cloud Identity ou do Google Workspace.