Migrar do Okta para o FoxIDs

Transfira os inícios de sessão do Okta para o FoxIDs com a abordagem adequada ao local onde cada grupo se autentica. Importe utilizadores locais e permita que escolham uma nova palavra-passe ou ative o acesso sem palavra-passe com códigos de utilização única. Para acessos sociais e empresariais, configure métodos FoxIDs que confiem em fornecedores externos. O Okta pode também continuar como fornecedor de identidade enquanto as aplicações passam para o FoxIDs.

Este guia técnico abrange os utilizadores do Okta Universal Directory, a configuração de aplicações e o mapeamento de contas para Okta Identity Engine e Classic Engine.

Para importar utilizadores locais, converta a exportação Okta revista num CSV e use o FoxIDs Seed Tool para os carregar em massa no FoxIDs. Os exemplos seguintes mostram os campos de definição de palavra-passe e acesso sem palavra-passe.

Escolha uma abordagem para cada grupo:

Método Requisitos Primeiro início de sessão
Importar utilizadores para definir a palavra-passe Dados de utilizador e um endereço de e-mail para definir a palavra-passe. O utilizador inicia sessão e define uma palavra-passe com um código por e-mail.
Migrar utilizadores sem palavra-passe Dados de utilizador e um fluxo de acesso adequado por e-mail ou SMS. O utilizador introduz um código de utilização única e mantém uma conta sem palavra-passe.
Migrar inícios de sessão sociais e empresariais Um método de autenticação FoxIDs configurado para confiar em cada fornecedor de identidade externo. O utilizador inicia sessão no fornecedor existente.
Ligar diretamente ao Active Directory O Active Directory continua a validar as palavras-passe dos utilizadores. O utilizador inicia sessão com a palavra-passe AD através do FoxIDs Login.
Manter o Okta durante a transição Uma ligação OpenID Connect ou SAML do FoxIDs ao Okta. O utilizador autentica-se no Okta com os métodos permitidos pelas suas políticas.

Preparar o destino e a aplicação

Um ambiente de teste dedicado permite experimentar a migração com um pequeno grupo antes da passagem para produção. Os passos de configuração são:

  1. Se pretender um domínio personalizado, configure-o e verifique-o no tenant antes de configurar aplicações e fornecedores de identidade externos. Utilize os URL FoxIDs resultantes durante toda a migração. Alterar o domínio mais tarde exige atualizar as configurações externas, incluindo os URL de autoridade ou metadados das aplicações e os URL de retorno e de fim de sessão dos fornecedores.
  2. Cada ambiente tem um método de autenticação Login predefinido chamado login. Personalize a imagem de marca e interface de início de sessão para obter o aspeto desejado e ajuste as opções de início de sessão aos utilizadores importados.
  3. Crie os métodos de autenticação que ligam os utilizadores aos fornecedores externos, incluindo o Okta se continuar a fazer parte da transição.
  4. Configure a aplicação, os URL de redirecionamento permitidos, o comportamento de fim de sessão e as API que aceitam os seus tokens de acesso.

O FoxIDs Cloud disponibiliza envio de e-mail e SMS para definir palavras-passe, iniciar sessão sem palavra-passe e usar autenticação multifator (MFA), consoante o plano FoxIDs Cloud escolhido.

Configure as definições MFA necessárias e a inscrição dos utilizadores. Os imports CSV descritos transferem dados de utilizadores, não inscrições Okta Verify, registos de dispositivos FastPass, chaves de acesso ou outras inscrições MFA. Os utilizadores que se autenticam localmente no FoxIDs registam os fatores configurados. Quem continua através do Okta pode manter as suas inscrições Okta.

A configuração de aplicações é um trabalho separado da importação de utilizadores. Reveja emissor, audiência, âmbitos, claims e validação de tokens, além de dependências do SDK Okta ou Sign-In Widget, inline hooks, regras de grupos e atribuições de aplicações. Recrie o comportamento exigido pela aplicação. O guia geral de migração abrange o inventário mais alargado e os passos de implementação.

Exportar um grupo definido de utilizadores Okta

