Guía Técnica. Consumos de Servicios de Interoperabilidad usando protocolo SOAP

Transcripción

1 Guía Técnica Consumos de Servicios de Interoperabilidad usando protocolo SOAP Documento de Arquitectura Página 1 de 11

2 IDENTIFICACION Y CONTROL Título Autor Referencia/Asunto Ubicación Copia Electrónica Clasificación Detalle Pedro Carrasco Curín Documento de Arquitectura de la plataforma de interoperabilidad SIIS Sharepoint Institucional Confidencial CONTROL DE VERSIÓN Fecha Versión Autor Descripción Pedro Carrasco 1ra versión del documento Pedro Carrasco Se añade endpoint productivo Internet. Se añade ejemplo de uso de credenciales asociadas al consumo Pedro Carrasco Incorporación mecanismo de seguridad Firma y uso de certificados. APROBACIÓN DEL DOCUMENTO Nombre Persona Cargo Firma Fecha Marcelo Gonzalez Inostroza magonzalez@fonasa.gov.cl Director Proyecto SIIS Carlos Nuñez Contreras carlos.nunez_ext@fonasa.gov.cl Jefe de Proyecto Cuenta Médica Interoperable Alex Arevalo Vergara afarevalo@fonasa.gov.cl Jefe Proyecto Integraciones Proyecto SIIS Pedro Carrasco Curin pacarrasco@fonasa.gov.cl Arquitecto TI Documento de Arquitectura Página 2 de 11

3 Tabla de Contenido 1 Introducción Propósito Supuestos Ejemplos de Consumo Diccionario de Datos Llamadas de Pruebas Aspectos de Seguridad Aspectos Considerados Autenticación Firma Electrónica Autenticación Mutua Endpoint Publicado por Prestador y Caracteristicas del servicio Sincrónico Tamaño del mensaje Autenticación y Autorización Protección del Mensaje Codigos de Respuesta Insumo a Documento de Arquitectura Página 3 de 11

4 1 Introducción 1.1 Propósito El siguiente documento tiene por objetivo presentar una guía que indica a nivel de detalle técnico el consumo de un servicio web según los mecanismos y protocolos definidos en el proceso de la generación de la cuenta medica interoperable. 1.2 Supuestos Se asume que ya se han generado previamente: 1. Habilitar un canal de tipo HTTPS usando certificados digitales válidamente emitidos. 2. Habilitar un ambiente de QA a través de Internet. 3. Adquirir un certificado para firma digital simple, el mismo utilizado para facturación electrónica al SII. 4. Publicar por Internet servicios usando este protocolo. 5. Registrar el certificado de dentro de su plataforma de interoperabilidad. Documento de Arquitectura Página 4 de 11

5 1.3 Ejemplos de Consumo Diccionario de Datos El diccionario de datos se encuentra descripto en la guía de implementación del siguiente link: Llamadas de Pruebas Endpoint Internet Pruebas Endpoint Internet QA El servicio actualmente valida el token que acompaña al contenido de la invocación Request SOAP <soapenv:envelope xmlns:cuen=" xmlns:soapenv=" <soapenv:header> <wsse:security xmlns:wsse=" xmlns:wsu=" <ds:signature Id="SIG-3AE3A5A98A87B6458E " xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#id-3AE3A5A98A87B6458E "> <ds:transforms> <ds:transform Algorithm=" <InclusiveNamespaces PrefixList="cuen" xmlns=" </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>18dibqz4yiwrn1vg1h9ovhglhbu=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>tnsfpw2wb6pyfwt2hunswl7arriecbq7zdbja8qa12nlg4zh5dgltkgd3/jc6oqbebnqyvm/vfgb B+RyzQhbFvejETD4vjSZKyM/Xnwti66cUePkQn2ANse0m4n+tIneP1G/emFMH+QQ2rFZCE3OEH1K M1vyCBelTuTrXA74upMZ/AvNEZHCc3rJ5YVFdweMMaCSMekc0rIjD6nhcvJM8zeU6vueXxKhRM2r loosirnf46rt0nnuxdrx2qxx8dkt/stekzmq4a14b/eaxgdyhtt2dz45a3r4ikwlc2g7kowd9eyq ZOlNLJZTHDFimmLzVA5b+7PH1q06H7FckKChaA==</ds:SignatureValue> <ds:keyinfo Id="KI-3AE3A5A98A87B6458E "> <wsse:securitytokenreference wsu:id="str-3ae3a5a98a87b6458e "> <ds:x509data> <ds:x509issuerserial> <ds:x509issuername>cn=pedro Carrasco,OU=Proyecto SIIS,O=Fondo Nacional de Salud,L=Santiago,ST=Chile,C=CL</ds:X509IssuerName> <ds:x509serialnumber> </ds:x509serialnumber> </ds:x509issuerserial> </ds:x509data> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> <wsse:usernametoken wsu:id="usernametoken-3ae3a5a98a87b6458e "> <wsse:username>identificador_prestador</wsse:username> <wsse:password Type=" 1.0#PasswordText">la_clave_del_prestaor</wsse:Password> <wsse:nonce EncodingType=" 1.0#Base64Binary">wnU4Oso3nOshtMriYk3rTQ==</wsse:Nonce> Documento de Arquitectura Página 5 de 11

