Documento Técnico para la Interoperabilidad de los Sistemas Automatizados de Control de Gestión

Transcripción

1 Documento Técnico para la Interoperabilidad de los Sistemas Automatizados de Control de Gestión Sesión de asesoría SECRETARIA DE LA FUNCIÓN PÚBLICA SUBSECRETARÍA DE LA FUNCIÓN PÚBLICA UNIDAD DE GOBIERNO DIGITAL Julio 2012

2 Bienvenidos

3 Agenda del Día I. Introducción y Antecedentes de los SACG II. Proceso de Elaboración del DTI de los SACG III. Qué es el DTI de los SACG? IV. Convergencia con la Ley de Firma Electrónica Avanzada V. Principales conceptos técnicos: Cifrado (Criptografía) Firma Digital Estampado de tiempo Estructuras XML del DTISACG (Anexo 2) VI. Las operaciones de Interoperabilidad del DTISACG 1 Registro de Instancia en la Plataforma 2 Solicitud de Suscripción entre Instancias 3 Sincronización Completa, Instancia a OPE 4 Sincronización Completa, OPE a Instancia 5 Sincronización Parcial de Directorios, Instancia a OPE 6 Sincronización Parcial de Directorios, OPE a Instancia 7 Envió de Solicitud 8 Envió de Respuesta VII. Convenciones de Comunicación A Protocolo Instancia OPE B Protocolo Instancia Instancia

4 I. Introducción y Antecedentes de los SACG II. Proceso de Elaboración del DTI de los SACG III. Qué es el DTI de los SACG? IV. Convergencia con la Ley de Firma Electrónica Avanzada

5 DTI de los SACG UNIDAD DE GOBIERNO DIGITAL Oficio No. UGD/409/442/2012 México, D. F., a 28 de mayo de Es necesario que las áreas administrativas responsables de TIC en cada institución, inicien los trabajos de adecuación de los actuales SACG con base en las directrices, operaciones y componentes contemplados en el DTISACG, e informen a esta Unidad, dentro de los 15 días hábiles siguientes a la recepción del presente oficio, la fecha prevista para la conclusión de las adecuaciones correspondientes. Julio 2012 Julio 2013: Firmado de oficios entre dependencias

6 DTI de los SACG Paperless De una administración pública basada en papel a una digital

7 DTI de los SACG 9 de diciembre del 2005 se crea la Comisión Intersecretarial para el Desarrollo del Gobierno Electrónico (CIDGE). En el acuerdo de creación de la CIDGE se crea también la Subcomisión de los Sistemas Automatizados de Control de Gestión. El 24 de abril de 2006 se publican los Lineamientos para la operación, funcionalidad, comunicación y seguridad de los sistemas automatizados de control de gestión. El 15 de diciembre de 2010 la CIDGE aprueba la ejecución del proyecto de interoperabilidad de los SACG. El 10 de febrero de 2011 la CIDGE formaliza la instalación del Grupo de trabajo para la elaboración del DTISACG.

8 DTI de los SACG El 6 de septiembre de 2011 la SFP publica el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal (EIDA). En noviembre de 2011 se lleva a cabo la instalación de la OPE en la SFP. El 16 de diciembre de 2011 se envío el primer Oficio Electrónico entre SCHP y SFP a través de la OPE. El 11 de enero de 2012 se publicó la Ley de Firma Electrónica Avanzada (LFEA). El 28 de mayo de 2012 se da a conocer mediante oficio el DTISACG.

9 DTI de los SACG Sistema Automatizado de Control de Gestión (SACG) SACG Lineamientos para la operación, funcionalidad, comunicación y seguridad de los sistemas automatizados de control de gestión. Publicado el: 24 de abril de 2006 Los objetivos principales de los lineamientos son los siguientes: Mejorar la gestión y trámites de los asuntos administrativos; Contar con un único sistema automatizado de control de gestión por cada dependencia o entidad; Asegurar la confidencialidad, integridad y resguardo de la información; Permitir la intercomunicación entre los sistemas de control de gestión; Utilizar la firma electrónica avanzada; Disminuir sustancialmente el uso de papel y gastos de mensajería.

10 DTI de los SACG Sistema Automatizado de Control de Gestión (SACG) SACG Que son los Documentos Técnicos de Interoperabilidad (DTI)? Documentos que establecen modelos de intercambio de información entre dos o más instituciones, sistemas o procesos. Incluyen disposiciones que deben tener en cuenta las instituciones para habilitar la interoperabilidad. Los DTI se apegan a los estándares de interoperabilidad organizacional, semántica y técnica, establecidos en el Esquema de Interoperabilidad y Datos Abiertos (EIDA), publicado el 6 de septiembre de 2011, entre los que destacan los siguientes: Establecen modelos de datos comunes, de aplicación obligatoria para el intercambio de información. Usan estándares abiertos con el fin de garantizar la independencia y neutralidad tecnológica. Mantienen los principios de seguridad, privacidad, confidencialidad e integridad de la información.

11 DTI de los SACG Sistema Automatizado de Control de Gestión (SACG) SACG Actividades de elaboración del DTI efectuadas por el Grupo de trabajo: Elaboración de documento base. Interoperabilidad de los SACG Se efectúan seis sesiones de trabajo y queda concluido el DTI y sus anexos en el mes de abril de 2011 en su versión inicial. HTTPS Firma Electrónica SACG A SACG B Firma Electrónica Se publica el DTI en el Portal de la CIDGE a fin de recibir opiniones de las dependencias y entidades miembros del Consejo Ejecutivo. A Web Services C B Firma electrónica Estampado de tiempo Verificación del Mensaje Verificación de Destinatario Verificación de Contenido Oficina Postal Electrónica (Ruteador) HTTPS En junio de 2011 se cierra la versión del DTI y se envía a revisión jurídica en la SFP.

12 DTI de los SACG Sistema Automatizado de Control de Gestión (SACG) SACG 28 de mayo de 2012 Se da a conocer mediante oficio el Documento Técnico de Interoperabilidad de los Sistemas Automatizados de Control de Gestión (DTISACG) Documento Técnico de Interoperabilidad de los Sistemas Automatizados de Control de Gestión (DTI-SACG) Es el primer modelo de interoperabilidad del gobierno mexicano alineado al EIDA, al cual deberán apegarse las dependencias y entidades de la Administración Pública Federal, así como la Procuraduría General de la República para la integración de los sistemas automatizados de control de gestión con que operan, lo cual permitirá el intercambio de oficios electrónicos legalmente válidos, con los consecuentes ahorros en el uso de papel, en los tiempos de elaboración y entrega de las comunicaciones, así como en el costo de almacenamiento y volumen de los archivos, incrementando así la eficiencia operativa de la Administración Pública Federal.

13 DTI de los SACG Miembros del Grupo de trabajo instaurado por la Subcomisión de los SACG: APF Industria Academia SHCP SFP SEGOB SRE STPS SSP SCT SAT CFE CONAGUA PEMEX IMSS IFAI (Invitado) Cámara Nacional de la Industria Electrónica, de Telecomunicaciones y Tecnologías de la Información (CANIETI) Consultoría y Aplicaciones Avanzadas de ECM S.A. de C.V. Document Imaging México, S.A. de C.V. MEVE Soluciones S.A. de C.V. Servicio y Soporte en Tecnología Informática S.A. de C.V. (Pegaso Tecnología). Instituto Politécnico Nacional (IPN), a través del Centro Nacional de Cálculo Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) Universidad Iberoamericana Ciudad de México (UIA)

14 DTI de los SACG Esquema de Interoperabilidad y Datos Abiertos (EIDA) EIDA Publicado en el DOF: 6 de septiembre de 2011 Entrada en vigor: Día siguiente a su publicación 21 de Septiembre de 2011 Quedó instalada formalmente la Subcomisión de Interoperabilidad en la CIDGE Interoperabilidad: La capacidad de organizaciones y sistemas, dispares y diversos, para interactuar con objetivos consensuados y comunes, con la finalidad de obtener beneficios mutuos, en donde la interacción implica que las dependencias y entidades compartan infraestructura, información y conocimiento mediante el intercambio de datos entre sus respectivos sistemas de tecnología de información y comunicaciones;

