Por que un só OTP non cobre Wi-Fi, VPN e un rexistro

O inicio de sesión único promete unha identidade e menos avisos, e a promesa rompe no terceiro protocolo. A trampa é supor que unha autenticación correcta produce un token que calquera outro protocolo poida presentar. O acceso Wi-Fi, a entrada VPN e un rexistro de contedores realizan cada un un intercambio distinto, con públicos e vixencias diferentes. Compartir a conta é unha decisión de directorio; compartir a credencial é unha decisión de protocolo, e os protocolos raramente coinciden.

Tres intercambios, tres propietarios

O Wi-Fi empresarial executa un método EAP dentro de 802.1X, normalmente terminado por un servizo RADIUS que ten a súa propia visión do usuario ou do dispositivo. Unha pasarela VPN autentícase mediante o seu propio fluxo compatible e logo mantén unha sesión co seu propio temporizador de reautenticación. Un rexistro responde a unha petición non autenticada cun desafío que nomea un servizo de tokens, un público e un ámbito, e o cliente cambia a súa credencial por un token de curta vida.

Non son tres visións dunha soa sesión. Cada un ten o seu propio verificador, a súa propia vixencia e a súa propia vía de revogación, por iso un cambio de contrasinal no directorio pode deixar un funcionando e outro roto. Trátaos como tres integracións que casualmente comparten un directorio de usuarios.

Que leva o SSO do navegador e que non

Unha sesión de navegador nun provedor de identidade é realmente útil: as aplicacións que redirixen a el herdan o inicio de sesión que o usuario xa completou. Iso funciona porque esas aplicacións falan os mesmos protocolos de redirección e de tokens e aceptan o mesmo público. Un solicitante que fala EAP non ten ningunha redirección que seguir, e un cliente de Docker que recibe un desafío do rexistro non pide un token de identidade OIDC. O provedor de identidade só pode responder polos protocolos para os que foi construído.

O fallo é doado de ver nos rexistros cando sabes onde mirar. O provedor de identidade informa dun inicio de sesión correcto mentres a asociación Wi-Fi segue fallando, ou o rexistro devolve 401 tras un intercambio de token que o navegador nunca viu. Dous éxitos e un fallo non son unha contradición; son tres autenticacións separadas.

Onde un certificado substitúe un código repetido

Para os dispositivos xestionados, o EAP baseado en certificados elimina o paso humano sen eliminar a identidade: o dispositivo presenta un certificado, o servizo RADIUS compróbao contra a autoridade emisora, e a revogación ocorre nesa autoridade en lugar de nun segredo compartido. O prezo é traballo de ciclo de vida, porque os certificados caducan e hai que renovalos antes de que o fagan.

Os rexistros teñen unha división equivalente. Un usuario interactivo pode iniciar sesión unha vez e deixar que un asistente de credenciais garde o token resultante, mentres que a automatización debería usar unha credencial de servizo de ámbito estreito ou unha identidade de carga de traballo. Ningunha das dúas debería ser o código dun só uso dunha persoa copiado nunha tubaxe. O asistente garda un token para un público concreto do rexistro, así que non se pode redirixir á pasarela VPN editando un ficheiro de configuración.

docker login registry.example.com

Compare o custo de mantemento, non o número de avisos

Unha credencial compartida parece barata porque o traballo é invisible ata que falla. Conte en cambio o que custa cada opción durante un ano: alta, renovación, revogación, o radio de impacto dunha fuga e o número de sistemas tocados cando alguén marcha. Unha frota de certificados custa máis de construír e menos de operar a escala; un código copiado non custa nada comezar e custa todo desenredar.

Logo elixa por tramo en lugar de globalmente. O Wi-Fi pode pasar a certificados, a VPN pode conservar o seu SSO compatible con MFA e o rexistro pode usar tokens con ámbitos explícitos. Anote o propietario, o público, o ámbito, a caducidade e a vía de revogación de cada un, e os avisos caerán onde deben en lugar de en todas partes á vez. Ese rexistro é tamén a resposta cando un auditor pregunta que sistemas seguen confiando nun contrasinal.