6 <wsu:created> t20:51:02.599z</wsu:created> </wsse:usernametoken> </wsse:security> </soapenv:header> <soapenv:body wsu:id="id-3ae3a5a98a87b6458e " xmlns:wsu=" wss-wssecurity-utility-1.0.xsd"> <cns:mensajehl7request xmlns:cns=" <cuen:tramadatos xmlns:cuen=" ^~\& SW_Clinica_el_Canelo K^ K^RUT SW_FONASA 0^ ^RUT ADT^A01^ADT_A P EVN A PID ^^^RegistroCivil^WP^^^^152&Chile&ISO Bermudez^Jorge Serna PV PR IN </cuen:tramaDatos> </cns:mensajehl7request> </soapenv:body> </soapenv:envelope> Response SOAP <soapenv:envelope xmlns:soapenv=" xmlns:cuen=" <soapenv:header /> <soapenv:body> <cuen:mensajehl7response> <cuen:tramadatos><![cdata[msh ^~\& FONASA^^ 0^ ^RUT SW_RegistroAdministr^^ ^ ^RUT ACK^A01^ACK 1025 P^ ADT_A01 MSA AA 0001]]></cuen:tramaDatos> </cuen:mensajehl7response> </soapenv:body> </soapenv:envelope> Documento de Arquitectura Página 6 de 11

7 2 Aspectos de Seguridad Para el caso de integraciones mediante protocolo SOAP se utilizará el intercambio de certificados al momento de generar el request, además de la implementación de un canal seguro el cual encriptara todo el tiempo la mensajería intercambiada entre las partes. 2.1 Aspectos Considerados Autenticación Cada invocación incluirá él envió de credenciales (usuario/contraseña) generadas por, enviados directamente en el encabezado SOAP (Header SOAP) con la implementación del Web Service Security (WSS) Firma Electrónica Se utilizara el certificado de firma digital adquirido para firmar cada invocación realizada, enviados directamente en el encabezado SOAP (Header SOAP) con la implementación del Web Service Security (WSS). Documento de Arquitectura Página 7 de 11

8 2.1.3 Autenticación Mutua Se adjunta un almacen de certificados y firma para ejectuar durante este proceso de pruebas, el cual es de tipo PKCS12. El contenido del almacen es: 1. Firma electronica para prestador genérico (emitida por ). REQUERIDO PARA SOAP. 2. Certificado https generico producción. 3. Certificado https generico qa. Archivo Almacen: fonasa_llave_pruebas.pfx Clave Almacén: CMI2017 Clave Llave: CMI2017 Documento de Arquitectura Página 8 de 11

9 3 Endpoint Publicado por Prestador y Según el mecanismo definido para la interoperabilidad se requiere que el prestador publique un endpoint donde generara una llamada de vuelta con la información resultante de la tributación inicial de información, la implementación de este endpoint será obligatoria asi tambien la publicación por Internet del mismo. El endpoint publicado por tendrá las mismas caracteristicas del servicio con excepción del uso del Token en vez de la Basic Authentitation 3.1 Caracteristicas del servicio implemento una plataforma de interoperabilidad con un enfoque en el uso de estandares del sector salud y mecanismos de comunicación, para mantener una homologación de la mensajeria y comunicaciones el servicio de recepción de mensajeria debe estar alineado con el principio declarado anteriormente (uso de estandares) Sincrónico El servicio publicado debe aceptar una invocación y debe retornar el estado de respuesta de la misma Tamaño del mensaje El mensaje de entrada y de salida no debe superar los 300 KB, en caso de superar este limite se generará el error 413 (ver tabla de errores) y se rechazará la petición Autenticación y Autorización Implementación UsernameToken El objeto UsernameToken contiene las informaciones para autentificar el usuario que llama un servicio de esta interfaz. A continuación se presenta un ejemplo de contenido de un objeto UsernameToken 1. Login: clinica Contraseña: _fds545$ Línea Contenido 1 <wsse:usernametoken xmlns:wsu=" wsu:id="id e9540a-1"> 2 <wsse:username>identificador_prestador</wsse:username> 3 <wsse:password Type=" 1.0#PasswordText">password123$</wsse:Password> 4 <wsu:created> t13:00:53z</wsu:created> 5 </wsse:usernametoken> Elemento <wsse:usernametoken> El objeto <wsse:usernametoken> contiene las informaciones para la autenticación. Este objeto debe ser contenido en el objeto Security del encabezado SOAP: El atributo xmlns:wsu hace referencia al URI de definición del namespace WSU (WebService Security Utility). El atributo wsu: Id corresponde a una cadena de caracteres específica al token utilizado. Documento de Arquitectura Página 9 de 11

