La integración técnica entre Cloudflare Access y un proveedor de identidad empresarial lleva menos de una hora en la mayoría de los casos: intercambio de metadatos, algunas URL y pruebas de autenticación. Lo que lleva semanas es lo que viene después: decidir qué grupos tienen acceso a qué aplicaciones, con qué duración de sesión, con qué requisitos de MFA y qué hacer con los colaboradores externos en un IdP diferente. La configuración del protocolo es un detalle de la documentación. La arquitectura de políticas es una decisión de diseño.
SAML, OIDC y lo que importa a la hora de elegir
Cloudflare Access es compatible con SAML 2.0 y OIDC. Para proveedores empresariales más grandes (Okta, Azure AD, Google Workspace, OneLogin, Ping Identity, JumpCloud), Cloudflare mantiene guías de integración con mapeo de campos exacto. La elección entre SAML y OIDC rara vez es una decisión técnica crítica; Ambos funcionan de manera equivalente para el caso de uso de autenticación de Access.
La diferencia práctica es que OIDC es más sencillo de configurar para los proveedores modernos y devuelve atributos en formato JWT directamente. SAML requiere mapeo de atributos en formato de aserción XML, lo que agrega fricción en configuraciones más complejas, especialmente cuando desea pasar atributos personalizados desde el IdP para su uso en políticas. Para nuevas integraciones con Okta o Azure AD, OIDC es el camino de menor resistencia.
Múltiples proveedores de identidad simultáneamente
Una capacidad de Access que pasa desapercibida en los proyectos iniciales: una misma organización puede tener múltiples proveedores configurados y asignar diferentes proveedores a diferentes aplicaciones. Una aplicación acepta autenticación mediante Google Workspace para empleados y mediante GitHub para colaboradores externos. Otro se restringe exclusivamente al Okta corporativo. Un tercero muestra el menú de opciones para que el usuario seleccione qué proveedor utilizar.
Esto resuelve el escenario frecuente de empresas con empleados en diferentes empresas asociadas, cada una con su propio Azure AD o Google Workspace. En lugar de crear cuentas de invitado en todos los proveedores, Access acepta múltiples proveedores con diferentes políticas por proveedor. El límite práctico no es técnico: es de gestión: cada proveedor adicional es un punto de configuración que mantener y un vector de acceso que monitorear.
Grupos y sincronización de autorizaciones.
Las políticas de acceso que hacen referencia a grupos extraen la membresía directamente del IdP en el momento de la autenticación. Una política "permitir: ingeniería de grupo" no es una lista estática en Cloudflare; es una verificación del grupo en Okta o Azure AD en el momento en que llega el token de autenticación. Cuando se agrega o elimina un colaborador del grupo en el IdP, el efecto es inmediato en la siguiente autenticación, sin sincronización manual en la plataforma Cloudflare.
Esto tiene una consecuencia operativa importante: el proceso de baja debe eliminar al usuario del IdP, no solo revocar el acceso en cada aplicación individual. Si el usuario es desactivado en Okta, todas las políticas de acceso que dependen de ese IdP dejan de funcionar para esa cuenta. La sesión activa sigue siendo válida hasta que caduca, lo que refuerza la importancia de configurar duraciones de sesión adecuadas para cada aplicación.
Duración de la sesión y aplicación de MFA por aplicación
La duración de la sesión se configura por aplicación en Access, no globalmente. Para una aplicación de monitoreo de interiores de baja sensibilidad, siete días es razonable. Para el acceso SSH al entorno de producción, una sesión de una hora requiere una reautenticación frecuente, lo que reduce la ventana para un token comprometido. Para un panel de administración de base de datos, 15 minutos pueden ser más apropiados.
Se puede requerir MFA en el nivel de acceso, independientemente de lo que haga el IdP. Si el IdP no aplica MFA de forma predeterminada, la política de Access puede requerir el uso de autenticación de segundo factor: Access redirigirá al usuario para completar MFA en el IdP si el token no incluye esta garantía. Diferentes aplicaciones pueden tener diferentes requisitos de garantía de autenticación sin necesidad de configurar varias políticas MFA en el IdP.
Tokens de servicio para acceso de máquina a máquina
Canalizaciones de CI/CD, agentes de monitoreo, webhooks: cualquier sistema automatizado que necesite acceder a un recurso con acceso protegido enfrenta un problema: no hay ningún usuario humano que siga el flujo de SSO. Access resuelve esto con tokens de servicio: un par de ID de cliente y secreto de cliente que identifica un servicio como una entidad confiable.
El servicio automatizado incluye el ID del cliente en el encabezado CF-Access-Client-Id y el secreto en CF-Access-Client-Secret. Access reconoce el token de servicio, evalúa la política asociada y permite o deniega el acceso, generando un evento de auditoría como cualquier otro acceso. Los tokens de servicio tienen una fecha de vencimiento configurable y se pueden revocar individualmente sin afectar a otros tokens o usuarios.
Cómo estructurar políticas antes de llamar
El error de diseño más común al adoptar Access es crear una política por aplicación sin un modelo jerárquico. Con docenas de aplicaciones internas, mantener políticas individuales para cada una se convierte en una carga operativa considerable. La alternativa es definir grupos de acceso reutilizables ("acceso básico para todos los empleados", "acceso elevado para el equipo de ingeniería", "acceso administrativo para SRE") y aplicarlos como bloques en las políticas individuales de cada aplicación.
La política de acceso de una nueva aplicación puede heredar un grupo base y agregar condiciones específicas, como la postura obligatoria del dispositivo o restricciones de tiempo. Cuando el equipo de ingeniería crece y se crea un nuevo grupo en el IdP, la actualización de la política de grupo reutilizable en Access se propaga a todas las aplicaciones que hacen referencia a él automáticamente.
Qué hay que decidir antes de configurar
La integración técnica con el IdP es el menor de los desafíos. El más importante es documentar las decisiones políticas y su justificación antes de habilitar Access en producción. ¿Qué aplicaciones tienen acceso automático para todos los empleados? ¿Cuáles requieren la aprobación explícita del grupo? ¿Cómo se trata a los empleados externos de empresas colaboradoras? ¿Quién mantiene a los grupos en el IdP alineados con las políticas de Access?
Estas preguntas no tienen respuesta técnica: son decisiones que el equipo de seguridad y el equipo de producto deben tomar juntos. Los equipos que llegan a la configuración técnica sin haber respondido estas preguntas a menudo terminan con políticas muy permisivas que replican el problema de la VPN con una capa de autenticación encima.