15 DTI de los SACG Esquema de Interoperabilidad y Datos Abiertos (EIDA) EIDA Establecer un Esquema de Interoperabilidad y Datos Abiertos de la Administración Pública Federal centrado en el ciudadano, que integre promueva y detone las operaciones digitales entre las instituciones con el fin fomentar una operación interna mas eficiente, mejorar la toma de decisiones y ofrecer mejores servicios públicos. El Modelo del Esquema de Interoperabilidad y Datos Abiertos está enfocado en la creación de las condiciones necesarias que garanticen el adecuado nivel de interoperabilidad técnica, semántica, organizativa y de gobernabilidad de los servicios, sistemas y aplicaciones de la Administración Pública Federal

16 DTI de los SACG Esquema de Interoperabilidad y Datos Abiertos (EIDA) EIDA Gobernanza Se ocupa de las condiciones políticas, legales, y estructurales Organizacional: Asegura la coordinación y el alineamiento de los procesos que intervienen en la provisión de los servicios Semántica: Se ocupa del significado en el uso de los datos y la información Técnica: Se refiere a aquellas cuestiones que garantizan que los componentes tecnológicos estén preparados para interactuar juntos.

17 DTI de los SACG Esquema de Interoperabilidad y Datos Abiertos (EIDA) EIDA Entre los principales beneficios del EIDA se describen los siguientes: Promueve servicios convergentes que reducen costos de transacción al ciudadano. Reduce costos operativos al impulsar una mayor utilización de servicios electrónicos gubernamentales como son la Firma Electrónica, el RUPA y la CURP. Permite una interacción ordenada, eficiente y transparente entre sistemas y bases de datos gubernamentales. Propicia el avance en transacciones con dispositivos fijos y móviles.

18 DTI de los SACG EIDA Esquema de Interoperabilidad y Datos Abiertos (EIDA) Artículo Décimo: La Infraestructura de Servicios de Interoperabilidad estará conformada por los documentos técnicos que serán emitidos por la Secretaría y desarrollados con apoyo de la Subcomisión Artículo Décimo Segundo: Las dependencias y entidades en la prestación de servicios digitales deberán: II. Observar los documentos técnicos que en materia de interoperabilidad emita la Secretaría; Artículo Décimo Tercero: Corresponderá a la Secretaría, con el apoyo de la Subcomisión: I. Emitir los documentos técnicos a los que hace referencia el presente Acuerdo y, en su caso, guías para la interoperabilidad entre aplicaciones o sistemas de las dependencias y entidades, considerando las dimensiones organizacional, semántica, técnica y de gobernabilidad;

19 DTI de los SACG Ley de Firma Electrónica Avanzada (LFEA) LFEA Publicada en el DOF: El 11 de enero de 2012 Entrada en vigor: El 4 de julio de 2012 Artículo décimo: Las dependencias y entidades en las comunicaciones y, en su caso, actos jurídicos que realicen entre las mismas, harán uso de mensajes de datos y aceptarán la presentación de documentos electrónicos, los cuales deberán contar, cuando así se requiera, con la firma electrónica avanzada del servidor público facultado para ello Por lo que la observancia del DTISACG por parte de las dependencias y entidades de la APF, coadyuvará al cumplimiento de la LFEA.

20 DTI de los SACG Oficina Postal Electrónica (OPE) OPE Actividades efectuadas por la UGD y el Grupo de Piloto : En noviembre de 2011 se concluye la instalación de la OPE en la SFP y se constituye el Grupo Piloto por la SHCP, SSP, SCT y COFETEL para verificar la funcionalidad de la OPE. En 16 de diciembre de 2011 se efectúa el envío del primer Oficio Electrónico entre SCHP y SFP a través de la OPE. Se concluyen las pruebas entre SCT y COFETEL así como entre SSP y su Sector. Durante el mes de enero de 2012 se efectuaron pruebas adicionales con la OPE y el 28 de mayo se dio a conocer mediante oficio emitido por la Unidad de Gobierno Digital, las disposiciones necesarias para su aplicación en la APF.

21 DTI de los SACG Oficina Postal Electrónica (OPE) OPE OCSP/HTTP OCSP/HTTP HTTPS Firma Electrónica SACG - Instancia A HTTPS Firma Electrónica SACG - Instancia B HTTPS Web Services A B C SFP - SAT OCSP/HTTP Log de trazabilidad Oficina Postal Electrónica /Ruteador Firma Electrónica

22 DTI de los SACG LFEA EIDA Nace el Oficio Electrónico Legalmente Válido SACG OPE

23 DTI de los SACG Contenido 1. Objeto 2. Definiciones 3. Plataforma 4. Directrices de Interoperabilidad de la Plataforma 5. Operaciones de Interoperabilidad Registro de Instancia Solicitud de suscripción Sincronización completa Instancia-OPE Sincronización completa OPE-Instancia Sincronización parcial de directorios, Instancia a OPE Sincronización parcial de directorios, OPE a Instancia Envío de Solicitud Envío de Respuesta Descripción de códigos de error 6. Servicios de Interoperabilidad 7. Consideraciones de seguridad Comunicación Firma Electrónica Estampado de tiempo Firmas en anexos 8. Convenciones de comunicaciones Protocolo Instancia- OPE Protocolo Instancia- Instancia 9. Referencias a estándares 10. Anexos

24 Búsqueda del DTISACG y EIDA en la Normateca

25 V. Principales conceptos técnicos Cifrado (Criptografía) Firma Digital Estampado de tiempo Estructuras XML del DTISACG (Anexo 2) Llave publica Texto plano Texto cifrado Llave privada

26 Antecedentes Definición Los datos en forma electrónica consignados en un mensaje de datos, o adjuntados o lógicamente asociados al mismo, que puedan ser utilizados para identificar al firmante en relación con el mensaje de datos e indicar que el firmante aprueba la información recogida en el mensaje de datos (UNCITRAL). El conjunto de datos y caracteres que permite la identificación del firmante, que ha sido creada por medios electrónicos bajo su exclusivo control, de manera que está vinculada únicamente al mismo y a los datos a los que se refiere, lo que permite que sea detectable cualquier modificación ulterior de éstos, la cual produce los mismos efectos jurídicos que la firma autógrafa, de conformidad con la Ley de Firma Electrónica Avanzada.

27 Antecedentes De acuerdo a la UNCITRAL para que una firma electrónica sea considerada como avanzada: a) Los datos de creación de la firma, en el contexto en el que son utilizados, corresponden exclusivamente al firmante. b) Es posible detectar cualquier alteración de la firma electrónica hecha después del momento de la firma. Integridad No repudio Confidencialidad Autenticidad Confidencialidad: se refiere a la capacidad de mantener un documento electrónico inaccesible a todos, excepto a una lista determinada de personas. Autenticidad se refiere a la capacidad de determinar si una lista determinada de personas han establecido su reconocimiento y/o compromiso sobre el contenido del documento electrónico.

28 Antecedentes Integridad No repudio Confidencialidad Autenticidad Integridad: se entiende que cuando se envíe un mensaje de una persona a otra o bien de una máquina a otra, este mensaje no sea modificado, sin que el destinatario pueda comprobarlo. La modificación se refiere tanto a una modificación explícita por alguien como a una modificación debido a un error (por ejemplo de transmisión). No Repudio: se hace referencia a la capacidad de afirmar la autoría de un mensaje o información, evitando que el autor niegue la existencia de su recepción o creación.

29 Criptografía Criptografía Simétrica: Es el sistema de cifrado más antiguo y consiste en que tanto el emisor como el receptor encriptan y desencriptan la información con una misma clave k (clave secreta) que ambos comparten. El funcionamiento es muy sencillo: el emisor cifra el mensaje con la clave k y se lo envía al receptor. Este último, que conoce dicha clave, la utiliza para desencriptar la información. Algoritmos típicos que utilizan cifrado simétrico son DES, IDEA, RC5, etc. El mayor inconveniente de la criptografía simétrica es que esta clave k, al ser compartida, ha de ser comunicada de forma segura entre las dos partes de la comunicación (por teléfono, correo certificado, etc.), previamente a ésta. Si este secreto fuese enviado por un canal inseguro, como por ejemplo Internet, la seguridad del sistema sería bastante pobre, dado que cualquiera podría interceptarla y comprometer todo el sistema. También hay que tener en cuenta la frecuencia con la que esta clave debe ser renovada para evitar que sea descubierta.

