EDItran/FF-EDItran/CD 5.1

Transcripción

1 EDItran/FF-EDItran/CD 5.1 Firma Electrónica de Ficheros MVS z/os (enlace con máquinas externas) Firma electróncia por NFS Indra. Septiembre de 2011 EF51USUA.doc.

2 Indra. La información aquí contenida puede ser objeto de cambios sin previo aviso. Las distintas versiones del producto pueden dar lugar a cambios, adiciones o supresiones de información en este manual. La correspondencia acerca de este manual debe realizarse en la hoja de comentarios aquí incluida y debe ser dirigida a Indra, Producto EDItran, Avda. de Bruselas 35 (Edificio VIO-1), Arroyo de la Vega - Alcobendas, Madrid. Comentarios de usuario sobre esta documentación. Exprese, y háganos llegar, su opinión y comentarios acerca de la documentación entregada y así podremos corregirla en las posteriores versiones de este documento. Indra. Producto : EDItran/FF-EDItran/CD 5.1 z/os (enlace con máquinas externas) Firma electróncia por NFS Referencia: EF51USUA.doc Avda. de Bruselas 35 - Arroyo de la Vega - Alcobendas MADRID. Empresa : Departamento: Contacto : Dirección :

3 . Indice 1. INTRODUCCION FUNCIONALIDAD DE EDITRAN/FF-CD REQUISITOS PARA LA UTILIZACION DE EDITRAN/FF-CD NFS SERVER (HOST) NFS CLIENTE MODO DE FUNCIONAMIENTO Cambios dependiendo de la versión EDItran FUNCIONES INVOCADAS DESDE JCL DE APLICACIÓN Definición del tipo de funcionamiento Verificación de habilitaciones y carga de emisión (Modo automático) Firma manual de la sesión de presentación Firma automática de la sesión de presentación Firma automática de n ficheros de una presentación Verificación de habilitaciones y carga de emisión (Modo no automático) Proceso de adaptación del fichero de aplicación de recepción EJEMPLO DE PROCEDIMIENTO DE FIRMA Emisión (modo automático utilizando ZTBGFITS) Emisión (modo no automático utilizando ENTRADA) Recepción PARAMETRIZACIONES EDITRAN/G ZOS como emisor y receptor ZOS como emisor y otro entorno como receptor ZOS como receptor y otro entorno como emisor Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. i.1

4 . 1. INTRODUCCION. Existen varias formas de funcionamiento en EDItran/FF y EDItran/CD. EDItran/FF es una aplicación integramente z/os. EDItran/CD se realiza en z/os, parte USS (UNIX SYSTEM SERVICES). Para ver esta opción, vea manuales ECD51USUA Y ED51USUC. Los certificados y la interfaz gráfica residen en máquinas WINDOWS-UNIX. Es necesario NFS (network file system). EDItran/CD y la interfaz gráfica EDItran/FF residen en dichas máquinas. Dentro de esta opción, podemos encontrar 2 subopciones de funcionamiento. o Modo automático. Desde cualquier procedimiento MVS, se enlaza vía IP con EDItran/CD de la máquina correspondiente, el cual certifica en ese momento, on-line lo que hay que enviar. Llamaremos a este modo Certificados externos en modo automático. o Modo no automático. Es el propio EDItran/CD el que ya colocado los ficheros necesarios por NFS, no se establece una conexión ip en cargas-descargas. Llamaremos a este modo Certificados externos en modo no automático. En este documento se describen los distintos modos de operación y requisitos para la firma de ficheros MVS mediante certificados digitales EXTERNOS (EDItran/CD + EDItran/FF en entornos WINDOWS-UNIX). En este manual se han tratado los siguientes aspectos: Breve descripción de la funcionalidad de EDItran/FF - CD Requisitos para la utilización de EDItran/FF - CD Modo de funcionamiento Descripción de jcl de adaptación de ficheros de aplicación emitidos o recibidos Evolución del procedimiento completo de firma, transmisión y verificación de firma de un fichero del MVS. Parametrización en EDItran/G del MVS. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 1-1

