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.
Nesta página
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
| Provedor | Configuração relevante |
|---|---|
| Habilitação, Client ID, substituição de client secret e callback. | |
| Microsoft | Client ID, Tenant ID do provedor, segredo e callback. |
| Okta / Auth0 | Client ID, Issuer URL HTTPS, segredo e callback. |
| GitHub | Client ID, segredo e callback; email primário verificado correspondente a um usuário Dova ativo. |
| GitLab | Client 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
- Abra Preferences → Authentication e selecione o cartão do provedor.
- Prepare a aplicação aprovada na administração do provedor.
- Copie Authorized callback URL do Dova e cadastre-a exatamente na integração.
- Preencha Client ID e os campos específicos, como Tenant ID ou Issuer URL.
- Use Replace client secret somente quando necessário. Deixar em branco preserva o segredo atual conforme o formulário.
- Defina a habilitação e use a ação correspondente, como Save Google ou Save Microsoft.
- Confirme a persistência e use
Testdiscovery ouTestprovider, conforme apresentado. O teste usa a configuração salva, não campos ainda editados. - 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
- Inicie o login pelo método autorizado e siga Verification or recovery code.
- No primeiro setup, cadastre o QR ou a chave apresentada de forma privada no autenticador correto. Não faça capturas para o manual.
- Envie o código atual pelo formulário. Se usar um código de recuperação, lembre que ele é de uso único.
- Guarde os códigos de recuperação em armazenamento seguro aprovado.
- Escolha Trust this device somente de forma consciente no dispositivo apropriado. Use Use another account se selecionou a identidade errada.
- 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.