30 Criptografía Criptografía Asimétrica (de llaves públicas): Estos criptosistemas están basados en propiedades matemáticas de los números primos, que permite que cada interlocutor tenga una pareja de claves propias. De esta pareja de claves, una se denomina privada o secreta y la otra, pública. La clave privada no se transmite nunca y se mantiene secreta. La clave pública, por el contrario, se puede y se debe poner a disposición de cualquiera, dado que es imposible deducir la clave privada a partir de la pública. El más extendido de los sistemas de clave pública fue desarrollado por Rivest, Shamir y Adleman en el MIT en 1977 y se conoce como RSA. La principal ventaja de este tipo de criptosistemas es que la clave secreta ya no tiene que transmitirse entre los interlocutores y tampoco es necesario tener claves diferentes para cada pareja de interlocutores, es suficiente con que cada usuario tenga su clave doble con componente pública y privada. A estos sistemas se les denomina de firma electrónica.

31 Criptografía Asimétrica (de llaves publicas) El procedimiento de firmado consiste en que, mediante un programa de cómputo, un sujeto alimenta un documento a firmar y su llave privada (que sólo él conoce). El programa produce como resultado un mensaje digital denominado firma electrónica. Juntos, el documento y la firma, constituyen el documento firmado. Llave Privada Mensaje en claro Función HASH + = Documento firmado Mensaje en claro Valor hash FIRMA DIGITAL

32 Verificación de Autenticidad El proceso de autenticación consiste en que, mediante un programa de cómputo, se alimenta un documento firmado y la llave pública del supuesto firmante; el programa indica si es auténtico o no es auténtico. Mensaje en claro Función HASH Valor hash = Documento firmado FIRMA DIGITAL Valor hash Llave Pública

33 Generación de Digestión (Hash) Un algoritmo de digestión (hash) toma como entrada un documento de cualquier longitud y produce un mensaje digital de longitud fija con características singulares. Si dos digestiones de dos documentos son iguales, entonces significa que ambos documentos son iguales, o son totalmente diferentes. Si un documento produce una digestión X entonces cualquier variación al documento, por pequeña que sea, produce una digestión diferente de X. La digestión X de un documento es irreversible, es decir, no puede conocerse el contenido del documento a partir de conocer X. El emitir un recibo de la digestión de un documento es equivalente a atestiguar el documento en sí. Además la digestión no revela el contenido del documento. Los principales algoritmos de digestión son SHA1 y MD5. Función HASH Valor hash

34 Infraestructura de Llave Pública Una Infraestructura de Llave Pública (o en inglés, PKI, Public Key Infrastructure) es una combinación de hardware y software, tecnologías de cifrado, servicios, políticas y procedimientos que permiten proteger la seguridad de las transacciones de información en un sistema distribuido. La PKI integra certificados digitales, criptografía de llave pública y autoridades de certificación en una arquitectura de seguridad unificada. Los servicios de seguridad que puede proporcionar una PKI son: Confidencialidad Integridad Autenticidad Comunicación segura Privacidad No-repudio No-repudio de origen No-repudio de recepción Administración de privilegios

35 Certificado Digital El Certificado Digital es un documento firmado digitalmente por una persona o entidad denominada Autoridad Certificadora, dicho documento establece una liga entre un sujeto, su llave pública y privada. Es decir, el Certificado Digital es un documento firmado por la Autoridad Certificadora (AC), el documento contiene el nombre de un sujeto y su llave pública.

36 Validación de un Certificado Digital Online Certificate Status Protocol (OCSP) es un método para determinar el estado de revocación de un certificado digital X.509 usando otros medios que no sean el uso de CRL (Listas de Revocación de Certificados). Este protocolo se describe en el RFC 2560 y está en el registro de estándares de Internet. Los mensajes OCSP habitualmente se transmiten sobre el protocolo HTTP. OCSP puede proporcionar una información más adecuada y reciente del estado de revocación de un certificado. Realizar las siguientes validaciones antes de realizar una firma electrónica: X Que el Certificado Digital haya sido emitido por una Autoridad Certificadora confiable o aceptada por el receptor del mensaje Que el Certificado Digital este en su período de validez Que el Certificado Digital no esté revocado

37 Estampado de Tiempo TSP (Time Stamp Protocol): Permite generar estampillas de tiempo que amparan la existencia de un contenido a una determinada fecha y hora. Estas estampillas son firmadas por la Oficialía de Partes o TSA (Time Stamp Authority). La especificación del protocolo se encuentra en el RFC Es sumamente importante poder ubicar con exactitud el momento en que se firmó el documento ya que esto ayuda a determinar si el contenido en su ámbito aplicativo tenía validez en ese momento.

38 Interoperabilidad y XML Interoperabilidad: A la capacidad de organizaciones y sistemas, dispares y diversos, para interactuar con objetivos consensuados y comunes, con la finalidad de obtener beneficios mutuos, en donde la interacción implica que las dependencias y entidades compartan infraestructura, información y conocimiento mediante el intercambio de datos entre sus respectivos sistemas de tecnología de información y comunicaciones. XML: Lenguaje común para que los diferentes sistemas de información puedan entenderse e intercambiar información de manera adecuada y eficiente. Define conceptos y la estructura de los servicios de forma que puedan ser entendidos por todos los involucrados. Por lo anterior se ha decidido utilizar XML como una especificación para el intercambio de información entre los Sistemas Automatizados de Control de Gestión.

39 Interoperabilidad y XML Los esquemas XML (XSD) permiten el desarrollo de vocabularios compartidos y en cuanto a los sistemas de información validar la información realizada por personas. La especificación de esquemas XML se compone de los siguientes elementos: Un conjunto de estructuras definidas: reglas y características que se deben tener en cuenta para generar mediante documentos XML un esquema XML. Un conjunto de tipos de datos básicos que deben ser utilizados para la definición de los demás elementos. La Plataforma de Interoperabilidad de la OPE especificada en el DTISACG y sus Anexos correspondientes utiliza esquemas XML, para definir de forma precisa el tipo de elementos aceptados por el estándar, así como las restricciones de los elementos.

40 Interoperabilidad y XML Anexo 1 del DTISACG Archivo PDF de nombre: DTISACG anexo 1 Contiene información detallada sobre los elementos y tipos de datos especificados en la estructura XSD del Anexo 2. Representa una guía útil obtenida de la estructura XSD definida para los tipos de datos de interoperabilidad del DTISACG, sus usos (requeridos u opcionales), atributos y propiedades que típicamente se visualizan con la ayuda de en un editor XML.

41 Interoperabilidad y XML Anexo 2 del DTISACG Archivo de nombre: TiposDeDatosInteroperabilidad.xsd

42 Firma XML Firma XML (también llamado XMLDsig, DSig XML, XML-Sig) es una recomendación del W3C que define una sintaxis XML para la firma digital. Funcionalmente, tiene mucho en común con PKCS#7 (Estándar de Firmado de RSA), pero es más extensible y está orientada hacia la firma de documentos XML. Una firma XML consiste en un elemento Firma en el espacio de nombres de La estructura básica es la siguiente:

43 Firma XML El elemento SignedInfo contiene o referencia los datos firmados y especifica qué algoritmo se usa. Los elementos SignatureMethod y CanonicalizationMethod son usados por el elemento SignatureValue y están incluidos en SignedInfo para evitar que sean modificados. Uno o más elementos Reference especifican el recurso que se está firmando por la referencia URI y cualquier transformación que vaya a aplicarse al recurso antes de firmar. DigestMethod especifica el algoritmo hash antes de aplicar el hash. DigestValue contiene el resultado de aplicar el algoritmo hash a el (o los) recurso(s) transformado(s).

