El aseguramiento es una afirmación, no una ceremonia

Ponga una llave de hardware delante de una descarga sensible y se enfrentará a una decisión de diseño que parece un detalle de implementación y no lo es.

La primera opción es convertir a lo que sirve el archivo en su propia parte confiante: ejecuta su propia ceremonia WebAuthn, custodia sus propios registros de credenciales y verifica la firma por sí misma. La segunda es dejar que el proveedor de identidad sea la única parte que toca la credencial, y que el servicio de archivos verifique lo que el proveedor de identidad afirma sobre la autenticación que ya ocurrió.

Elegimos la segunda. Es federación en el sentido que le da NIST SP 800-63C, un nivel afirmado en lugar de un nivel que usted verificó por sí mismo, y vale la pena ser precisos sobre lo que eso aporta y lo que obliga.

Lo que realmente cuesta la segunda inscripción

El argumento a favor del primer diseño es que es autocontenido. El argumento en contra es todo lo que se deriva de una segunda superficie de inscripción.

Un usuario que inscribe una llave dos veces tiene dos credenciales que perder, en dos sistemas con dos rutas de revocación. Un operador que da de baja a ese usuario tiene dos lugares que revisar, y el segundo es el que nadie recuerda. Un auditor que pregunta "qué autenticador autorizó esta descarga" obtiene una respuesta de un sistema que no tiene idea de lo que ocurrió en el inicio de sesión. Y en el momento en que esos dos sistemas discrepan sobre quién es alguien, la capa de entrega es la que tiene que estar equivocada, porque no es el sistema de identidad.

La federación elimina toda esa superficie. La reemplaza por una obligación más estrecha: verificar la afirmación correctamente y ser honesto sobre lo que la afirmación significa.

Tres declaraciones, y la que todos olvidan

Un nivel afirmado llega como declaraciones en un token. Tres de ellas cargan con todo el contrato.

Qué ocurrió. La clase de contexto de autenticación, acr, es la declaración del proveedor de identidad sobre cómo el usuario demostró su identidad esta vez. Es la declaración de la que realmente depende la compuerta.

Para quién era. La audiencia. Sin una verificación de audiencia, un token emitido para su CMS satisface a su servicio de archivos, y cada otro cliente del mismo proveedor de identidad se convierte en una vía de entrada. Esta es la verificación que más a menudo se omite, porque omitirla nunca rompe nada de forma visible.

Cuándo. El vencimiento, y este es el que pasa desapercibido. La mayoría de los verificadores comprueban que un token no ha vencido. Muy pocos comprueban cuándo ocurrió realmente la ceremonia de autenticación. Si el suyo es uno de los muchos, entonces la vida útil del token es su ventana de aseguramiento, lo haya decidido alguien o no. Un token de doce horas significa que un toque a las nueve de la mañana sigue autorizando descargas a las nueve de la noche.

Hay dos correcciones honestas. Verificar la hora de autenticación o solicitar una antigüedad máxima, y rechazar un token cuya ceremonia sea más antigua de lo que su política permite. O acortar deliberadamente la vida útil del token, para que el mecanismo que ya tiene exprese la política que realmente quiere. Elegimos la segunda, escogimos una ventana medida en minutos y, este orden importa, solo la acortamos una vez que la aplicación podía renovar de forma transparente un token vencido. Una vida útil corta sin ruta de renovación no refuerza el aseguramiento; deja sesiones varadas.

No le ponga el nombre de una certificación contra la que no ha sido evaluado

Cualquier cadena que su proveedor de identidad estampe en esa declaración se convierte en un contrato publicado. La nuestra se revela a clientes no autenticados por diseño: cuando una solicitud llega sin autenticación suficiente, la respuesta correcta es un desafío que le dice al cliente qué sería suficiente, el patrón que RFC 9470 describe para la autenticación escalonada. El valor requerido sale en un encabezado, a cualquiera que lo pida.

Ese hecho zanjó para nosotros una discusión sobre nombres. El candidato obvio era una etiqueta de nivel de aseguramiento tomada del vocabulario de NIST. Se lee bien y todos la reconocen. También es una afirmación de cumplimiento, publicada en un encabezado, que tendríamos que defender a petición, y una parte confiante federada que verifica un nivel afirmado no es lo mismo que un verificador evaluado a ese nivel. Dos afirmaciones distintas, una cadena conveniente.

En su lugar usamos un valor del vocabulario del OpenID Enhanced Authentication Profile, uno que describe lo que realmente ocurrió: resistente al phishing, protegido por hardware. No es más corto ni más claro. Simplemente es cierto, y es una frase que podemos terminar frente a un evaluador.

La regla general: una cadena de aseguramiento es la descripción de un evento, no un certificado. Si se lee como un certificado, espere que le pidan el certificado.

Todo falla cerrado, incluidas las partes que nadie prueba

Una compuerta federada tiene más formas de estar mal configurada que una autocontenida, porque depende de que lleguen las declaraciones. Eso convierte la dirección de la falla en la decisión de diseño más importante de toda la funcionalidad.

Una lista vacía de valores de aseguramiento aceptados deniega en lugar de admitir. Una audiencia ausente deniega. Un token sin vencimiento se rechaza de plano, porque un token que nunca vence no permite razonar sobre él. Una declaración ausente es una verificación fallida, no una verificación omitida.

Esto suena obvio por escrito. Vale la pena decirlo de todos modos, porque la forma natural del código es la opuesta: obtiene una declaración, no encuentra nada, y lo que parece más prolijo es continuar. Los errores de falla abierta casi nunca parecen decisiones. Parecen un if que nadie escribió.

Lo que este diseño no le da

No convierte a su servicio de archivos en un verificador de hardware, y no debe describirlo como tal. Hereda el rigor del proveedor de identidad: si ese proveedor acepta un autenticador más débil para el mismo valor de aseguramiento, su compuerta también lo acepta, y ni el token ni su código se lo dirán. La fortaleza de todo el arreglo se fija en el proveedor de identidad y se afirma aguas abajo.

Lo que sí le da es una credencial, una inscripción, una ruta de revocación, un lugar donde se decide la fortaleza de la autenticación, y una descarga que no puede ser autorizada por nada que el proveedor de identidad no acabe de presenciar.

Es una afirmación más pequeña que "descargas verificadas por hardware". También es una que puede sostener en una revisión sin matizarla después, que es el único tipo de afirmación de seguridad que vale la pena publicar.