Metadatos, certificados y su rotación

Los metadatos SAML son un documento XML que cada parte publica sobre sí misma: su entityID, las direcciones de sus servicios, los formatos que admite y sus certificados, en elementos KeyDescriptor marcados para firma, para cifrado o para los dos. El metadato de un IdP dice con qué clave firma; el de un SP, a dónde se le entregan las respuestas y con qué clave se le cifran.

Como de ahí sale la clave en la que se confía, el metadato es tan sensible como la clave misma. Se obtiene por un canal autenticado: descargado por HTTPS de la dirección del otro, con su propia firma comprobada si la trae, o intercambiado una vez por un canal verificado. Un metadato que viaja sin cifrar ni firma puede cambiarse por el camino, y con él la clave en la que la aplicación va a creer. Además, el atributo validUntil dice hasta cuándo debe considerarse vigente esa copia.

La rotación ordenada de una clave de firma tiene cuatro pasos y ninguno se salta. El IdP publica el certificado nuevo junto al viejo. Cada SP lo incorpora y acepta los dos. En la fecha anunciada, el IdP empieza a firmar con el nuevo. Cuando vence el viejo, se retira de los metadatos y de cada SP. Un SP que toma los certificados de los metadatos de forma automática y segura pasa por esto sin hacer nada; uno que los cargó a mano tiene que hacerlo a tiempo.

Lee metadatos-tirimba.xml y aviso-tirimba.txt, y compáralos con lo que acepta hoy Quenaré.

Cuando el IdP empiece a firmar solo con un certificado que el SP no conoce, el SP rechazará todas las aserciones. Es fallar cerrado y es lo correcto, pero toda la empresa cliente se queda sin entrar, y la tentación del día es apagar la validación de firma «mientras se arregla». El trabajo de quien revisa es que ese día no llegue por sorpresa.

El SP también tiene certificado: con él firma sus solicitudes, si lo hace, y con su clave pública los IdP le cifran las aserciones. Rotarlo es el mismo baile visto desde el otro lado. El SP publica el nuevo junto al viejo en sus metadatos, cada IdP cliente lo descarga, el SP sigue aceptando ambos durante el solapamiento (para descifrar, eso significa conservar las dos claves privadas) y solo retira el viejo cuando sabe que todos sus clientes tienen el nuevo. Saberlo exige mirar qué copia tiene cada cliente, no suponerlo.

Lee descarga-metadatos.yml. Fíjate en el esquema de la dirección, en si se comprueba la firma de los metadatos y en si se respeta su vigencia.