Use a Okta Users API para obter dados de utilizadores em JSON para conversão. Selecione a organização de origem e os utilizadores ou grupos a migrar. Siga o URL rel="next" do cabeçalho de resposta Link até ler todas as páginas. A operação de listagem normal omite utilizadores DEPROVISIONED; um filtro ou pesquisa pode incluí-los. Os resultados de pesquisa têm consistência eventual, pelo que alterações recentes podem demorar a aparecer.

Conserve organização de origem, id do utilizador, status do ciclo de vida, atributos profile necessários e informação credentials.provider. Distinga utilizadores geridos pelo Okta, baseados em diretório e federados. A configuração dos fornecedores e as regras de encaminhamento ajudam a identificar onde se autenticam realmente.

Para exportação baseada em relatório, o relatório User Accounts oferece CSV Export. As colunas ainda precisam de conversão para o formato FoxIDs Seed Tool. A API é útil se forem necessários atributos personalizados ou dados do fornecedor ausentes no relatório.

Exporte separadamente a pertença a grupos e o acesso a aplicações quando determinam permissões. Os relatórios Okta Group Membership e User App Access descrevem essas relações; nem todas estão no objeto profile do utilizador.

Disponibilidade das palavras-passe

O Okta apenas disponibiliza a exportação de hashes de palavras-passe para migração para o Auth0, sujeita a critérios específicos.

O FoxIDs pode importar hashes de palavras-passe suportados quando estão disponíveis.

Mapear dados de utilizadores e preservar contas das aplicações

O FoxIDs cria o seu próprio ID persistente para os utilizadores locais importados. Importar o id do utilizador Okta como claim personalizado não o torna no ID FoxIDs nem preserva automaticamente o sujeito da aplicação. Registe o sub OpenID Connect ou NameID SAML real usado por cada aplicação, juntamente com a organização de origem e o ID do utilizador.

Se a aplicação usa o ID de utilizador Okta como sub, importe-o como claim personalizado, por exemplo legacy_okta_user_id. No método Login configure uma transformação de claims Map com ação Replace claim, claim de entrada legacy_okta_user_id e de saída sub. A aplicação recebe esse valor como sub, enquanto o ID persistente FoxIDs permanece inalterado. Se usar outro valor de sujeito, preserve e mapeie esse valor.

As aplicações que identificam contas por emissor e sujeito também precisam de associar o novo emissor FoxIDs às contas existentes. Para aplicações SAML, configure o NameID e formato necessários no registo de aplicação SAML. Um início de sessão de teste mostra a identidade realmente recebida pela aplicação.

Mantenha uma associação entre identidade de origem, nova identidade FoxIDs e conta existente da aplicação. As identidades usadas durante a transição devem apontar para o mesmo registo de cliente ou colaborador. Para acessos sociais e empresariais, inclua a identidade recebida diretamente do fornecedor; pode diferir do ID de utilizador Okta.

Para importar utilizadores locais, utilize o seguinte mapeamento:

Informação de origem Destino e decisão
profile.email Email. Verifique duplicados após remover espaços nas extremidades e converter para minúsculas, incluindo colisões com utilizadores FoxIDs existentes.
profile.login Username se for exigido início de sessão com nome de utilizador. Um nome de acesso Okta pode diferir do e-mail do utilizador.
profile.mobilePhone Phone quando o número escolhido será usado para acesso por SMS. Use formato internacional com indicativo do país.
Evidências de verificação de e-mail e telefone EmailVerified e PhoneVerified. A presença de um contacto no perfil não prova a verificação; use false quando o estado é desconhecido.
status DisableAccount. Mantenha desativados os utilizadores suspensos; omita os desaprovisionados ou importe-os desativados se os registos forem necessários.
id de utilizador e organização de origem Conserve no mapeamento de migração. Os exemplos também mantêm o ID em legacy_okta_user_id.
profile.firstName, profile.lastName e atributos personalizados necessários Mapeie para os claims usados pelas aplicações.
Pertença a grupos e atribuições de aplicações Recrie as funções e atribuições de acesso necessárias no FoxIDs ou na aplicação.