5 2. FUNCIONALIDAD DE EDItran/FF-CD. EDItran/FF EDItran/CD son componentes de la plataforma EDItran que permite la firma de ficheros mediante certificados digitales (personales o de servidor) emitidos por autoridades de certificación (CA). Cada uno de los ficheros de datos (de aplicación). puede firmarse por uno o más firmantes (cada uno con su certificado) generándose un fichero de firma (PKCS#7) por cada uno de ellos (en modo attach, se genera un único fichero que contiene aplic+firmas) Una vez generadas las firmas, EDItran/FF da la posibilidad al responsable de la aplicación, de habilitar el envío del fichero y sus firmas asociadas. EDItran/G, puede verificar que se ha concedido el permiso para enviar dicha presentación antes de realizar la carga. Una vez recibido/s el/los fichero/s de aplicación, con sus respectivos ficheros de firma asociados, el EDItran/FF del extremo receptor permite verificar cada una de las firmas asociadas al/los fichero/s. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 2-1

6 3. REQUISITOS PARA LA UTILIZACION DE EDItran/FF-CD. En caso de Certificados externos, EDItran/FF-CD es un software disponible en entornos UNIX y WINDOWS. Para que el entorno MVS pueda acceder a dichos servicios es necesario: o Disponer del propio EDItran/FF-CD en entorno WINDOWS (o UNIX) o Adecuar el servidor NFS de ficheros MVS de los servicios UNIX del ZOS para que den servicio a un cliente NFS o Disponer de un cliente NFS en la plataforma Windows (o UNIX). o Los ficheros no deben sufrir transformaciones de formato, alfabeto, etc, en el proceso de carga, transmisión y descarga. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 3-1

7 WINDOWS MVS EDItran/FF CLIENTE NFS Servidor NFS EDItran/G EDItran/P F. Datos F. Firma Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 3-2

8 3.1. NFS SERVER (HOST). Es necesario configurar el host como NFS server en el ZOS (soporte NFS para ficheros MVS) para poder funcionar con EDItran/FF. Se definirá por razones de seguridad, un puntero,(por ejemplo, PUNTERO.LOCAL.NFS) desde el cual se habilitará el acceso a NFS cliente. Se debe autorizar a usuarios, a través de RACF a la utilización de dicho servicio. La transferencia de datos se realizará en formato binario NFS CLIENTE. Debe instalarse una herramienta NFS cliente (las definiciones que siguen corresponden al Camaleón). Se recomienda no codificar en la misma el usuario RACF, puesto que si se hace doble clic en la conexión, se reenvía N veces el usuario codificado con pasword a blancos de forma que el RACF acaba denegando el acceso a dicho usuario e inhabilitándolo para futuras entradas. En el momento de conectarse con dicha herramienta se recomienda máxima atención con la pasword por los intentos incontrolados de conexión que hace el NFS cliente. Los parámetros NFS cliente con los que se han realizado las pruebas han sido: Username: <System logon name> (ninguno) Authenticator: (ninguno) Read size (8192, 512, etc). Write size (8192, 512, etc). Se observa que los ficheros creados en el host, son de record format VB, organization PS, con una longitud de registro de 8196 y un block size de Según lo que se indique en write size, así creará el NFS los registros del fichero variable (de firma), de forma que se recomienda codificar 8192, para mejor aprovechamiento del espacio. Opción CD Jukebox / WAN Server: ACTIVA. Permisos de creación de directorios: Todos los permisos (lectura, escritura y ejecución) para el usuario, para el grupo y para el resto (todos los permisos a 777). Permisos de creación de ficheros: Todos los permisos (lectura, escritura y ejecución) para el usuario, para el grupo y para el resto (todos los permisos a 777). Ficheros y pathnames con Character Set: Default. Ficheros y pathnames con Case on Create: Uppercase (Mayúsculas). Opción Enable Symlinks: ACTIVA. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 3-3

9 4. MODO DE FUNCIONAMIENTO. Utilizando el NFS, EDItran/FF genera el fichero de firma en un fichero MVS a partir del fichero de datos firmados que también reside en MVS. Al mismo tiempo genera un fichero de habilitación de la aplicación. El EDItran CICS/IMS podrá transmitir tanto el fichero de datos, el de habilitación, el de firma o todos ellos, al extremo remoto que podrá ser otro entorno MVS o una plataforma UNIX o Windows. De igual forma, El EDItran/FF de un extremo receptor puede comprobar las firmas recibidas en el sistema de ficheros del MVS. Para poder validar la firma de los ficheros, éstos no pueden ser transformados (por EDItran) en el transcurso de la transmisión, y por tanto las transformaciones de alfabeto y formato, si son necesarias, han de realizarse en un proceso posterior a la verificación de la firma. Las particularidades de su funcionamiento con EDItran/G son las siguientes: Los ficheros de firma tendrán el puntero *.P7B EDItran/G puede validar si desde EDItran/FF se ha habilitado el envío de ficheros y firmas asociadas, pudiendo interrumpir el proceso en caso de no existir dicho permiso. La transmisión de ficheros firmados electrónicamente, hace que sea conveniente que no se modifiquen las características del fichero origen (formato de fichero, traducción, conversión, etc), puesto que de otra forma el extremo receptor tendría errores de firma (en su EDItran/FF), al verificar la firma comparando cada fichero de aplicación recibido con cada fichero PKCS#7. Además, los entornos UNIX y WINDOWS, que generan saltos de carro en el fichero que les llega, no lo podrían hacer por la misma razón. La solución a éste proceso pasa por emitir ficheros binarios, siempre que el entorno sea no homogéneo (formato de fichero M (Modificado)), y en recepción, una vez pasado el proceso de verificación de EDItran/FF, se adaptará el fichero de aplicación al lenguaje y formatos conocidos, incluso eliminando posibles saltos de carro (todo ello asincronamente). La descarga debe hacerse indicando que los ficheros binarios recibidos se descarguen como fichero variable y no especificando un fichero único para la descarga (al menos, van a llegar dos ficheros). Es posible que en el remoto dichos datos estén en ASCII (a pesar de que el mismo, haya indicado formato binario) y además es posible que dichos datos pertenezcan a un fichero de texto de tipo fijo (los entornos UNIX-WINDOWS incluyen saltos de carro al final de cada línea). Cuando un fichero no se transmite como binario, dicho entorno, adapta el formato a fijo y hace traducción. Al no poder tocar los datos ni en emisión, ni en recepción, puesto que de otra forma la firma quedaría invalidada, se ha optado por la solución de que se adapte, una vez validadas las firmas, el fichero recibido a la situación en la que se recibía normalmente. Posteriormente a la descarga y a la verificación de la firma, si fuese necesario, se lanzará un jcl, al que se le pasan una serie de parámetros, para adaptar lenguaje, tablas de conversión, formato de fichero y saltos de carro. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 4-1

10 4.1. Cambios dependiendo de la versión EDItran. Los cambios más significativos son: 1. Hasta la versión 4.1 fase 0, los ficheros de firmas se llamaban P7. A partir de esta versión se llaman P7B. Para cambiar busque en los distintos ficheros ENTRADA el string.p7 y sustituya por.p7b. 2. Hasta la versión 4.1 fase 0, el modo de funcionamiento era NO AUTOMATICO. Se utilizaba el fichero ENTRADA (procedimiento ZTBGP1CF, que contiene un paso previo y el paso de A1P). A partir de esta versión, se puede utilizar el modo AUTOMATICO, que utiliza el procedimiento normal de EDItran (ZTBGP1C, el paso A1P), añadiendo el fichero ZTBGFITS (contiene datos de la conexión al servidor CD). En el caso de funcionar con ZTBGFITS (MODO AUTOMATICO), el programa establece una conexión con un programa servidor, el cual indica si la sesión está habilitada y tiene el número de firmas suficiente. En el caso de ENTRADA (MODO NO AUTOMATICO), es EDItran el que hace dicha validación alocando los ficheros correspondientes. Deberá cambiar el procedimiento previo a emisión, poniendo el adecuado. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 4-2

11 5. FUNCIONES INVOCADAS DESDE JCL DE APLICACIÓN Definición del tipo de funcionamiento. En EDItran/G, sesión de presentación aparecen los siguientes parámetros: CARGA EDItran/FF (N,A,T)...: X VERIF.EDItran/FF (N,H,F)...: X Su significado es el siguiente: 1. Carga EDItran/FF es la forma de funcionamiento de EDItran/FF. Sus valores posibles son: 1.1. N - Indica que se actúa en modo no automático ó sin EDItran/FF 1.2. A - Indica que se actúa con EDItran/FF en modo automático y que se cargarán en el fichero tampón sólo los ficheros de aplicación (no se cargarán los de firmas ni habilitación) T - Indica que se actúa con EDItran/FF en modo automático y que se cargarán en el fichero tampón todos los ficheros (aplicación, habilitación y firmas). 2. Verificación EDItran/FF es la forma de verificar que se puede proceder a cargar en EDItran/FF. Sus valores posibles son: 2.1. N - Indica que se actúa en modo no automático ó sin EDItran/FF 2.2. H - Indica que se actúa con EDItran/FF en modo automático y que para poder cargar, el servidor EDItran/FF windows nos debe comunicar que la sesión ha sido habilitada, ya sea normalmente o en modo forzado F - Indica que se actúa con EDItran/FF en modo automático y que para poder cargar, el servidor EDItran/FF windows nos debe indicar que esté ó no habilitada la sesión, se cumplen los requisitos de disponer de las firmas necesarias para la carga. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-1

12 5.2. Verificación de habilitaciones y carga de emisión (Modo automático). Utilizar el procedimiento ZTBGP1C. Este modo de funcionamiento automático es el más recomendado. Si se opta por esta opción, se realiza una conexión ip contra un programa que atiende sobre puerto server y que nos confirmará si para la aplicación EDItran/FF descrita, tenemos habilitado el envío y en su caso que ficheros hay que cargar. ZTBGFITS es un fichero creado por el usuario cuyo formato es fijo, de longitud 80 y con los siguientes registros: Nivel Nombre Long. Tipo Descripción 1 Registro-fich- 80 ZTBGFITS 2 Identificador de 2 Alfn. C1 registro de control 2 Guión 1 Alfn. Guión de separación 2 Dirección-ip donde 56 Alfn. Dirección ip del server donde está el prog. está el prog. EDI/FF 2 Guión 1 Alfn. Guión de separación 2 Puerto donde está el 5 Num programa EDItran/FF 2 Guión 1 Alfn. Guión de separación 2 Segundos activ server 3 Num Segundos de activación máxima 2 Guión 1 Alfn. Guión de separación 2 TCPNAME 8 Alfn. TCPIPJOBNAME 2 Filler 3 Alfn. SPACES Nivel Nombre Long. Tipo Descripción 1 Registro-fich- 80 ZTBGFITS 2 Identificador de 2 Alfn. C2 registro de control 2 Guión 1 Alfn. Guión de separación 2 Puntero NFS 44 Alfn. Puntero NFS 2 Filler 33 Alfn. RESERVA El siguiente / siguientes tipos de registro solo es válido para firma automática. Nivel Nombre Long. Tipo Descripción 1 Registro-fich n registros ZTBGFITS 2 Identificador de Firma 2 Alfn. C3 Automática 2 Guión 1 Alfn. Guión de separación 2 Origen Presentacion 9 Alfn. Origen de la presentación. Si su valor es zeros, indica que es válido para todos los origenes. 2 Guión 1 Alfn. Guión de separación 2 Remoto Presentacion 9 Alfn. Remoto de la presentación. Si su valor es zeros, indica que es válido para todos los remotos. 2 Guión 1 Alfn. Guión de separación 2 Aplicación Presentacion 6 Alfn. Aplicación de la presentación. Si su valor es zeros, indica que es válido para todos las aplicaciones. 2 Guión 1 Alfn. Guión de separación Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-2

13 2 Nombre de usuario. 25 Alfn. Nombre de usuario permitido para firma automática. Su DN debe estar en el servidor para firma automática. 2 Guión 1 Alfn. Guión de separación 2 Habilitación en la firma automática 2 Guión 1 Alfn. Guión de separación 2 Filler 9 Alfn. Area de reserva Ejemplo: C C2-KI.EITC.NFS 1 Alfn. S/N, indica si además de firmar automáticamente se quiere permitir el habilitar o no TCPIPB En el caso anterior, si queremos cargar para la sesión de presentación PRUEBA, se hace un connect contra la dirección puerto 8300, con un máximo de 30 segundos, siendo el puntero nfs el KI.EITC.NFS. El programa server verifica si la sesión está habilitada y devuelve los ficheros a cargar (en este caso todos: habilitación, aplicación y firmas), en el tampón. Se ha validado que exista fisicamente que exista el de habilitación y los de firmas correspondientes. Existen 3 formas de firmar los ficheros: Firma manual de la sesión de presentación. Con esta opción, cada vez que se genera un fichero de aplicación, los usuarios firmantes, lo ven y firman su fichero. Este proceso, está plenamente integrado con lo anteriormente expuesto. En el previo a emisión, se llama al servidor FF, el cual es consciente de los ficheros firmados, habilitación, etc Firma automática de la sesión de presentación. Con esta opción, los usuarios no firman manualmente los ficheros de la presentación. En un paso previo a la carga, se llama al servidor FF, y se le proporciona el usuario firmante (cuyo certificado reside en el servidor). El servidor EDItran/FF, conoce los ficheros de la aplicación para la que se le llama, de forma que firma todos los ficheros de la misma (incluso puede habilitar la presentación). Al utilizar esta opción, se incluye un paso previo a la carga (ya sea un paso previo en el procedimiento ó un jcl por fuera). Se utiliza el jcl ZTBGJFF0 (funcion 01), que tira del programa ZTBGBFF0, pasando vía parm la sesión de presentación para la que se quiere firma automática, por ejemplo. //FIRMAU ZTBGBFF0 EXEC PGM=ZTBGBFF0,PARM=' EDIFF1' //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS),DISP=SHR No obstante, este proceso, se puede encadenar en un paso previo al paso de carga en el procedimiento previo a emisión: //FIRMAUT EXEC PGM=ZTBGBFF0, // PARM='01-&L1&L2&R1&R2&AP&LF/CBLQDA(ON)', // REGION=0M,TIME=25 //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS),DISP=SHR Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-3

14 Según el ejemplo anterior, con la sesión EDIFF1, imaginemos que el fichero KI.EGTC.ZTBP.FICHEROS(ZTBGFITS), contiene lo siguiente: ********************************* Top of Data ********************************** C TCPIPB C2-KI.EITC.NFS C APLI01-frodriguez -S- C APLI02-fgutierrez -N- C APLI03-fgarcia -S- C APLI04-fgarcia -N- C EDIFF1-fjaraba -S- ******************************** Bottom of Data ******************************** El paso FIRMAU, detecta que la última ficha C3 es la que contiene datos de la sesión, (el resto de ellas no son válidas para la sesión referenciada), de forma que llama al servidor FF, indicando que se use el user fjaraba para firmar, e indicando que se habilite el envío. Si se usa la función 01, no es necesario el fichero ZTBGFCAR. El servidor EDItran/FF conoce los ficheros de la presentación y los firma automáticamente con el usuario descrito. Además se puede indicar si se quiere o no habilitar el envío Firma automática de n ficheros de una presentación. Esta opción es parecida a la anterior (firma automática de la sesión de presentación). La diferencia es que el servidor FF no conoce que ficheros están asociados a una presentación (normalmente porque la aplicación genera ficheros con nombres distintos, por ejemplo con la fecha de sistema). Con esta opción, los usuarios no firman manualmente los ficheros de la presentación. En un paso previo a la carga, se llama al servidor FF, y se le proporciona el usuario firmante (cuyo certificado reside en el servidor), y el fichero a firmar. El servidor EDItran/FF, firma dicho fichero y lo asocia a su aplicación. Al utilizar esta opción, se incluye un paso previo a la carga (ya sea un paso previo en el procedimiento ó un jcl por fuera). Se utiliza el jcl ZTBGJFF0 (funcion 02, 03 ó 04). Función 02- Firmar automáticmante el / los ficheros indicados en ZTBGFCAR, sin habilitar Función 03- Firmar automáticmante el / los ficheros indicados en ZTBGFCAR, pidiendo en el último que se habilite el envío. Función 04- Habilitar el envío. Este jcl tira del programa ZTBGBFF0, pasando vía parm la sesión de presentación para la que se quiere firma automática y los ficheros a firmar, por ejemplo. //FIRMAU EXEC PGM=ZTBGBFF0,PARM=' EDIFF1' //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS),DISP=SHR //ZTBGFCAR DD DSN=KI.EGDC.ZTBP.FICHEROS(LISTFICH),DISP=SHR No obstante, este proceso, se puede encadenar en un paso previo al paso de carga en el procedimiento previo a emisión: Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-4

15 //FIRMAUT EXEC PGM=ZTBGBFF0, // PARM='03-&L1&L2&R1&R2&AP&LF/CBLQDA(ON)', // REGION=0M,TIME=25 //ZTBGFITS DD DSN=KI.EGTC.ZTBP.FICHEROS(ZTBGFITS),DISP=SHR //ZTBGFCAR DD DSN=KI.EGDC.ZTBP.FICHEROS(LISTFICH),DISP=SHR Según el ejemplo anterior, con la sesión EDIFF1, imaginemos que el fichero KI.EGTC.ZTBP.FICHEROS(ZTBGFITS), contiene lo siguiente: ********************************* Top of Data ********************************** C TCPIPB C2-KI.EITC.NFS C APLI01-frodriguez -S- C APLI02-fgutierrez -N- C APLI03-fgarcia -S- C APLI04-fgarcia -N- C EDIFF1-fjaraba -S- ******************************** Bottom of Data ******************************** El paso FIRMAU, detecta que la última ficha C3 es la que contiene datos de la sesión, (el resto de ellas no son válidas para la sesión referenciada), de forma que llama al servidor FF, indicando que se use el user fjaraba para firmar el-los ficheros contenidos en la lista ZTBGFCAR (puede ver el formato ZTBGFCAR en. Suponiendo una aplicación, que genere ficheros de aplicación con nombres distintos cada día, y además quiera firmar automáticamente, puede hacer de 3 formas: Cada vez que la aplicación genera un fichero, grabar el nombre del mismo en ZTBGFCAR, y arrancar el jcl descrito (función 02). El último jcl generarlo con función 03. Cuando están todos, arrancar el previo a emisión standard. Cada vez que la aplicación genera un fichero, añade el nombre del mismo a ZTBGFCAR. Cuando se graba el último, se lanza un previo a emisión, cuyo primer paso es el descrito (función 03). Cada vez que la aplicación genera un fichero, grabar el nombre del mismo en ZTBGFCAR, y arrancar el jcl descrito (función 02). En el previo a emisión, poner un paso previo con función 04 (habilitar). En ambos casos, cuando se arranque el paso de carga del previo a emisión, se utilizará editran ff en modo automático (se llamará de nuevo al servidor, el cual nos dirá los ficheros que debemos cargar). Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-5

16 5.3. Verificación de habilitaciones y carga de emisión (Modo no automático). Utilizar el procedimiento ZTBGP1CF. Requiere más pasos que el caso automático. El modo de funcionamiento en modo no automático es el siguiente : PROC ZTBGP1CF, LF=S PASO 1 ZTBGBFF1 CALL ZTBGBF11 ENTRADA ZTBGFCAR (new,catlg) (jcl) ZTBGFFIR (new,pass) (jcl) PASO 2 ZTBGB110 LF=S TAMPON PASO 3 ZTBGBFF2 (DELETE s) PASO 4 IEBFR14 (DELETE) Habilitación Firma 1 Firma n Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-6

17 Se ha implementado la posibilidad de que una vez que se hayan generado los ficheros de firma, sólo se puedan cargar y emitir, si se ha habilitado la sesión para ello. Así, se ha desarrollado un jcl, que en un primer paso, valida si existe tal habilitación y crea un fichero con la lista de ficheros a cargar-emitir. En un segundo paso, lanza el previo a emisión. Dichos procesos se desarrollan en el jcl ZTBGJFF1, el cual consta de lo siguiente: 1. PASO1, PARM. Se le pasan 3 parámetros distintos; origen, función y sesión de presentación. El origen, en caso de lanzarlo desde jcl, es A(aplicación). La función admite los valores: 00(sólo validar habilitación), 01(validar habilitación y cargar), 03(validar habilitación, cargar y pedir la emisión). Con función 00, el jcl acaba en su paso1 con return code 04, de forma que impide ejecutar el paso2. La sesión de presentación consta de origen-destino y aplicación. Nivel Nombre Long. Tipo Descripción 1 Origen 01 Alfn. A- (Aplicación). En caso de lanzarlo desde jcl. O- (Operador). En caso de lanzamiento de procedimiento desde EDItran/G. E- (Editran). En caso de lanzamiento de procedimiento desde EDItran/P. 1 Función 02 Num. 00- Validar habilitación (función sólo disponible si se ejecuta desde jcl) 01- Validar habilitación y cargar. 03- Validar habilitación, cargar y pedir la emisión. 1 Sesión de 24 Alfn. Sesión de presentación presentación 2 Origen 9 Alfn. Nif origen de la sesión de presentación. En caso de lanzarse procedimiento, este campo se forma con las variables &L1&L2. 2 Destino 9 Alfn. Nif destino de la sesión de presentación. En caso de lanzarse desde procedimiento, este campo se forma con las variables &R1&R2. 2 Aplicación 6 Alfn. Aplicación de la sesión de presentación. En caso de lanzarse desde procedimiento, este campo se forma con la variable &AP. 2 Modo verificación (Recoger ficheros) 1 Alfn. Indica si queremos conexión tcp/ip a un server para que nos devuelva el resultado de la habilitación y el nombre de ficheros a cargar o que saque los ficheros de una lista (ENTRADA). 1-Tira del fichero ENTRADA 2- Llama a programa server, en función de datos recogidos en fichero ZTBGFITS ZTBGFCAR del PASO1 es el nombre del fichero de salida, que contiene los ficheros a cargar y el formato de los mismos, para que el paso 2 los cargue. ZTBGFFIR del PASO1, es un fichero que se borra al acabar el jcl, en el que se grabará la lista de ficheros que se quieren borrar en el paso3. ZTBGFLIS del PASO1, es un informe de lo que ha ocurrido con los ficheros tratados en el PASO1. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-7

18 INFORME CARGA FICHEROS EDITRAN/FF SESION PRESENTACION : GENERI TIPO HABILITACION : FICHEROS DE FIRMAS NRO FICH. FIRMAS A VERIFICAR : 02 TIPO DE GRABACION EN TAMPON : FICH.DATOS,FICH.FIRMA Y APLIC. FICHEROS TRATADOS KI.EIDC.ZTBG.APLIC KI.EGDC.ZTBP.JCLS(ZTBPJITR) KI.EIDC.ZTBG.FIRMA1 KI.EIDC.ZTBG.FIRMA2 KI.EIDC.ZTBG.JCLS(ZTBGJILO) KI.EIDC.ZTBG.FIRMA21 KI.EIDC.ZTBG.FIRMA22 KI.EIDC.ZTBG.FIRMA23 VERIFICACION PARA LA CARGA FINALIZA CORRECTAMENTE FICHEROS CARGADOS KI.EGDC.ZTBP.JCLS(ZTBPJITR) KI.EIDC.ZTBG.FIRMA1 KI.EIDC.ZTBG.FIRMA2 KI.EIDC.ZTBG.JCLS(ZTBGJILO) KI.EIDC.ZTBG.FIRMA11 KI.EIDC.ZTBG.FIRMA12 KI.EIDC.ZTBG.FIRMA13 ENTRADA del paso 1 es un fichero creado por el usuario cuyo formato es fijo, de longitud 80 y con los siguientes registros: 1nombre-fichero-habilitación 2nombre-fichero1-emisión 3nombre-fichero1-firma-emisión abbc El último puntero del primer fichero (habilitación), debe de coincidir con la aplicación de EDItran/FF asociada a los ficheros a firmar. Nivel Nombre Long. Tipo Descripción 1 Registro-fich-entrada 80 2 Tipo de fichero 1 Alfn. Tipo de fichero de entrada: 1-Fichero de habilitación. 2-Fichero de aplicación para emitir. 3-Fichero de firmas PCKS#7 2 Dsname de fichero 44 Alfn. Dsname del fichero de entrada 2 Resto de datos 35 Alfn. Espacios en caso de ficheros de tipo registro Tipo-habilitación (sólo en tipo registro 1) 1 Num. 0-Verificar que existe fisicamente fichero habilitación (dsname del tipo registro 1). 1-Verificar que exiten fisicamente los nn ficheros de firmas (tipo de registro 3), por cada tipo de fichero de datos (tipo de registro 2), indicado en su campo correspondiente (número de ficheros de firma a verificar). 2-Ambos Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-8

19 3 Número de ficheros de firma a verificar (sólo en tipo registro 1) 3 Tipo de grabación en fichero tampón (sólo en tipo registro 1) 3 Número de ficheros de aplicación a verificar que existen y a enviar (sólo en tipo registro 1) 2 Num Especifica el número de ficheros de firmas (tipo de registro de 3), por cada tipo de fichero de datos (tipo de registro 2), que se desea verificar que realmente existen. 1 Num. 0- No se graba nada. 1- Se graban sólo los ficheros de datos (tipo de registro 2). 2- Se graban todos los ficheros de datos (tipo de registro 2) y todos los ficheros de firma que existan (tipo de registro 3). 3- Se graban todos los ficheros de datos (tipo de registro 2) y del resto, todos los que existan (tipo de registro 1 y 3, de forma que se incluye el de habilitación). 4- Se graban todos los ficheros de datos (tipo de registro 2) y el de habilitación, si existe (tipo de registro 0). 2 Num. 00- Deben de existir todos los ficheros de aplicación Deben existir, AL MENOS, nn ficheros de aplicación y se enviarán, de ellos, los que existan (puede que nn sea 01 y existan 2, de forma que se cargarían 2 y se enviarían 2(tipo de registro 2), siempre y cuando todos ellos cumplieran el resto de parametrizaciones (número de registros de tipo 3 a validar, etc). 3 Filler 30 Alfn. Area de reserva a espacios. Así, por ejemplo, si tenemos creado un fichero ENTRADA con las siguientes características: 1KI.FICHERO.HABILITACION KI.FICHERO1.APLICACION 3KI.FICHERO1.APLICACION.FIRMA1.PKCS7 3KI.FICHERO1.APLICACION.FIRMA2.PKCS7 3KI.FICHERO1.APLICACION.FIRMA3.PKCS7 3KI.FICHERO1.APLICACION.FIRMA4.PKCS7 3KI.FICHERO1.APLICACION.FIRMA5.PKCS7 2KI.FICHERO2.APLICACION 3KI.FICHERO2.APLICACION.FIRMA1.PKCS7 3KI.FICHERO2.APLICACION.FIRMA2.PKCS7 3KI.FICHERO2.APLICACION.FIRMA3.PKCS7 3KI.FICHERO2.APLICACION.FIRMA4.PKCS7 3KI.FICHERO1.APLICACION.FIRMA5.PKCS7 En el host, sólo existen fisicamente los siguientes ficheros: KI.FICHERO.HABILITACION KI.FICHERO1.APLICACION KI.FICHERO2.APLICACION KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7 KI.FICHERO2.APLICACION.FIRMA5.PKCS7 El programa de carga-validación, en el primer grupo de registros de tipo 1,2 y 3, verificará que el primer registro de ENTRADA, el que contiene el dsname del fichero de habilitación (comienza por 1): Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-9

20 Tiene un 2 en la posición 46, lo que indica que verifique que existen fisicamente el fichero cuyo tipo comienza por 1 y que verifique que existen fisicamente, al menos, 03 ficheros de tipo 3, por cada fichero de tipo 2. Es correcto, puesto que existen: KI.FICHERO.HABILITACION Para fichero de tipo 2, KI.FICHERO1.APLICACION, existen: KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 Para fichero de tipo 2, KI.FICHERO2.APLICACION, existen: KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7 Tiene un 03 en las posiciones 47-48, de forma que ya se explicó su significado con el campo anterior (verificar que existen fisicamente, al menos, 03 ficheros de firmas, de tipo 3, por cada fichero de tipo 2). Tiene un 2 en la posición 49, lo que le indica, que cargue todos los de aplicación, de tipo 2, y todos los de firma que existan, de tipo 3 (al menos, existían 03 por cada uno de los de tipo 2, por la validación anterior). Tiene un 00 en las posición 50-51, lo que le indica, que deben existir fisicamente todos los ficheros de aplicación especificados y además debe de cargarlos todos (registros de tipo 2). Con ello, se cargarán los siguientes ficheros: KI.FICHERO1.APLICACION KI.FICHERO1.APLICACION.FIRMA1.PKCS7 KI.FICHERO1.APLICACION.FIRMA2.PKCS7 KI.FICHERO1.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION KI.FICHERO2.APLICACION.FIRMA2.PKCS7 KI.FICHERO2.APLICACION.FIRMA3.PKCS7 KI.FICHERO2.APLICACION.FIRMA4.PKCS7 KI.FICHERO2.APLICACION.FIRMA5.PKCS7 Si alguno de criterios de verificación o carga no se cumple, el proceso se detendrá sin cargar nada. Así, si en el ejemplo anterior, no existiese KI.FICHERO.HABILITACION, como el fichero de tipo 1, tiene un 2 en la posición 46, (lo cual indica que verifique que existen fisicamente el fichero de tipo 1 y que verifique que existen fisicamente, al menos, 03 ficheros de tipo 3, por cada fichero de tipo 2). Al no existir el de tipo 1, el proceso falla. Se recomienda la utilización de criterios coherentes en cuanto a la verificación y a la carga, por ejemplo, si no existe KI.FICHERO.HABILITACION, e indicamos la ficha: 1KI.FICHERO.HABILITACION A pesar de que el proceso funcionaría sin problemas, le estamos indicando, que verifique que existen unicamente 3 ficheros de tipo 3 por cada fichero de tipo 2, y que cargue ficheros de tipo 2 y fichero de tipo 1 (éste último no existe, por lo que es incoherente). No se permiten procesos que conlleven más de 99 ficheros a cargar. Indra. Todos los derechos reservados EF51USUA.doc 18/10/2011 Pag. 5-10