La aserción y qué partes van firmadas

Una respuesta SAML (samlp:Response) envuelve una o más aserciones (saml:Assertion). La aserción es la que dice quién es la persona: su identificador en Subject, las condiciones de uso en Conditions, cómo se autenticó en AuthnStatement y sus atributos en AttributeStatement. El estándar permite firmar la respuesta, la aserción o las dos.

La firma XML no cubre «el mensaje»: cubre el elemento al que apunta su Reference URI, con todo lo que ese elemento contiene. Si apunta al ID de la respuesta, queda protegida la respuesta entera, con la aserción dentro. Si apunta al ID de la aserción, queda protegida la aserción, pero no lo que esté fuera de ella. Por eso quien revisa un SP lee la referencia antes de leer nada más.

Abre las tres respuestas. En cada una, busca dónde está el elemento ds:Signature y a qué ID apunta su ds:Reference. Una empresa firma la aserción, otra firma la respuesta completa. Las dos formas son válidas siempre que el SP compruebe que lo que usa está dentro de lo firmado.

El fallo clásico de un SP no está en la criptografía, sino en lo que hace alrededor. Si el código busca «una firma» en el documento, la valida, y después busca por separado «una aserción» para leer el usuario, nada garantiza que las dos sean la misma pieza. Un documento puede llevar una aserción firmada correctamente y otra distinta que es la que el código termina usando. La hoja de buenas prácticas de SAML de OWASP pide validar el XML contra el esquema antes de procesarlo, leer los elementos por su posición exacta en el documento y comprobar que la aserción que se usa es la cubierta por la firma validada.

Lee procesar_respuesta.py y la nota al final.

La firma también se juzga por su algoritmo. SignatureMethod dice cómo se firmó y DigestMethod cómo se resumió el elemento antes de firmarlo. SHA-1 ya no se considera adecuado para firmas digitales, y NIST lo retiró para generarlas; la hoja de OWASP pide RSA con SHA-256 o más fuerte y rechazar SHA-1 tanto en la firma como en el resumen. Un SP que acepta cualquier algoritmo que le declare el mensaje hereda la debilidad del más viejo de sus clientes.

Desde el 5 de octubre el servicio de consumo anota dos datos de cada respuesta: el ID al que apuntaba la firma validada y el ID de la aserción que leyó. Cuando la firma cubre la respuesta entera, es normal que los dos difieran: la aserción está dentro. Cuando la firma cubre una aserción, los dos deben coincidir. Recorre registro-acs.txt con esa regla.