Os estados do ciclo de vida Okta são mais detalhados do que o indicador de desativação FoxIDs. Os exemplos ativam utilizadores selecionados de contas ACTIVE e mantêm desativadas as contas suspensas. Estados como STAGED, PROVISIONED, RECOVERY, PASSWORD_EXPIRED e LOCKED_OUT exigem mapeamento explícito para o comportamento pretendido de ativação, definição de palavra-passe ou acesso.

Migrar inícios de sessão sociais e empresariais

Crie um método FoxIDs para cada fornecedor social ou empresarial atualmente ligado através do Okta, estabelecendo confiança direta. Os utilizadores mantêm as contas e credenciais no fornecedor.

  1. Identifique o fornecedor de cada ligação. Use o guia de integração adequado, como Google ou Microsoft Entra ID, e selecione o método suportado OpenID Connect, SAML 2.0 ou WS-Federation.
  2. Registe ou configure o FoxIDs no fornecedor. Troque definições de cliente ou metadados de federação e configure os URL de retorno e fim de sessão indicados no guia. Conserve a ligação Okta durante a transição.
  3. Permita o novo método de autenticação na aplicação FoxIDs. Configure Home Realm Discovery para que os utilizadores possam escolher o fornecedor ou ser encaminhados pelas regras configuradas.
  4. Associe a identidade do fornecedor à conta existente da aplicação. Se precisar de guardar claims ou atribuições de acesso por utilizador no FoxIDs, configure e aprovisione utilizadores externos.
  5. Recrie as restrições de acesso anteriormente aplicadas pelo Okta, incluindo atribuições de aplicações, utilizadores suspensos e MFA necessária.

O fluxo esperado é aplicação → FoxIDs → fornecedor de identidade externo → FoxIDs → aplicação. O FoxIDs emite os tokens da aplicação após o fornecedor autenticar o utilizador.

Pode experimentar cada ligação iniciando a sessão na aplicação, selecionando o fornecedor e concluindo o respetivo fluxo. Isto permite observar MFA, conta e permissões da aplicação e comportamento de fim de sessão.

Migrar utilizadores do Active Directory

Se o Okta delega a autenticação com palavra-passe no Active Directory e o AD continua a ser a origem, o FoxIDs pode ligar-se diretamente através do Directory Connector para Active Directory. Configure o conector e o método Login conforme esse guia. O FoxIDs sincroniza utilizadores do AD e valida palavras-passe no AD, pelo que estes utilizadores não precisam de importação CSV de palavras-passe.

Por predefinição, o FoxIDs guarda uma cópia local da palavra-passe após validação bem-sucedida pelo Directory Connector. Isto permite passar mais tarde para autenticação local FoxIDs desativando o conector. Os utilizadores cujas palavras-passe não foram recolhidas podem usar a definição de palavra-passe. Consulte o comportamento de palavras-passe do Directory Connector para opções de configuração.

Um utilizador Okta proveniente do AD não se autentica necessariamente ainda no AD: o Okta pode migrar a autenticação com palavra-passe do AD para o Okta. A ligação direta aplica-se quando o AD continua a guardar e validar a palavra-passe utilizada.

Migrar utilizadores sem palavra-passe

Importe os utilizadores como internos FoxIDs sem palavra-passe e configure o início de sessão sem palavra-passe com código por e-mail ou SMS. O utilizador introduz o código na página que já abriu.

Isto representa uma mudança do método de autenticação para os utilizadores do Okta FastPass ou de passkeys. Os códigos por e-mail e SMS não oferecem a mesma resistência ao phishing que o FastPass.

  1. Ative e-mail ou telefone como identificador de início de sessão no método FoxIDs Login e ative Passwordless with email (one-time password) ou Passwordless with SMS (one-time password) conforme adequado.
  2. Para um método dedicado a utilizadores sem palavra-passe, selecione Disable password authentication e desative a definição/reposição de palavra-passe por e-mail e SMS.
  3. Importe os utilizadores omitindo Password e todos os campos de hash. Mantenha SetPasswordEmail, SetPasswordSms e ChangePassword em false. Preserve o estado de verificação mapeado, o estado de desativação e os claims necessários.

Por exemplo, este CSV do Seed Tool importa um utilizador fictício sem palavra-passe por e-mail cujo estado anterior de verificação do e-mail é desconhecido:

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount;Claims
alice@example.com;false;false;false;false;false;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"