44 Firma XML El elemento SignatureValue contiene el resultado de una firma codificada en Base64 (la firma generada con los parámetros especificados en el elemento SignatureMethod) del elemento SignedInfo después de aplicar el algoritmo especificado por el CanonicalizationMethod. El elemento KeyInfo permite opcionalmente al firmante proporcionar recipientes con la clave que valida la firma, generalmente en la forma de uno o más certificados digitales X.509. La parte restante debe identificar la clave del contexto si no está presente KeyInfo. El elemento Object (opcional) contiene los datos firmados en caso de ser una firma envolvente.

45 VI. Las operaciones de Interoperabilidad del DTISACG

46 Operaciones de Interoperabilidad El DTISACG plantea 8 escenarios mediante los cuales se construye el flujo de mensajes y sus operaciones de interoperabilidad, enseguida se describe cada uno de ellos. 1 Registro de Instancia en la Plataforma Solicitud de Suscripción entre Instancias Sincronización Completa, Instancia a OPE Sincronización Completa, OPE a Instancia Sincronización Parcial de Directorios, Instancia a OPE Sincronización Parcial de Directorios, OPE a Instancia Envió de Solicitud Envió de Respuesta

47 1 Registro de Instancia en la Plataforma Descripción: Escenario que permite el registro de una Instancia en una Comunidad. Precondiciones: Contar con certificado de Firma Electrónica Avanzada vigente para la Instancia. Protocolo de Comunicación: En el intercambio de Mensajes de este escenario se aplica el Protocolo Instancia-OPE. Tipos de Datos: En este escenario se envía un Mensaje de tipo SolicitudRegistro con un elemento tipo SolicitudRegistro que representa la solicitud de registro de una Instancia en la OPE, para efectuar operaciones de interoperabilidad.

48 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A genera Mensaje-1 de tipo SolicitudRegistro Identificador del mensaje Datos de la Instancia -Id- Fecha de envío Certificado Digital (de la Instancia) Reto (cadena generada por la Instancia, la cual es cifrada con su clave privada) Instancia A Envío del Mensaje-1 Solicitud de Registro a la OPE OPE La OPE realiza las siguientes validaciones 1) La existencia de la Instancia A en la Comunidad. 2) La vigencia y legitimidad del Certificado Digital de la Instancia A.

49 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A 1) La existencia de la Instancia A en la Comunidad Verifica que el -Id- de la Institución no esté registrado en el DCI* de la OPE. Si no existe el registro, procede a hacer la validación del Certificado Digital de la Instancia A ( ver siguiente diapositiva). Si ya existe un registro, genera el Mensaje-2 de tipo RespuestaSolicitudRegistro con el rechazo de la solicitud de registro por -Id- duplicado en el DCI. OPE *DCI = Directorio Consolidado de Interoperabilidad

50 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A Nota: Este escenario de validación ocurre poco antes de la respuesta de la OPE a la Instancia A (mostrada en la siguiente diapositiva). 2) La vigencia y legitimidad del Certificado Digital de la Instancia A Si es válido y está vigente, la OPE procede a generar: Una cadena aleatoria encriptada asimétricamente con algoritmo RSA, y cifra la cadena aleatoria enviada por la Instancia A con la clave privada de la OPE. El Mensaje-2 de tipo RetoSolicitudRegistro con la cadena aleatoria de la OPE encriptada, el Certificado Digital de la OPE y la cadena aleatoria recibida en el Mensaje-1 Reto deberá estar cifrada con la clave privada de la OPE. Si no es válido: Genera el Mensaje-2 de tipo RechazoSolicitudRegistro con el rechazo de la solicitud de registro por Certificado Digital inválido. OPE

51 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A La OPE responde a la Instancia A para lo cual Descifra la cadena aleatoria especificada en el elemento Reto del Mensaje-1, utilizando la clave pública del Certificado Digital de la Instancia A y la cifra con la clave privada de su Certificado Digital introduciendo la cadena cifrada en el elemento RespuestaReto. Genera una cadena aleatoria y la cifra con su clave privada, que es introducida en el elemento Reto. Responde al Mensaje-1 de la Instancia A, con el Mensaje-2. OPE

52 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Envio del Mensaje-2 a Instancia A, en respuesta al Mensaje-1 Instancia A OPE Si el Mensaje-2 es de tipo RechazoSolicitudRegistro, la Instancia A registra el rechazo y se culmina la operación; de lo contrario Si el Mensaje-2 es de tipo RetoSolicitudRegistro se continua con el siguiente escenario.

53 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A La Instancia A valida el Certificado Digital de la OPE y su vigencia Si es válido y está vigente, descifra la cadena especificada en el elemento RespuestaReto, utilizando la clave pública del Certificado Digital de la OPE. Si hay coincidencia entre las cadenas descifradas de RespuestaReto del Mensaje-2 y la que la Instancia generó e insertó en el elemento Reto del Mensaje-1: la Instancia reconoce a la OPE como válida para el registro en la Comunidad. Si no hay coincidencia entre las cadenas la Instancia rechaza a la OPE y detiene su registro en la Comunidad. Si no es válido, detiene su registro en la Comunidad. OPE

54 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Envío del Mensaje-3 a la OPE, en respuesta al Mensaje-2 Instancia A OPE La Instancia A envía un Mensaje-3 a la OPE, para lo cual Previamente descifra la cadena aleatoria especificada en el elemento Reto del Mensaje-2, utilizando la clave pública del Certificado Digital de la OPE y la cifra con la clave privada de su Certificado Digital, e introduce la cadena cifrada en el elemento RespuestaReto del Mensaje-3.

55 1 Registro de Instancia en la Plataforma Flujo normal de eventos: Instancia A La OPE valida el Mensaje-3, para lo cual Descifra la cadena especificada en el elemento RespuestaReto, utilizando la clave pública del Certificado Digital de la Instancia. Si hay coincidencia entre las cadenas descifradas de RespuestaReto del Mensaje-3 y la que la OPE generó e insertó en el elemento Reto del Mensaje-2, la OPE registra a la Instancia A en la Comunidad y genera el Mensaje-4 de tipo RespuestaSolicitudRegistro de registro satisfactorio en la Comunidad. Si no hay coincidencia entre las cadenas, la OPE rechaza a la Instancia A y genera el Mensaje-4 de registro erróneo en la Comunidad, cifrado con la clave privada de la OPE. OPE

56 1 Registro de Instancia en la Plataforma Flujo normal de eventos: La Instancia A obtiene y procesa el resultado de su registro en la Comunidad. La OPE responde al Mensaje-3 de la Instancia A, con el Mensaje-4. Envio del Mensaje-4 a Instancia A, en respuesta al Mensaje-3 Instancia A OPE Resultado: La Instancia A se encuentra registrada y puede enviar solicitudes de suscripción entre Instancias a otros miembros de la Comunidad, con el propósito de establecer una Relación de Interoperabilidad.

