Pese a que el "espíritu" del standard de WebServices, WS-Security, y demas yerbas planteadas en las RFC supondrían una facilidad para la interoperabilidad ente diferentes plataformas, al intentar llevarlas a la realidad las asperezas surgen... y explotan en nuestra cara.
Hace un tiempo, en Lagash tuvimos que implementar un TokenManager (entre otras cosas) para poder traducir los llamados hechos desde WSE 3 a Java, utilizando certificados de seguridad.
Luego de estar funcionando sin problemas por casi dos años, el servicio comenzó a fallar al momento de recibir la respuesta de un pedido, con un mensaje que decía "WSE590: Failed to resolve the following key info"... y mostraba uno de los nodos de Key Info, conteniendo supuestamente el Subject Key Identifier del certificado necesario para desencriptar el mensaje.
El problema resultó ser que, dado que el nuevo certificado que comenzaron a usar no contenía la extensión de Subject Key Identifier, para poder identificarlo, tanto Java como WSE generaban un hash del certificado. El gran problema gran era que los hashes eran calculados de forma distinta!
Para poder solucionarlo, dentro del input filter de los mensajes hubo que reemplazar la porción de SOAP que indica el certificado a utilizar por una creada a mano que indique el certificado concreto (que, de hecho, siempre es el mismo que se utiliza al enviar el mensaje original).
Para mas información: http://support.microsoft.com/kb/922779/en-us (el problema no es exactamente el mismo, pero el approach para solucionarlo es muy similar).
Saludos!
Zaiden
2 comentarios:
Muy intersante el caso.
Una consulta.
¿Como llegaste a determinar que esa era la problemática?
¿A partir del caso de MS? O ese caso lo encontraste en función del workaround que realizaste.
Gracias,
Busque mucha mucha información y entre otras cosas logré encontrar eso, y lo confirmé con el caso de MS
Publicar un comentario