Dova Docs22.0.5
Suporte

Configurar SSO e concluir MFA no escopo autorizado

Configure provedores externos, teste as configurações persistidas e conclua a verificação da conta sem confundir identidade e autorização.

Manual completo em PDF
Nesta página
  1. Objetivo e autoridade
  2. Provedores e campos
  3. Configurar um provedor externo
  4. Política de autorregistro
  5. Concluir MFA
  6. Exemplo e recuperação

Objetivo e autoridade

Preferences → Authentication configura provedores externos de login. Salvar ajustes globais, substituir segredos e testar provedores exige Platform Administrator autorizado. Consultar Preferences não concede essa autoridade. Verifique a permissão informada e o papel ativo antes de alterar um provedor.

SSO estabelece identidade; papéis e associações controlam a autorização; MFA conclui a verificação exigida da conta. Habilitar um provedor não concede administração nem remove MFA. Antes de mudar uma integração, prepare uma via administrativa de recuperação autorizada e uma identidade de laboratório.

Provedores e campos

ProvedorConfiguração relevante
GoogleHabilitação, Client ID, substituição de client secret e callback.
MicrosoftClient ID, Tenant ID do provedor, segredo e callback.
Okta / Auth0Client ID, Issuer URL HTTPS, segredo e callback.
GitHubClient ID, segredo e callback; email primário verificado correspondente a um usuário Dova ativo.
GitLabClient ID, Issuer URL suportado, segredo e callback para o serviço pretendido.

Authorized callback URL é somente leitura e pode ser copiada. Cadastre exatamente essa URL na aplicação autorizada do provedor, sem adivinhar caminhos ou trocar domínios. Client ID e segredo têm funções diferentes. Nunca publique o segredo, a chave de setup MFA, um desafio real ou códigos de recuperação.

Configurar um provedor externo

  1. Abra Preferences → Authentication e selecione o cartão do provedor.
  2. Prepare a aplicação aprovada na administração do provedor.
  3. Copie Authorized callback URL do Dova e cadastre-a exatamente na integração.
  4. Preencha Client ID e os campos específicos, como Tenant ID ou Issuer URL.
  5. Use Replace client secret somente quando necessário. Deixar em branco preserva o segredo atual conforme o formulário.
  6. Defina a habilitação e use a ação correspondente, como Save Google ou Save Microsoft.
  7. Confirme a persistência e use Test discovery ou Test provider, conforme apresentado. O teste usa a configuração salva, não campos ainda editados.
  8. Realize um novo login com a identidade autorizada de laboratório e confira usuário, workspace e papel finais.

Um teste de disponibilidade ou discovery não valida sozinho o fluxo completo nem todos os aspectos do segredo. Uma sessão antiga aberta também não comprova o login pela configuração nova. Siga a regra de identidade de cada cartão; não aplique o comportamento de onboarding Google a todos os seis provedores.

Política de autorregistro

Allow self-registration possui uma ação separada, Save registration policy. O autorregistro novo utiliza identidades Google verificadas conforme a política vigente e o fluxo de workspace individual e trial administrado quando aplicável. Não concede papéis de plataforma. Confira o tenant e a identidade resultantes, em vez de presumir um destino pelo texto de ajuda antigo.

Habilitar a opção não converte contas existentes, renova trials ou cancela condições comerciais. Uma negativa por ciclo de vida deve ser investigada em tenant e assinatura, sem atribuir um papel de plataforma como correção.

Concluir MFA

  1. Inicie o login pelo método autorizado e siga Verification or recovery code.
  2. No primeiro setup, cadastre o QR ou a chave apresentada de forma privada no autenticador correto. Não faça capturas para o manual.
  3. Envie o código atual pelo formulário. Se usar um código de recuperação, lembre que ele é de uso único.
  4. Guarde os códigos de recuperação em armazenamento seguro aprovado.
  5. Escolha Trust this device somente de forma consciente no dispositivo apropriado. Use Use another account se selecionou a identidade errada.
  6. Após concluir, confirme o workspace e o papel antes de realizar operações.

Se o fluxo informar mfaRequired, authenticated=false é esperado enquanto o segundo fator está pendente. Não interprete a confirmação da senha ou do provedor como uma sessão plenamente autenticada. Se a verificação vencer, inicie novamente e use o desafio atual; não reutilize desafios de uma aba antiga. Trust this device não desabilita MFA globalmente.

Exemplo e recuperação

Em laboratório, teste uma identidade autorizada, uma identidade não autorizada e um código inválido, sem registrar códigos ou cookies na evidência. Somente o caminho permitido deve chegar ao tenant e papel esperados após MFA. Saia e faça um novo login para verificar a configuração persistida.

Em falhas, separe conexão do provedor, callback ou issuer, correspondência da identidade, MFA e autorização. Se o provedor responder e Dova negar acesso, confira estado da conta, associação e papel. Se não tiver o fator, siga a recuperação autorizada; não altere armazenamento ou política para pular a verificação. Solicite ajuda pelo formulário Cloudata, sem enviar códigos ou segredos.

Consulte também: Users, Roles & permissions, Tenants.