57 1 Que es la cadena Reto? La cadena aleatoria Reto generada por la Instancia u OPE, pudiera hacer uso de un UUID (Universally Unique Identifier). El UUID es un identificador único universal usado en el desarrollo de software, estandarizado por la Open Software Foundation (OSF), es creado para identificar objetos en un sistema. El UUID o GUID (Globally Unique Identifier para implementaciones Microsoft), es un número pseudoaleatorio, que en teoría es imposible que se repita. El UUID tiene un longitud de 16 bytes (128 bit) y aunque no garantiza la unicidad, la probabilidad de colisiones es reducida debido al número de bits y a la forma en que éstos son generados (16 32 ó ) posibilidades. Los algoritmos de creación del UUID están especificados en el RFC4122. En su forma canónica, un UUID consiste de una cadena compuesta por 32 dígitos hexadecimales (del 0 al 9 y las primeras 6 letras del alfabeto), mostrados en cinco grupos separados por guiones de la forma ( ) para un total de 36 caracteres (32 dígitos y 4 guiones. Algunos ejemplos de cadenas UUID serían los siguientes: 1bdee0fb a-9a80-db175934c4c2 560a8451-a29c-41d4-a f81d4fae-7dec-11d0-a765-00a0c91e6bf6

58 1 Flujo de Intercambio de Retos (Instancia OPE)

59 1 Estructuras XML del DTISACG -Anexo 2- Mensajes de Interoperabilidad Tipos de Mensajes: Oficio Electrónico Directorio de Usuarios de Instancia Directorio de Usuarios de Instancias de la Comunidad Actualización de Directorio de usuarios de Instancias Acuses de Recibo

60 1 Estructuras XML del DTISACG -Anexo 2- Encabezado

61 1 Estructuras XML del DTISACG -Anexo 2- Cuerpo del Mensaje

62 1 Estructuras XML del DTISACG -Anexo 2- Firma Electrónica del Mensaje Corresponde al mensaje completo de interoperabilidad y es emitida por la Instancia emisora con el propósito de mantener integro el contenido del mensaje así como asegurar el no repudio del mismo.

63 1 Estructuras XML del DTISACG -Anexo 2- Instancia A genera Mensaje-1 de tipo SolicitudRegistro

64 1 Estructuras XML del DTISACG -Anexo 2- Si ya existe un registro, la OPE genera el Mensaje-2 de tipo RespuestaSolicitudRegistro con el rechazo de la solicitud de registro por -Idduplicado en el Directorio Consolidado de Interoperabilidad.

65 1 Estructuras XML del DTISACG -Anexo 2- El Mensaje-2 de tipo RetoSolicitudRegistro con la cadena aleatoria de la OPE encriptada, el Certificado Digital de la OPE y la cadena aleatoria recibida en el Mensaje-1 Reto deberá estar cifrada con la Clave Privada de la OPE.

66 1 Estructuras XML del DTISACG -Anexo 2- Si el Mensaje-2 es de tipo RechazoSolicitudRegistro, la Instancia A registra el rechazo y se culmina la operación.

67 2 Solicitud de Suscripción entre Instancias Descripción: Establece la creación de una Relación de Interoperabilidad que permite a dos Instancias iniciar los escenarios de interoperabilidad de Envío de Solicitud y Envío de Respuesta. Precondiciones: La Instancia que envía la solicitud y la Instancia con la que se desea establecer la Relación de Interoperabilidad están registradas en la Comunidad. Protocolo de Comunicación: En el intercambio de Mensajes de este escenario se aplica el Protocolo Instancia-Instancia. Tipos de Datos: En este escenario, se envía un Mensaje con un elemento de tipo SolicitudSuscripcionInstancia que representa la solicitud de suscripción de una Instancia para efectuar operaciones de interoperabilidad.

68 2 Solicitud de Suscripción entre Instancias Flujo normal de eventos: La OPE retransmite el Acuse de recibo electrónico, según lo especificado en el Protocolo Instancia-Instancia. OPE La OPE transmite la solicitud, según lo especificado en el Protocolo Instancia-Instancia. La Instancia A envía una solicitud Genera un Mensaje, de tipo SolicitudSuscripcionInstancia, y Solicita la creación de la Relación de Interoperabilidad y envía dicha solicitud a la Instancia destino B a través de la OPE. Instancia A Instancia destino B registra la solicitud El SACG de la Instancia B validará que no se encuentre registrada previamente la Instancia A. Acepta la solicitud de suscripción y envía un Acuse de recibo electrónico. Instancia B

69 2 Solicitud de Suscripción entre Instancias Flujo normal de eventos: La OPE retransmite el Mensaje RespuestaSuscripcionInstancia hacia la Instancia A. OPE La OPE analiza la respuesta y de ser aprobatoria, registra la Relación de Interoperabilidad, esta relación permitirá que la OPE envié mensajes de una Instancia a otra. La Instancia A recibe y procesa el Mensaje de RespuestaSuscripcionInstancia Instancia A La Instancia B para dar respuesta a la solicitud Genera un Mensaje de tipo RespuestaSuscripcionInstancia, y Envía la respuesta a la Instancia A, a través de la OPE, según lo especificado en el Protocolo Instancia-Instancia. Instancia B

70 2 Solicitud de Suscripción entre Instancias Flujo Alterno: Este flujo de eventos ocurre cuando en el flujo normal de eventos se rechaza la Solicitud de Suscripción recibida. OPE La OPE analiza la respuesta, descarta la creación de la Relación de Interoperabilidad y retransmite el Mensaje RespuestaSuscripcionInstancia hacia la Instancia A. La Instancia A recibe y procesa el Mensaje de RespuestaSuscripcionInstancia Instancia A La Instancia destino B rechaza la Solicitud de Suscripción La Instancia B devuelve un Mensaje de tipo RespuestaSuscripcionInstancia, a la Instancia que solicitó la Relación de Interoperabilidad, especificando el rechazo de la solicitud. Instancia B

71 2 Solicitud de Suscripción entre Instancias Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. La Instancia A ya está registrada para interoperar con la Instancia B. Este flujo ocurre cuando la Instancia A, previamente se había suscrito para establecer una Relación de Interoperabilidad con la Instancia B. 2. La Instancia de recepción no está disponible. Este flujo de evento ocurre si al momento de enviar el Mensaje, la OPE no puede contactar a la Instancia destino del mensaje. La OPE intentará realizar la conexión no más de 6 veces en lapsos de 1 hora entre cada intento. Luego de cada solicitud fallida, la OPE genera un mensaje de error que envía al administrador del SACG de destino, vía correo electrónico. Resultado: Se ha creado una Relación de Interoperabilidad entre las Instancias, y éstas podrán iniciar el envío de Mensajes de solicitud y respuesta, en cuanto se efectúe la sincronización de sus directorios.

72 2 Estructura XML del DTISACG -Anexo 2- En este escenario, se envía un Mensaje con un elemento de tipo SolicitudSuscripcionInstancia que representa la solicitud de suscripción de una Instancia para efectuar operaciones de interoperabilidad. La respuesta es enviada mediante un elemento de tipo RespuestaSuscripcionInstancia

73 3 Sincronización Completa, Instancia a OPE Descripción: Permite la actualización completa del directorio de la OPE, mediante el envío completo de la última versión del directorio de una Instancia. Este escenario es iniciado cuando la Instancia A envía a la OPE su directorio completo y la OPE sincroniza el Directorio Consolidado de Interoperabilidad. Precondiciones: 1. La Instancia que envía la sincronización está registrada en la Comunidad. 2. La versión del directorio a publicar por parte de la Instancia en el Mensaje debe ser la primera o una superior a la versión registrada de esta Instancia en el Directorio Consolidado de Interoperabilidad. Protocolo de Comunicación: En el intercambio de Mensajes de este escenario se aplica el Protocolo Instancia-OPE. Tipos de Datos: En este escenario se envía un Mensaje de tipo DirectorioMiembroComunidad con un elemento tipo DirectorioMiembroComunidad. El elemento DirectorioMiembroComunidad contiene la Estructura de la Institución.

74 3 Sincronización Completa, Instancia a OPE Flujo normal de eventos: Instancia A prepara un Mensaje de sincronización de tipo DirectorioMiembroComunidad Identificador del mensaje Estructura de la Institución Fecha de envío Versión actual del directorio (este número de versión es particular de la Instancia) Envio de Mensaje de sincronización Instancia a OPE Instancia A OPE La OPE recibe el Mensaje y valida Que la versión del directorio de la Instancia de que se trata es superior a la última registrada. Efectuada dicha validación la OPE procesa el Mensaje y sustituye el directorio actual por el suministrado por la Instancia. Asimismo toma la versión del directorio como base para próximas sincronizaciones.

75 3 Sincronización Completa, Instancia a OPE Flujo de Excepción: Ocurre si durante la validación del Mensaje de sincronización DirectorioMiembroComunidad la versión del directorio de la Instancia que envía su mensaje NO es mayor que la registrada en la OPE, es decir, la OPE detecta una Secuencia de versión incorrecta. La OPE envía como respuesta al remitente un Mensaje de rechazo de tipo MensajeRechazado y el elemento CodigoError, el cual tendrá en su atributo SecuenciaDeVersiónIncorrecta. Instancia A OPE La Instancia recibe el Mensaje de rechazo, registra y procesa el error siguiendo las directrices para el manejo de errores de los escenarios de Interoperabilidad Resultado: El directorio de la Instancia A se encuentra sincronizado con el Directorio Consolidado de Interoperabilidad de la OPE.

76 3 Estructura XML del DTISACG -Anexo 2- En este escenario, la Instancia A prepara un Mensaje de sincronización de tipo DirectorioMiembroComunidad

77 3 Estructura XML del DTISACG -Anexo 2- La OPE envía como respuesta al remitente un Mensaje de rechazo de tipo Rechazo, el cual tendrá en su atributo SecuenciaDeVersionIncorrecta.

78 4 Sincronización Completa, OPE a Instancia Descripción: Permite la transmisión de un Mensaje de Sincronización Completa, OPE a Instancia. Inicia después de que una Instancia A envía a la OPE su directorio completo, o bien, cuando se encuentra algún error de sincronización de directorio. La OPE deberá enviar este Mensaje al resto de miembros con los que la Instancia A tiene Relación de Interoperabilidad. Precondiciones: Recibir una actualización completa de tipo Instancia a OPE. Protocolo de Comunicación: En el intercambio de los Mensajes de este escenario se aplica el Protocolo Instancia-OPE. Tipos de Datos: En este escenario, se envía un Mensaje de tipo DirectorioMiembroComunidad con un elemento de tipo DirectorioMiembroComunidad. El elemento DirectorioMiembroComunidad contiene la Estructura de la Institución.

79 4 Sincronización Completa, OPE a Instancia Flujo normal de eventos: La OPE prepara el Mensaje de sincronización de tipo DirectorioMiembroComunidad Estructura de la Institución Versión actual del directorio de la Instancia A Instancia C Instancia A Para cumplir este escenario, la precondición es que la Instancia haya efectuado previamente una actualización completa de su Directorio a la OPE OPE La OPE envía el mensaje a todas las Instancias con las que la Instancia A tiene Relación de Interoperabilidad. Cada una de las Instancias destino recibe el Mensaje y sustituye en su directorio local la Estructura de la Institución de la Instancia A suministrada por la OPE. Instancia B

80 4 Sincronización Completa, OPE a Instancia Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. La Instancia de Recepción no está disponible. Este flujo de evento ocurre si al momento de enviar el Mensaje la OPE no puede contactar a la Instancia destino del Mensaje. La OPE intentará realizar la conexión no más de 6 veces, en lapsos de 1 hora entre cada intento. Luego de cada intento de envío de actualización fallido, la OPE generará un mensaje de error que enviará al administrador del SACG destino, vía correo electrónico. Resultado: Las Instancias con las que la Instancia A tienen Relación de Interoperabilidad, cuentan con el directorio actualizado de la Instancia A.

81 4 Estructura XML del DTISACG -Anexo 2- En este escenario se utiliza la estructura del mensaje DirectorioMiembroComunidad

82 5 Sincronización Parcial de Directorios, Instancia a OPE Descripción: Permite la actualización parcial del Directorio Consolidado de Interoperabilidad y de los directorios de las Instancias, mediante la especificación de operaciones de altas, cambios y bajas en las Estructuras de las Instituciones de que se trate. Este escenario inicia cuando una Instancia envía a la OPE una actualización de su directorio. Precondiciones: 1. La Instancia que envía la solicitud es una Instancia ya registrada en la Comunidad. 2. Se debe contar con al menos una Sincronización Completa Instancia OPE efectuada previamente. Protocolo de Comunicación: En el intercambio de los Mensajes de este escenario se aplica el Protocolo Instancia-OPE. Tipos de Datos: En este escenario se envía un Mensaje de tipo ActualizacionDirectorioMiembroComunidad, con un elemento de tipo ActualizacionDirectorioMiembroComunidad. El Elemento ActualizacionDirectorioMiembroComunidad contiene las listas de altas, cambios y bajas de la Estructura de la Institución, ocurridas en la Instancia que emite el Mensaje.

83 5 Sincronización Parcial de Directorios, Instancia a OPE Flujo normal de eventos: Instancia A prepara un Mensaje de sincronización de tipo ActualizacionDirectorioMiembro Comunidad Altas, bajas y cambios realizados desde la última sincronización. Número correspondiente de la versión del directorio de la Instancia. Envío de Mensaje de Sincronización Instancia a OPE Sincronizado el DCI, la OPE envía el Mensaje de Sincronización a las Instancias con las que la Instancia A tiene Relación de interoperabilidad Instancia A OPE La OPE recibe el Mensaje y valida Que la versión del directorio de la Instancia en el Mensaje sea superior a la versión registrada por la misma en el directorio de Instancias de la OPE. Efectuada dicha validación, la OPE procesa el Mensaje y realiza las operaciones de altas, cambios y bajas en ese orden.

84 5 Sincronización Parcial de Directorios, Instancia a OPE Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. Secuencia de versión incorrecta. Este flujo ocurre si durante la validación del Mensaje del flujo normal de eventos, la versión del directorio no es mayor que la registrada en la OPE. Lo que supondría un error en algún intento de sincronización anterior. a. Al presentarse el error en la validación, la OPE envía como respuesta al remitente un Mensaje de rechazo de tipo MensajeRechazado, especificando en el atributo CodigoError el valor SecuenciaDeVersionIncorrecta. b. La Instancia recibe el Mensaje de rechazo, lo registra y procesa el error, siguiendo las reglas para el manejo de errores en Escenarios de Interoperabilidad. Resultado: El Directorio Consolidado de Interoperabilidad de la OPE se encuentra sincronizado con la Instancia A.

85 5 Estructura XML del DTISACG -Anexo 2- En este escenario se utiliza la estructura del mensaje ActualizacionDirectorioMiembroComunidad

86 6 Sincronización Parcial de Directorios, OPE a Instancia Descripción: Permite la actualización parcial de los directorios de las Instancias, mediante la especificación de operaciones de altas, cambios y bajas en las Estructuras de las Instituciones de que se trate. La OPE envía Mensajes de sincronización de actualizaciones de la Instancia A, hacia aquellas Instancias con las que la Instancia A tenga Relación de Interoperabilidad. Este escenario inicia después de que la OPE hace la sincronización parcial del directorio de la Instancia A en el Directorio Consolidado de Interoperabilidad de la OPE. Precondiciones: Recibir una Sincronización Parcial, Instancia a OPE. Protocolo de Comunicación: En el intercambio de los Mensajes de este escenario se aplica el Protocolo Instancia-OPE. Tipos de Datos: En este escenario se envía en un Mensaje de tipo ActualizacionDirectorioMiembroComunidad, con un elemento de tipo ActualizacionDirectorioMiembroComunidad. El elemento ActualizacionDirectorioMiembroComunidad contiene la Estructura de la Institución A.

87 6 Sincronización Parcial de Directorios, OPE a Instancia Flujo normal de eventos: Instancia A La OPE prepara el Mensaje de sincronización de tipo ActualizaciónDirectorioMiembro Comunidad Para cumplir este escenario, la precondición es que la OPE haya recibido previamente una Sincronización parcial del directorio de la Instancia A, a fin de sincronizarlo en el DCI OPE Altas, Bajas y Cambios realizados desde la ultima sincronización Número correspondiente de la versión del directorio de la Instancia A La OPE envía el mensaje de sincronización a todas las Instancias con las que la Instancia A tiene Relación de Interoperabilidad. Instancia C Cada una de las Instancias destino recibe el Mensaje y valida que la versión del directorio sea la correcta y aplica en su directorio local las actualizaciones de la Estructura de la Institución de la Instancia A suministrada por la OPE. Instancia B

88 6 Sincronización Parcial de Directorios, OPE a Instancia Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. La Instancia de recepción no está disponible. Este flujo ocurre si al momento de enviar el Mensaje, la OPE no puede contactar a la Instancia destino (aplica para cada Instancia con la que la Instancia A tenga una Relación de Interoperabilidad). La OPE intentará realizar la conexión no más de 6 veces, en lapsos de 1 hora entre cada intento. Luego de cada intento de envío de actualización fallido, la OPE generará un mensaje de error que enviará al administrador del SACG destino, vía correo electrónico. Resultado: Las Instancias con las que la Instancia A tiene Relación de Interoperabilidad, cuentan con el directorio actualizado de la Instancia A.

89 6 Estructura XML del DTISACG -Anexo 2- En este escenario se utiliza la estructura del mensaje ActualizacionDirectorioMiembroComunidad

90 7 Envió de Solicitud Descripción: Escenario de Interoperabilidad que habilita el envío de un Mensaje de tipo RegistroOficioElectronico de un SACG a otro. Precondiciones: Existe Relación de Interoperabilidad entre la Instancia que remite la solicitud y la Instancia destino. Protocolo de Comunicación: En el intercambio de los Mensajes de este escenario se aplica el Protocolo Instancia-Instancia. Tipos de Datos: En este escenario se envía un Mensaje de tipo RegistroOficioElectronico con un elemento de tipo OficioElectronico, el cual tendrá el valor Solicitud en el atributo TipoOficio.

91 7 Envió de Solicitud Flujo normal de eventos: La Instancia A genera mensaje de tipo RegistroOficio Electronico que contiene La OPE recibe el Mensaje y realiza las siguientes validaciones Un elemento de tipo OficioElectronico, el cual tendrá el valor Solicitud en para la Instancia B y lo envía a la OPE. OPE Que el área o UA de la Instancia A que envía la solicitud, así como el usuario firmante Remitente del oficio, se encuentran en el DCI. Que el área o UA de la Instancia B a quien se dirige la solicitud, así como el usuario(s) Destinatario(s) (originales o en copia) del oficio, se encuentran en el DCI. Efectuadas las validaciones, la OPE reenvía el Mensaje a la Instancia B, según lo estipulado en el Protocolo Instancia-Instancia. Instancia A La Instancia B recibe el Mensaje y realiza las siguientes validaciones Que el área o UA de la Instancia A que envía la Solicitud, así como el usuario firmante Remitente del oficio, se encuentran en el DCI. Que el área o UA de la Instancia B a quien se dirige la Solicitud, así como el usuario(s) Destinatario(s) (originales o en copia) del oficio, se encuentran en el DCI. Instancia B *UA = Unidad Admistrativa

92 7 Envió de Solicitud Flujo normal de eventos: OPE El registro de la Solicitud deberá incluir todos los elementos de la misma. Si en el Mensaje de tipo RegistroOficioElectronico se incluyen archivos anexos, éstos deberán ser validados con respecto a sus respectivos atributos HashArchivo, y registrados en la Instancia destino al momento de la recepción de cada Solicitud. En los casos en que estos archivos se transmitan como referencias (elementos ReferenciaWeb), deberán ser descargados para su validación y registro. Instancia A Efectuadas las validaciones mencionadas el destinatario registra y procesa la Solicitud recibida, conforme al SACG. Instancia B

93 7 Envió de Solicitud Flujos Alternos: En los flujos alternos se consideran los siguientes casos: 1. Envío de copias de solicitud. En el flujo normal de eventos, el área o UA de la Instancia A, envía un Mensaje de tipo RegistroOficioElectronico al área o UA de la Instancia B, con copia a una o más áreas o UA de una o más Instancias. a) La OPE realiza las validaciones especificadas, por cada uno de los destinatarios de la solicitud. b) Después de efectuadas las validaciones mencionadas, la OPE reenvía el Mensaje de tipo RegistroOficioElectronico a todas las Instancias destino, según lo estipulado en el Protocolo Instancia-Instancia. 2. Cada Instancia que recibe copia del Mensaje, realiza las siguientes validaciones: a) Que el área o UA de la Instancia A que envía la solicitud, así como el usuario o firmante Remitente del oficio, se encuentran en el DCI. b) Que el área o UA de la Instancia B a quien se dirige la solicitud, así como el usuario(s) Destinatario(s) originales o en copia del oficio, se encuentran en el DCI. Después de efectuadas las validaciones mencionadas, los destinatarios de las copias las reciben y les dan el trámite que corresponda.