10 Este atributo es generado automáticamente Elemento <wsse:username> El objeto <wsse:username> contiene el nombre del usuario. Este objeto es obligatorio y debe ser proporcionado por el usuario Elemento <wsse:password> El objeto <wsse:password> contiene la contraseña asociada al nombre del usuario. Este atributo es obligatorio y debe ser proporcionado por el usuario. La contraseña debe ser enviado sin protección (se transmite en texto sin cifrar) Elemento <wsse:created > Este elemento debe contener la fecha hora en que se ejecuta la invocación al servicio Elemento <wsse:signature> Este elemento debe las información de la firma electronica simple, y el elemento que se firma es el Body. Ejemplo: <ds:signature Id="SIG-3AE3A5A98A87B6458E " xmlns:ds=" <ds:signedinfo> <ds:canonicalizationmethod Algorithm=" <ds:signaturemethod Algorithm=" <ds:reference URI="#id-3AE3A5A98A87B6458E "> <ds:transforms> <ds:transform Algorithm=" <InclusiveNamespaces PrefixList="cuen" xmlns=" </ds:transform> </ds:transforms> <ds:digestmethod Algorithm=" <ds:digestvalue>18dibqz4yiwrn1vg1h9ovhglhbu=</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue>tnsfpw2wb6pyfwt2hunswl7arriecbq7zdbja8qa12nlg4zh5dgltkgd3/jc6oqbebnqyvm/vfgb B+RyzQhbFvejETD4vjSZKyM/Xnwti66cUePkQn2ANse0m4n+tIneP1G/emFMH+QQ2rFZCE3OEH1K M1vyCBelTuTrXA74upMZ/AvNEZHCc3rJ5YVFdweMMaCSMekc0rIjD6nhcvJM8zeU6vueXxKhRM2r loosirnf46rt0nnuxdrx2qxx8dkt/stekzmq4a14b/eaxgdyhtt2dz45a3r4ikwlc2g7kowd9eyq ZOlNLJZTHDFimmLzVA5b+7PH1q06H7FckKChaA==</ds:SignatureValue> <ds:keyinfo Id="KI-3AE3A5A98A87B6458E "> <wsse:securitytokenreference wsu:id="str-3ae3a5a98a87b6458e "> <ds:x509data> <ds:x509issuerserial> <ds:x509issuername>cn=pedro Carrasco,OU=Proyecto SIIS,O=Fondo Nacional de Salud,L=Santiago,ST=Chile,C=CL</ds:X509IssuerName> <ds:x509serialnumber> </ds:x509serialnumber> </ds:x509issuerserial> </ds:x509data> </wsse:securitytokenreference> </ds:keyinfo> </ds:signature> Protección del Mensaje El servicio debe ser publicado utilizando un canal seguro mediante https, con un certificado autofirmado para el servidor publicador. Documento de Arquitectura Página 10 de 11

11 De esta manera se asegura que el mensaje solo puede ser leido por el prestador que publica. Tambien se recomienda aplicar un filtrado por IP y habilitar solo IP de para recepcionar la información, autorizando las siguientes IP publicas. IP Públicas Descripción Ambiente Sub Dominio Seguro Plataforma de Interoperabilidad PRODUCCIÓN Plataforma de Interoperabilidad QA Codigos de Respuesta Se implementarán los siguientes códigos de respuesta que representarán el estado de la comunicación. Los estados de respuesta serán los definidos por la W3C en Codigo Estado Respuesta Glosa Error Descripción 500 Internal Server Error Error generico de procesamiento interno 415 Unsupported Media Type Falla validación de content-type 413 Request Entity Too Large El mensaje es más largo de lo definido 405 Method Not Allowed El metodo no esta permitido, solo acepta POST 403 Forbidden Usuario no logeado 401 Unauthorized Usuario no autorizado para acceder al servicio 200 OK Respuesta exitosa Los codigos de estado semantico del mensaje HL7 es definido dentro de las guías de implementación de la mensajeria Insumo a Para asegurar la el consumo del servicio publicado, el Prestador debe enviar un correo indicando la siguiente información. 1. URL del Servicio, indicando claramente el puerto. 2. Credenciales para generar el hash de Basic Authentication. 3. Proyecto de ejemplo con soapui para ser importado. El correo debe estar dirigido a: Carlos Nuñez Contreras carlos.nunez_ext@fonasa.gov.cl Copiando a: Alex Arevalo Vergara afarevalo@fonasa.gov.cl Pedro Carrasco Curin pacarrasco@fonasa.gov.cl en caso que la evaluación el endpoint entregado cumpliando estas caracteristicas se integrará el endpoint a la plataforma de interoperabilidad, en caso contrario se debe iterar una vez más para cumplir con las caracteristicas. Documento de Arquitectura Página 11 de 11