Para utilizadores SMS, substitua Email e EmailVerified por Phone e PhoneVerified, com o número escolhido e o estado de verificação conhecido. Aplica-se o mesmo procedimento de carregamento.

Pode experimentar o fluxo com um utilizador de teste importado, introduzindo e-mail ou telefone e o código recebido. Um código válido permite a um utilizador ativo continuar pela MFA necessária até à aplicação. O utilizador continua sem palavra-passe após um acesso sem palavra-passe bem-sucedido.

Importar utilizadores para definir a palavra-passe

Ative início de sessão por e-mail, autenticação com palavra-passe e definição por e-mail no método FoxIDs Login. Os utilizadores importados escolhem uma palavra-passe no primeiro início de sessão.

Migração com definição de palavra-passe: exportar e rever dados dos utilizadores Okta, importar utilizadores sem palavra-passe e depois iniciar sessão e definir uma palavra-passe com um código por e-mail.

A importação prepara as contas. A definição da palavra-passe ocorre quando cada utilizador inicia sessão, não durante a importação.

Converta os registos revistos num ficheiro UTF-8 para o FoxIDs Seed Tool. Os cabeçalhos distinguem maiúsculas de minúsculas e o separador é um ponto e vírgula. O exemplo contém utilizadores fictícios com estado anterior de verificação de e-mail desconhecido; a segunda conta continua desativada:

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;false;true;false;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO001""]}]"
suspended@example.com;false;true;true;true;"[{""Claim"":""legacy_okta_user_id"",""Values"":[""00u000000000DEMO002""]}]"

SetPasswordEmail=true seleciona a definição da palavra-passe com confirmação por e-mail. Omita Password e todas as colunas de hash. RequireMultiFactor=true é a política escolhida no exemplo e requer configurar os métodos MFA correspondentes.

Disponibilize o claim de exemplo legacy_okta_user_id apenas às aplicações que dele necessitem através do tratamento de claims configurado.

Carregar utilizadores e examinar o resultado

Utilize este procedimento para utilizadores sem palavra-passe e que escolherão uma palavra-passe no primeiro início de sessão, com os campos adequados ao método escolhido.

O Seed Tool divide os campos por pontos e vírgulas; campos entre aspas não podem conter pontos e vírgulas nem quebras de linha. Utilize as operações de utilizadores da Control API se os valores exigirem uma representação de importação mais completa.

  1. Transfira e configure o Seed Tool para o ambiente pretendido. Defina SeedSettings.UsersSvcPath como o ficheiro CSV convertido.
  2. Execute o Seed Tool e selecione U para carregar os utilizadores em massa.
  3. Registe os novos ID de utilizador no mapeamento de migração.

Pode experimentar o carregamento com um CSV de poucos utilizadores num ambiente de teste. O Seed Tool apresenta as contagens de sucessos e falhas. No FoxIDs Control pode examinar identificadores, estado de desativação, claims e indicadores de definição da palavra-passe dos utilizadores importados.

O Seed Tool usa aprovisionamento em massa, que pode substituir utilizadores existentes em vez de os combinar. Repetir o carregamento pode remover credenciais e estado e criar novos ID. Numa importação parcial, reconcilie o resultado antes de tentar novamente; use atualizações específicas para alterações posteriores.

Definição da palavra-passe no primeiro início de sessão

Para um utilizador importado ativo com SetPasswordEmail=true, o fluxo esperado é:

  1. O utilizador abre a aplicação e inicia sessão através do FoxIDs Login.
  2. O FoxIDs identifica o utilizador pelo endereço de e-mail e envia um código de confirmação.
  3. O utilizador submete o código e uma nova palavra-passe que cumpre a política do FoxIDs.
  4. O FoxIDs verifica o e-mail, guarda a palavra-passe e limpa os indicadores de definição. O início de sessão prossegue pelas etapas MFA necessárias antes de regressar à aplicação.

Importar um utilizador não envia o e-mail de definição. Os acessos seguintes com palavra-passe usam a nova palavra-passe FoxIDs. Se o utilizador não conseguir receber o código, o processo de recuperação precisa de outra forma de verificar a identidade.