94 7 Envió de Solicitud Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. El área o unidad administrativa, o el usuario o firmante Remitente del oficio, son desconocidos por la Instancia destino. Este flujo ocurre si durante el flujo normal de eventos (validaciones Instancia B) o en el flujo alterno (cada Instancia que recibe copia), la Instancia B no encuentra el área o UA, o el usuario o firmante Remitente del oficio de la Instancia A en el DCI. a) La Instancia B solicita a la OPE, el DCI completo para actualizar su directorio. Esto lo realiza conforme al Escenario: Sincronización Completa OPE a Instancia. b) Una vez recibido el DCI, la Instancia B valida si la Instancia A y el área o unidad administrativa, y el usuario o firmante Remitente del oficio están registrados: i. Si la Instancia A sí está registrada, la Instancia B registra y procesa la solicitud recibida, conforme al SACG. ii. Si la Instancia A no está registrada, la Instancia B elimina la solicitud recibida y envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor MiembroDesconocido.

95 7 Envió de Solicitud Flujo de Excepción: 2. La Instancia de recepción no está disponible. Este flujo de evento ocurre si al momento de enviar el Mensaje, la OPE no puede contactar a la Instancia destino del Mensaje. La OPE intentará realizar la conexión no más de 6 veces en lapsos de 1 hora entre cada intento. Después de cada intento de envío de actualización fallido, la OPE generará un mensaje de error que enviará al administrador del SACG destino, vía correo electrónico. 3. El Oficio Electrónico contiene archivos anexos por ReferenciaWeb y la Instancia destino no puede descargar alguno de estos archivos. Este flujo ocurre si durante el flujo normal de eventos (validaciones Instancia B) o en el flujo alterno (cada Instancia que recibe copia), la Instancia B no puede descargar algún archivo de los anexos incluidos en el Oficio Electrónico como ReferenciaWeb (URL de descarga). a) La Instancia B envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor DatosInvalidos.

