...

Tal y como se especifica en la Normativa de Seguridad publicada por la Unidad de Seguridad TIC (USTIC) al respecto de los requisitos de seguridad web y que se puede encontrar en este enlace:

• Para la comunicación entre el servicio web y el usuario hay que cifrar siempre los canales de comunicación mediante TLS, que es un protocolo criptográfico que permite cifrar los canales de comunicación. Este protocolo, aplica privacidad, autenticación e integridad de datos como propiedades del canal de comunicación. La versión mínima debe ser TLS 1.2 y además hay que evitar utilizar algoritmos y protocolos criptográficos que tengan debilidades significativas conocidas o que sean insuficientes para los requisitos de seguridad actuales.

• Para la comunicación con otras aplicaciones y/o servicios web, emplear una criptografía robusta como en el punto anterior, es decir, TLS 1.2 o superior con algoritmos y protocolos sin debilidades, sea cual sea el método o protocolo utilizado, por ejemplo, HTTPS o FTPS.

...

1. Llega el mensaje
2. Validación sintáctica y tique (para comprobar la fecha del tique se hace contra la fecha del mensaje NUNCA contra la del sistema)
    2.1 Si NO OK se devuelve NACK
    2.2 Si OK intentamos poner el mensaje en la cola de procesamiento del ámbito correspondiente (censo, demográfico, citas, ...)
        2.2.1 Si OK se devuelve ACK al ESB
        2.2.2 Si NO OK (error interno o similar que no nos permita encolar el mensaje) se devuelve un SOAP Fault

...

1. Llega el mensaje
2. Validación sintáctica y tique
    2.1 Si NO OK se devuelve error en el formato del servicio de respuesta síncrono concreto
    2.2 Si OK intentamos procesar el mensaje
        2.2.1 Si OK se devuelve la respuesta en el formato del servicio de respuesta síncrono concreto
        2.2.2 Si NO OK (error interno o similar) se devuelve error comprensible por el usuario en el formato del servicio de respuesta síncrono concreto.

...

En cualquiera de los casos, los detalles técnicos de la configuración de Weblogic y los servidores JMS se hará teniendo en cuenta el criterio de Sistemas y las directrices de Arquitectura.

Validación del tique de Maco:

La validación del ticket de MACO se realiza en los sistemas de destino de las transacciones. Esta validación del ticket de MACO implica tres acciones una vez se recibe el ticket en el sistema de destino:

1. Validar que el ticket y la firma son correctos.  

El tique y firma que viaja en el mensaje se valida mediante un algoritmo en local, que se basa en generar un MD5 del tique, se decodifica la firma con la clave pública de Maco y se comparan ambos hashes, si coinciden el tique no ha sido modificado desde que lo creó Maco y podemos confiar en él. Esto se hace sin necesidad de invocar a sistemas externos.

2. Con la certeza de que el tique no ha sido alterado, pasamos a validar la fecha que se incluye en el ticket. 

Dependiendo de la tipología del mensaje, la validación de la fecha se debe hacer con la fecha de creación del mensaje, para los servicios asíncronos, o con la fecha del sistema, para los servicios síncronos. En ambas casuísticas la diferencia entre las fechas con respecto a la del tique debe ser menor de 24 horas, siendo la fecha del tique siempre la más antigua.

3. Validar que el tique dispone de la operación permitida sobre el servicio al que se está invocando. 

De esta forma validamos que el operador dispone de permisos para realizar la operacion sobre ese servicio.

En caso de incumplimiento de cualquiera de las validaciones indicadas en los puntos anteriores, el sistema destino, debe notificar al origen el error con una descripción precisa.