Pode explorar o fluxo com um utilizador de teste seguindo os passos acima. Estes cenários mostram os resultados esperados:

Scenario Resultado esperado
Primeiro início de sessão e seguintes O e-mail chega; a definição é concluída com código válido e palavra-passe conforme à política; o início de sessão seguinte não repete a definição.
Código inválido ou expirado A definição da palavra-passe falha sem conceder acesso à aplicação.
Conta desativada Nem a definição da palavra-passe nem o início de sessão ativam a conta.
Conta e permissões O utilizador acede à mesma conta e dados da aplicação com o acesso previsto.
MFA, acesso API e fim de sessão A MFA necessária é aplicada; as API aceitam os tokens previstos e rejeitam os inválidos; o fim de sessão segue o fluxo configurado.

Manter o Okta durante a transição

O FoxIDs pode confiar no Okta como fornecedor externo enquanto as aplicações passam para o FoxIDs. Os utilizadores autenticam-se no Okta e o FoxIDs emite tokens para a aplicação. As palavras-passe e autenticadores Okta permanecem no Okta; não são copiados para o FoxIDs.

Para uma ligação OpenID Connect:

  1. Crie no Okta uma integração de aplicação web OIDC para o FoxIDs com Authorization Code Flow. Atribua os utilizadores ou grupos que iniciarão sessão através dela e configure a política de acesso.
  2. Crie um método de autenticação OpenID Connect no FoxIDs. Defina Authority como o emissor Okta escolhido e configure o ID de cliente Okta em Optional custom SP client ID, o respetivo segredo e o método correspondente de autenticação do cliente no endpoint de tokens.
  3. Peça os âmbitos profile e email conforme necessário; o FoxIDs inclui openid. Selecione Read claims from the UserInfo Endpoint instead of the access token or ID token em Show advanced para obter os claims através de UserInfo.
  4. Registe o Redirect URL apresentado pelo FoxIDs como URI de redirecionamento de início de sessão no Okta e configure o URI de fim de sessão correspondente quando usado.
  5. Permita o método na aplicação FoxIDs e configure Home Realm Discovery para os utilizadores que continuam através do Okta.

O servidor de autorização da organização Okta suporta início de sessão OpenID Connect com um emissor como https://example.okta.com. Um servidor personalizado usa um emissor como https://example.okta.com/oauth2/default. Use o emissor e a configuração de claims escolhidos para a integração.

Outra opção é um método de autenticação SAML: crie uma aplicação SAML no Okta para o FoxIDs e troque metadados e definições dos fornecedores de serviço e de identidade.

Um início de sessão de teste pela aplicação mostra a política de autenticação Okta, claims, associação de contas e fim de sessão da nova ligação. À medida que os utilizadores passam para acesso local FoxIDs ou fornecedores diretos, encaminhe-os para esses métodos. Manter a associação de contas alinhada entre os métodos permite continuar a usar os mesmos registos.

Implementar e manter uma via de reversão

A migração pode ser implementada por aplicação ou grupo. Os utilizadores podem continuar pelo URL habitual com o fluxo configurado: definição de palavra-passe, código de utilização única, palavra-passe do diretório ou fornecedor externo.

Reconcilie utilizadores criados, alterados, suspensos ou eliminados desde a exportação, incluindo alterações a grupos e atribuições de aplicações. Um breve período sem alterações ou uma reconciliação controlada pode manter origem e destino alinhados durante a passagem. As atualizações posteriores devem preservar as credenciais e o estado já estabelecidos no FoxIDs.

Monitorize a entrega de e-mail e SMS, falhas na definição de palavras-passe, falhas de início de sessão e problemas de associação de contas. A reversão depende da disponibilidade da configuração Okta anterior. Pode experimentar restaurá-la para uma aplicação de teste e observar o regresso ao fluxo Okta.

Uma palavra-passe definida localmente no FoxIDs não é sincronizada de volta para o Okta. A reversão usa as credenciais ainda guardadas no Okta ou no fornecedor ligado. Os utilizadores criados apenas no FoxIDs precisam de uma via de acesso se for necessário reverter. Quando os utilizadores e aplicações necessários usarem os métodos de destino, a integração Okta pode ser retirada.