96 7 Envió de Solicitud Flujo de Excepción: 4. El Oficio Electrónico contiene archivos anexos y falla la validación de HashArchivo de alguno de ellos. Este flujo ocurre si durante el flujo normal de eventos (validaciones Instancia B) o en el flujo alterno (cada Instancia que recibe copia), la Instancia B encuentra discrepancia entre alguno de los HashArchivo declarado en el Oficio Electrónico y su correspondiente HashArchivo calculado. a) La Instancia B envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor DatosInvalidos. Resultado: La Instancia B ha registrado la Solicitud recibida.

97 7 Estructura XML del DTISACG -Anexo 2- En este escenario se utiliza la estructura del mensaje OficioElectronico

98 7 Estructura XML del DTISACG -Anexo 2- Los datos del remitente incluyen los datos del autor del oficio electrónico, la Unidad Organizacional (Área o Unidad Administrativa) y la Institución a la que pertenece. Estos mismos datos son los que se tienen también para los destinatarios del oficio electrónico.

99 7 Estructura XML del DTISACG -Anexo 2- Los datos del oficio dependen de si el oficio se trata de una Solicitud o una Respuesta.

100 7 Estructura XML del DTISACG -Anexo 2- El Documento Electrónico es un elemento opcional del oficio electrónico, en un formato estandarizado por ejemplo un documento de Word en los casos cuando dicha representación del oficio electrónico sea requerida y no baste con el XML del propio oficio. Los anexos son documentos adicionales que acompañan al oficio y que pueden tener diversos formatos binarios, por ejemplo una imagen digitalizada de un documento en papel.

101 7 Estructura XML del DTISACG -Anexo 2- La firma del oficio electrónico esta basada en el estándar XML Digital Signature. La firma es del autor del oficio electrónico.

102 7 Estructura XML del DTISACG -Anexo 2- En el caso de los archivos Anexo al oficio electrónico estos son firmados basados en el estándar PKCS#7, verificar el elemento FirmaElectronicaArchivo de la estructura XSD del DTISACG para mayor referencia.

103 8 Envió de Respuesta Descripción: Escenario de Interoperabilidad que habilita el envío de una respuesta a una solicitud de una Instancia a otra. Precondiciones: 1. La Instancia que envía la respuesta es una Instancia registrada en la Comunidad. 2. Existe Relación de Interoperabilidad entre la Instancia que remite la solicitud y la Instancia destino. 3. Existe una solicitud a la cual se está respondiendo. Protocolo de Comunicación: En el intercambio de los Mensajes de este escenario se aplica el Protocolo Instancia-Instancia. Tipos de Datos: En este escenario, se envía un Mensaje de tipo RegistroOficioElectronico con un elemento de tipo OficioElectronico, el cual tendrá el valor Respuesta en el atributo TipoOficio. El elemento OficioElectronico contiene la respuesta a la solicitud, e incluye el atributo EnRespuestaDe con el folio de la solicitud a la que se responde.

