Por qué un solo OTP no cubre Wi-Fi, VPN y un registro
El acceso Wi-Fi, la entrada VPN y un registro realizan cada uno un intercambio distinto con su propio público y su propia vigencia. Compartir la cuenta no es compartir un token.
El inicio de sesión único promete una identidad y menos avisos, y la promesa se rompe en el tercer protocolo. La trampa es suponer que una autenticación correcta produce un token que cualquier otro protocolo pueda presentar. El acceso Wi-Fi, la entrada VPN y un registro de contenedores realizan cada uno un intercambio distinto, con públicos y vigencias diferentes. Compartir la cuenta es una decisión de directorio; compartir la credencial es una decisión de protocolo, y los protocolos rara vez coinciden.
Tres intercambios, tres propietarios
El Wi-Fi empresarial ejecuta un método EAP dentro de 802.1X, normalmente terminado por un servicio RADIUS que tiene su propia visión del usuario o del dispositivo. Una puerta de enlace VPN se autentica mediante su propio flujo compatible y luego mantiene una sesión con su propio temporizador de reautenticación. Un registro responde a una petición no autenticada con un desafío que nombra un servicio de tokens, un público y un ámbito, y el cliente cambia su credencial por un token de corta vida.
No son tres vistas de una sola sesión. Cada uno tiene su propio verificador, su propia vigencia y su propia vía de revocación, por eso un cambio de contraseña en el directorio puede dejar uno funcionando y otro roto. Trátalos como tres integraciones que casualmente comparten un directorio de usuarios.
Qué lleva el SSO del navegador y qué no
Una sesión de navegador en un proveedor de identidad es realmente útil: las aplicaciones que redirigen a él heredan el inicio de sesión que el usuario ya completó. Eso funciona porque esas aplicaciones hablan los mismos protocolos de redirección y de tokens y aceptan el mismo público. Un suplicante que habla EAP no tiene ninguna redirección que seguir, y un cliente de Docker que recibe un desafío del registro no pide un token de identidad OIDC. El proveedor de identidad solo puede responder por los protocolos para los que fue construido.
El fallo es fácil de ver en los registros cuando sabes dónde mirar. El proveedor de identidad informa de un inicio de sesión correcto mientras la asociación Wi-Fi sigue fallando, o el registro devuelve 401 tras un intercambio de token que el navegador nunca vio. Dos éxitos y un fallo no son una contradicción; son tres autenticaciones separadas.
Dónde un certificado sustituye a un código repetido
Para los dispositivos gestionados, el EAP basado en certificados elimina el paso humano sin eliminar la identidad: el dispositivo presenta un certificado, el servicio RADIUS lo comprueba contra la autoridad emisora y la revocación ocurre en esa autoridad en lugar de en un secreto compartido. El precio es trabajo de ciclo de vida, porque los certificados caducan y hay que renovarlos antes de que lo hagan.
Los registros tienen una división equivalente. Un usuario interactivo puede iniciar sesión una vez y dejar que un asistente de credenciales guarde el token resultante, mientras que la automatización debería usar una credencial de servicio de ámbito estrecho o una identidad de carga de trabajo. Ninguna de las dos debería ser el código de un solo uso de una persona copiado en una tubería. El asistente guarda un token para un público concreto del registro, así que no se puede redirigir a la puerta de enlace VPN editando un archivo de configuración.
docker login registry.example.comCompare el coste de mantenimiento, no el número de avisos
Una credencial compartida parece barata porque el trabajo es invisible hasta que falla. Cuente en cambio lo que cuesta cada opción durante un año: alta, renovación, revocación, el radio de impacto de una filtración y el número de sistemas tocados cuando alguien se marcha. Una flota de certificados cuesta más de construir y menos de operar a escala; un código copiado no cuesta nada empezar y lo cuesta todo desenredar.
Luego elija por tramo en lugar de globalmente. El Wi-Fi puede pasar a certificados, la VPN puede conservar su SSO compatible con MFA y el registro puede usar tokens con ámbitos explícitos. Anote el propietario, el público, el ámbito, la caducidad y la vía de revocación de cada uno, y los avisos caerán donde deben en lugar de en todas partes a la vez. Ese registro es también la respuesta cuando un auditor pregunta qué sistemas siguen confiando en una contraseña.