Migração

A migração para FoxIDs normalmente combina migração de aplicativos, migração de usuários e uma transição controlada entre a plataforma de identidade existente e os FoxIDs. Planeje esses fluxos de trabalho juntos para que identificadores, claims, comportamento de autenticação e opções de reversão permaneçam consistentes durante toda a transição.

Os locatários do FoxIDs oferecem suporte a ambientes separados. Use ambientes dedicados de desenvolvimento, teste, preparação e produção para configurar e validar fluxos de migração em paralelo sem alterar prematuramente o ambiente de produção.

Avalie a plataforma de identidade existente

Comece gravando:

Aplicações, APIs e ambientes conectados à plataforma existente.
Configurações OpenID Connect, OAuth 2.0, SAML 2.0 e WS-Federation.
Provedores de identidade, métodos de autenticação e requisitos de autenticação multifatorial.
Identificadores de usuários, perfis, claims, grupos, funções e atribuições de acesso.
Opções de armazenamento, validação e redefinição de senha disponíveis na plataforma de origem.
Certificados, metadados, URLs de redirecionamento, comportamento de logout e tempos de vida de token.
Requisitos de monitoramento, auditoria e reversão para transição.

A origem pode ser AD FS, Active Directory, Keycloak, Auth0, Okta, Microsoft Entra ID ou outro provedor de identidade ou repositório de usuário personalizado. O caminho de migração disponível depende dos protocolos, capacidades de exportação e opções de validação de senha fornecidas por essa fonte.

Migração de aplicativos

Migre aplicativos por protocolo e ambiente, em vez de tratar o patrimônio como uma transição única.

Registre o aplicativo em um ambiente FoxIDs que não seja de produção.
Reproduza as claims, escopos, identificadores, certificados e comportamento de logout necessários.
Conecte o provedor de identidade existente como método de autenticação quando a autenticação paralela for necessária.
Teste o fluxo completo de login, token e logout com usuários representativos e integrações.
Mova um grupo controlado ou um aplicativo por vez antes de uma implementação mais ampla.

FoxIDs ponte de protocolo permitem que um aplicativo retenha seu protocolo atual enquanto o lado do provedor de identidade muda. Isso é útil quando aplicativos OpenID Connect modernos e aplicativos SAML 2.0 ou WS-Federation existentes devem operar durante o mesmo período de migração.

Perfis de usuário e identificadores

Decida qual identificador permanece estável antes de importar ou criar usuários. Endereços de e-mail, números de telefone e nomes de usuário podem mudar, portanto, use um identificador de origem estável onde a integração o suportar.

Mapeie as informações do usuário necessárias após a migração:

Propriedades de perfil de usuário e identificadores de login.
Claims usadas por aplicativos e APIs.
Grupos, funções e atribuições de acesso.
Requisitos de autenticação multifator e abordagem de inscrição ou recuperação após a migração.
Contas desativadas, excluídas ou de outra forma restritas.

Use Carregar muitos usuários quando os usuários puderem ser exportados e importados em lotes. Use Directory Connector quando um diretório existente ou repositório personalizado permanecer autoritativo durante a transição. Para Active Directory, use Directory Connector for Active Directory.

Estratégia de senha

Escolha o caminho da senha com base no que a plataforma de origem pode expor ou validar com segurança:

Importe senhas ou hashes de senha compatíveis somente quando estiverem disponíveis em um formato compatível e puderem ser manipulados com segurança.
Valide a senha existente por meio do Directory Connector enquanto o diretório de origem permanece autoritativo.
Por padrão, os FoxIDs salvam uma cópia da senha local após a validação bem-sucedida do Directory Connector. Isso torna possível desabilitar o conector posteriormente e mover a validação de senha para FoxIDs sem forçar uma redefinição de cada usuário.
Desative a cópia da senha local quando a política exigir que o diretório externo continue sendo o único armazenamento de senhas.
Exigir redefinição de senha quando importar ou reter a senha existente não for tecnicamente possível ou quando a redefinição for a opção mais segura.

Nunca presuma que as senhas podem ser movidas diretamente de um provedor de identidade. Confirme o formato de exportação da plataforma de origem, o algoritmo de hash, a API de validação e as restrições de segurança antes de selecionar o método de migração.

Migração gradual

Onde o diretório de origem oferece suporte à validação on-line, os usuários podem ser criados ou atualizados em FoxIDs na primeira entrada bem-sucedida por meio do Directory Connector. Isso oferece suporte a uma transição gradual sem exigir que todos os usuários migrem ao mesmo tempo.

Mantenha a origem disponível até que a população de usuários necessária tenha migrado e a janela de reversão seja fechada. Monitore logins com falha, conflitos de identificador, claims ausentes e disponibilidade do conector durante a transição.

Corte e reversão

Antes do corte da produção:

Conclua aplicativos representativos e testes de aceitação do usuário.
Confirme certificados, metadados, DNS, URLs de redirecionamento e caminhos de firewall.
Defina a ordem na qual os aplicativos, APIs e grupos de usuários são movidos.
Registre a configuração anterior e as condições que acionam a reversão.
Certifique-se de que o monitoramento e o registro em log cubram os FoxIDs e os fluxos restantes da plataforma de origem.
Comunique a redefinição de senha ou a alteração do comportamento de login antes que isso afete os usuários.

Uma implementação gradual limita o número de aplicativos e usuários afetados por cada alteração. Mantenha a reversão tecnicamente possível até que o comportamento de produção, as reclamações e o acesso tenham sido verificados.