104 8 Envió de Respuesta Flujo normal de eventos: La OPE recibe el Mensaje y realiza las siguientes validaciones Después de efectuadas las validaciones, la OPE reenvía el Mensaje a la Instancia A, según lo estipulado en el Protocolo Instancia-Instancia. OPE Que el área o UA de la Instancia B que envía la respuesta, así como el usuario firmante Remitente del oficio, se encuentran en el DCI. Que el área o UA de la Instancia A a la que se dirige la respuesta, así como el usuario(s) Destinatario(s) (originales o en copia) del oficio, se encuentran en el DCI. Instancia A La Instancia B genera Mensaje de tipo RegistroOficio Electronico para la Instancia A que contiene El elemento de tipo OficioElectronico, tiene valor Respuesta en La Respuesta a la solicitud incluye (folio de la solicitud a la que se responde) y lo envía a la OPE. Instancia B

105 8 Envió de Respuesta Flujo normal de eventos: OPE La Instancia A recibe el Mensaje y realiza las siguientes validaciones Que el área o UA de la Instancia B que envía la respuesta, así como el usuario firmante Remitente del oficio, se encuentran en el DCI. Que el área o UA de la Instancia A a quien se dirige la respuesta, así como el usuario(s) Destinatario(s) (originales o en copia) del oficio, se encuentran en el DCI. Que existe una solicitud emitida por el destinatario de la respuesta, con el folio de dicha solicitud, en Si se incluyen archivos anexos, deberán ser validados con sus Si los archivos se transmiten como ReferenciaWeb, deberán ser descargados para su validación y registro. Instancia A Después de efectuadas las validaciones, el destinatario registra y procesa la respuesta recibida en la Instancia A, conforme al SACG. Instancia B

106 8 Envió de Respuesta Flujos Alternos: En los flujos alternos se consideran los siguientes casos: 1. Envío de copias de Respuesta. En el flujo normal de eventos, el área o UA de la Instancia B, envía un Mensaje de tipo RegistroOficioElectronico al área o UA de la Instancia A, con copia a una o más áreas o UA de una o más Instancias. a) La OPE realiza las validaciones especificadas, por cada uno de los destinatarios a quienes se marca copia de la respuesta. b) Después de efectuadas las validaciones mencionadas, la OPE reenvía el Mensaje de tipo RegistroOficioElectronico a todas las Instancias destino, según lo estipulado en el Protocolo Instancia-Instancia. 2. Cada Instancia que recibe los Mensajes de copia, realiza las siguientes validaciones: a) Que el área o UA de la Instancia B, así como el usuario o firmante Remitente del oficio, se encuentran en el DCI. b) Que el área o unidad administrativa de la Instancia A, así como el usuario firmante Destinatario del oficio, se encuentran en el DCI. Efectuadas las validaciones mencionadas, los destinatarios a quienes se marca copia de la Respuesta, la reciben y le dan el trámite que corresponda.

107 8 Envió de Respuesta Flujo de Excepción: En este flujo se consideran los supuestos de excepción siguientes: 1. El área o unidad administrativa o el usuario o firmante Remitente del oficio es desconocida por el destinatario. Este flujo ocurre si durante el flujo normal de eventos (validaciones de OPE), o en el flujo alterno (envió de copias de Respuesta) la Instancia B, no encuentra el área o UA de la Instancia A o de alguna Instancia a la que se dirige copia, en su DCI. a) La Instancia B solicita a la OPE, el DCI completo para actualizar su directorio. Esto lo realiza conforme al Escenario: Sincronización Completa OPE a Instancia. b) Una vez recibido el DCI, la Instancia B valida si la Instancia A y el área o UA de ésta, o de la Instancia a la que se dirige copia, están registradas: i. Si la Instancia A o la Instancia a la que se dirige copia sí está registrada, la Instancia B procede al envío del Mensaje de tipo RegistroOficioElectronico o de su copia. ii. Si la Instancia A o la Instancia a la que se dirige copia no está registrada, la Instancia B envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor MiembroDesconocido.

108 8 Envió de Respuesta Flujo de Excepción: 2. La Instancia de recepción no está disponible. Este flujo de evento ocurre si al momento de enviar el Mensaje, la OPE no puede contactar a la Instancia destino del Mensaje. La OPE intentará realizar la conexión no más de 6 veces en lapsos de 1 hora entre cada intento. Después de cada intento de envío de actualización fallido, la OPE generará un mensaje de error que enviará al administrador del SACG destino, vía correo electrónico. 3. El Oficio Electrónico contiene archivos anexos por ReferenciaWeb y la Instancia destino no puede descargar alguno de estos archivos. Este flujo ocurre si durante el flujo normal de eventos (validaciones Instancia A) o en el flujo alterno (envió de copias de Respuesta), la Instancia A no puede descargar algún archivo de los anexos incluidos en el Oficio Electrónico como ReferenciaWeb (URL de descarga). a) La Instancia B envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor DatosInvalidos.

109 8 Envió de Respuesta Flujo de Excepción: 4. El Oficio Electrónico contiene archivos anexos y falla la validación de HashArchivo de alguno de ellos. Este flujo ocurre durante el flujo normal de eventos (validaciones Instancia A) o durante las validaciones de los elementos (Anexos incluidos al oficio electrónico), la Instancia A encuentra discrepancia entre alguno de los HashArchivo declarado en el Oficio Electrónico y su correspondiente HashArchivo calculado. a) La Instancia A envía un Mensaje de rechazo, especificando en el atributo CodigoError el valor DatosInvalidos. Resultado: La Instancia A ha registrado la Respuesta recibida.

110 8 Estructura XML del DTISACG -Anexo 2- En este escenario se utiliza la estructura del mensaje OficioElectronico. En el atributo EnRespuestaDe se incluye el folio de la solicitud a la que responde.

111 8 Estructura XML del DTISACG -Anexo 2- Confirmaciones y Acuses de Recibo La confirmación de recibo y el acuse de recibo son tipos especiales de mensajes de interoperabilidad que no incluyen cuerpo del mensaje, pues todos los datos de la confirmación o del acuse se encuentran en el encabezado y en la firma. Confirmación de recibo: Contestación síncrona provocada por la recepción de un mensaje y que indica que un miembro de la comunidad (o la OPE) confirma que recibió el mensaje después de aplicar las validaciones al encabezado del mensaje pertinentes. La confirmación de recibo incluye información que determina la fecha y hora exactas de recepción del mensaje. Acuse de recibo: Tipo especial de confirmación de recibo que aplica cuando el receptor del mensaje corresponde con el destinatario final del mismo (o cuando es uno de los destinatarios finales de un mensaje a múltiples destinatarios). La fecha y hora del acuse de recibo se considera como la fecha y hora de recepción del mensaje y de su contenido.

112 VII. Convenciones de Comunicación Protocolo Instancia OPE Protocolo Instancia Instancia

113 En el Documento Técnico de Interoperabilidad de los Sistemas Automatizados de Control de Gestión, se definen dos protocolos de comunicación para la interoperabilidad de una Comunidad. A Protocolo Instancia OPE Protocolo utilizado cuando una Instancia solicita o proporciona información a la OPE o cuando la OPE solicita o proporciona información a una Instancia. B Protocolo Instancia Instancia Protocolo utilizado cuando una Instancia envía información a través de la OPE a una o más Instancias.

114 A Protocolo Instancia OPE Generación de Mensaje Identificador del mensaje Acción Información de Remitente Fecha de envío Envío de Mensaje a OPE La OPE valida el Mensaje XSD Certificado Firma Instancia Envío de Mensaje a Instancia OPE Generación de Respuesta Identificador del mensaje En referencia Fecha de envío Cuerpo de mensaje

115 GRACIAS! SECRETARIA DE LA FUNCIÓN PÚBLICA SUBSECRETARÍA DE LA FUNCIÓN PÚBLICA UNIDAD DE GOBIERNO DIGITAL Julio 2012