Configurar SSO y completar MFA sin ampliar permisos
Objetivo y autoridad
Preferences → Authentication configura proveedores de inicio de sesión. El servidor exige Platform Administrator para guardar, sustituir secretos y probar proveedores. Acceder a Preferences por etl.configuration.view no basta para modificar autenticación global. La respuesta de configuración indica si el usuario puede gestionar; no dependa exclusivamente de que aparezca un botón.
SSO identifica a una persona; RBAC determina qué puede hacer. MFA añade verificación del acceso conforme al flujo de cuenta. No suponga que habilitar un proveedor crea usuarios, asigna roles o elimina la verificación multifactor. Prepare una vía administrativa autorizada de recuperación antes de cambiar una integración y pruebe con identidades de laboratorio.
Proveedores y campos
| Proveedor | Configuración visible relevante |
|---|---|
| Habilitación, Client ID, sustitución de client secret y callback autorizado | |
| Microsoft | Habilitación, Client ID, tenant del proveedor, secreto y callback |
| Okta | Client ID, Issuer URL HTTPS, secreto y callback |
| Auth0 | Client ID, Issuer URL HTTPS, secreto y callback |
| GitHub | Client ID, secreto y callback; identidad con email primario verificado |
| GitLab | Client ID, Issuer URL, secreto y callback; GitLab.com o self-managed |
La interfaz muestra Authorized callback URL como sólo lectura y permite copiarlo. Registre esa URL exacta en la aplicación del proveedor, sin adivinar rutas ni intercambiar dominios. Para secretos existe Replace client secret: dejarlo vacío conserva el actual conforme al formulario. Un valor de configuración visible no autoriza publicar el secreto ni su ubicación de custodia.
Procedimiento de configuración
- Confirme rol activo de plataforma y el proveedor que desea integrar.
- Prepare una aplicación autorizada en el proveedor según el procedimiento de su organización. No utilice una aplicación ajena o personal como sustituto temporal.
- Copie el callback mostrado por Dova y configure la integración correspondiente en el proveedor.
- Introduzca Client ID, issuer o tenant cuando proceda y reemplace el secreto sólo si es necesario.
- Guarde los ajustes y el reemplazo de secreto mediante el flujo del proveedor, y confirme su persistencia. Después use Test provider: la prueba utiliza la configuración guardada, no los campos aún editados.
- Realice un inicio nuevo con la cuenta de laboratorio. Verifique identidad, workspace y rol final, además del resultado del proveedor.
Test provider comprueba disponibilidad o discovery según el proveedor; no valida por sí solo el inicio de sesión completo ni la validez integral del client secret. Un resultado correcto tampoco prueba que toda cuenta externa esté autorizada. GitHub requiere email primario verificado que coincida con un usuario Dova activo según el texto de la UI. Revise cada política; no generalice el autoregistro de Google a los seis proveedores.
Autoregistro Google y lifecycle
Google self-registration es una política global independiente. El contrato de onboarding individual utiliza identidad verificada para crear el workspace privado individual y trial administrado cuando aplica; no concede acceso administrativo. No describa el texto de ayuda histórico sobre tenant predeterminado como garantía de destino. La identidad y el alcance finales deben verificarse con el comportamiento del onboarding vigente.
Habilitar esta opción no convierte cuentas existentes ni renueva trials automáticamente. El modelo preserva identidades pagadas y aplica condiciones comerciales al tenant creado. Una denegación por lifecycle no debe corregirse asignando un rol de plataforma.
MFA y recuperación
El flujo de autenticación ofrece Verification or recovery code. Para configuración inicial muestra QR y clave de setup; registre el factor en su autenticador de forma privada y envíe el código requerido. Los códigos de recuperación son de un solo uso y deben custodiarse en un gestor de contraseñas. Nunca capturarlos para el manual, soporte público o un POC compartido.
Trust this device es una elección explícita del usuario, no un mecanismo para desactivar MFA globalmente. Use Use another account si seleccionó la identidad equivocada. Si no dispone del factor, utilice recuperación autorizada; no modifique almacenamiento ni políticas para saltar la verificación.
POC, errores y diagnóstico
En laboratorio pruebe un usuario existente autorizado, otro no autorizado y un intento con código incorrecto. Compruebe que sólo el caso permitido entra al workspace esperado. Registre resultados sin códigos, cookies ni tokens. Pruebe nuevamente tras cerrar sesión: la sesión administrativa abierta no valida el nuevo inicio.
Ante fallo revise callback exacto, issuer/tenant, habilitación y correspondencia de identidad. Si el proveedor responde pero Dova rechaza acceso, examine cuenta, membresía y rol. No repita sustituciones de secreto sin identificar la causa. Mantenga separados un error de conexión del proveedor, MFA y una denegación de autorización.