Curso Iaap I17f-Ps23

CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA
Desarrollo de aplicaciones y
servicios de administracin
electrnica en el marco de la
Ley 39/2015
Instituto Andaluz de Administracin Pblica

07 y 18 de abril de 2017
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA De s arro llo de aplic ac io ne s y s e rvic io s de
adminis trac i n e le c tr nic a e n e l marc o de
la Le y 39/2015
NDICE
1)Introduccin al Esquema Nacional de Interoperabilidad.
2)NTI de Documento electrnico.
3)NTI de Expediente electrnico.
4)Libreras conversor-eni y enidocWS.
5)La Herramienta Centralizada de Verificacin.
6)La Herramienta para la validacin y verificacin de
documentos y expedientes electrnicos.
7)Generacin de expedientes electrnicos en el motor de
tramitacin Trew@.
8)Port@firmas. Integracin de aplicaciones y servicios con
adecuacin al ENI.
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
INTR ODUC C IN AL ENI
Definicin de interoperabilidad
INTEROPERABILIDAD:
Capacidad de los sistemas de informacin y

de los procedimientos a los que stos dan
soporte, de compartir datos y
posibilitar el intercambio de informacin y
conocimiento entre ellos. Resulta necesaria
para la cooperacin, el
desarrollo, la integracin y la prestacin de
servicios por las Administraciones Pblicas.
Pg.-4-
Declaracin del E squema Nacional de Interoperabilidad (E NI)
El Art.156.1 Ley 40/2015: Art. 42.1 derogada 11/2007
El Esquema Nacional de Interoperabilidad comprende[r] el

conjunto de criterios y recomendaciones en materia de
seguridad, conservacin y normalizacin de la informacin, de
los formatos y de las aplicaciones que debern ser tenidos en
cuenta por las Administraciones Pblicas para la toma de
decisiones tecnolgicas que garanticen la interoperabilidad.
Desarrollo normativo ENI: R.D. 4/2010, de 8 de enero,

por el que se regula el Esquema Nacional de
Interoperabilidad.
Plazo adecuacin: hasta el 30 de enero de 2014.
Pg.-5-
DIR 3 (Directorio C omn, art 9 E NI)
El Directorio Comn es un inventario unificado

y comn a todas las AA.PP. de las unidades
orgnicas / organismos pblicos, sus oficinas
de registro y atencin a la ciudadana y sus
unidades de gestin econmica-presupuestaria,
bajo un criterio de mantenimiento distribuido y
corresponsable de la informacin. Es un
instrumento bsico para la interoperabilidad
entre AA.PP. La informacin de la Junta de
Andaluca en el Directorio Comn se gestiona
de manera centralizada en la Direccin
General de Planificacin y Evaluacin.
Pg.-6-
R PA (R egistro de P rocedimientos Administrativos)
Registro con la informacin de los

procedimientos y servicios de la Administracin
de la Junta de Andaluca.
Cada Consejera gestiona la informacin en el
Registro de sus procedimientos y servicios
mediante una herramienta informtica
centralizada existente en la Consejera de
Hacienda y Administracin Pblica.
La informacin de los procedimientos que se
muestra en el portal de atencin a la ciudadana
de la CHAP se toma automticamente de este
Registro.
Pg.-7-
S IA (S istema de Informacin Administrativa)
Inventario de procedimientos y servicios de las

AA.PP. e instrumento bsico para la
interoperabilidad entre AA.PP. Todos los
procedimientos y servicios de la Junta de Andaluca
deben estar inscritos en el SIA. La informacin de
los procedimientos y servicios en el SIA se
actualiza a partir de la informacin en el Registro
de Procedimientos Administrativos de la Junta de
Andaluca. Los procedimientos y servicios estn
disponibles para la ciudadana en el buscador de
trmites del Punto de Acceso General (PAG):
http://tramites.administracion.gob.es/comunidad/tr
amites/tramites
Pg.-8-
Metadato. Definicin.
Dato que define y describe otros datos.
Los metadatos asociados a los documentos y
expedientes electrnicos sirven para identificarlos,
autenticarlos y contextualizarlos, y del mismo modo
a las personas, procesos y sistemas que los crean,
gestionan, mantienen y utilizan.
Posibilitan la creacin, gestin y uso de los
documentos y expedientes electrnicos a lo largo del
tiempo durante su ciclo de vida.
Constituyen un instrumento fundamental para la
interoperabilidad en especial para la remisin de los
documentos y expedientes a otras AA.PP. y al
archivo electrnico nico de los procedimientos
finalizados.
Pg.-9-
R epositorio electrnico de documentos (art 21 R D 2/2010)
Elemento nuclear en el Esquema es la creacin de

un repositorio electrnico, destinado a cubrir el
conjunto del ciclo de vida de los documentos
electrnicos, complementario y equivalente en
cuanto a su funcin al archivo convencional de
oficina en primer lugar. En un repositorio
electrnico se almacenan y administran datos y
documentos electrnicos, y sus metadatos. Se
implementa mediante una aplicacin especfica
para el almacenamiento fiable de los documentos
electrnicos y sobre el mismo deben implantarse
los procesos de gestin de documentos electrnicos
Pg.-10-
S ituacin previa NTI en sistemas de tramitacin
Codificaciones propias o ausencia de codificaciones
para unidades orgnicas, procedimientos o
metadatos.
Los sistemas custodian ficheros en cualquier tipo de
formato.
Cada sistema asigna a los ficheros los metadatos que
la entidad cree necesarios. No existe criterio comn.
Unos ficheros se firman y otros no.
No existe uniformidad en los sistemas de verificacin
de firmas.
Los sistemas de tramitacin no son interoperables: se
hace complejo o imposible trasladar documentos y
expedientes entre ellos.
Pg.-11-
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
NTI DE DOC UME NTO E LE C TRNIC O
C omponentes del documento electrnico
CONTENIDO: conjunto
de datos en el que se
sustancia la informacin.
FIRMAS: garantizan la
integridad y autora del
contenido.
METADATOS:
proporcionan contexto al
contenido y a la firma.
C ontenido
CONTENIDO: el
formato deber estar
entre los admitidos en la
Norma Tcnica de
Interoperabilidad de
Catlogo de estndares.
NTI DE DOC UME NTO ELE C TRNIC O
Firmas
FIRMAS:
Una como mnimo.
Firma reconocida formato NTI Catlogo de Estndares.
TF02 - XAdES internally detached signature.

TF03 - XAdES enveloped signature.
TF04 - CAdES detached/explicit signature.
TF05 - CAdES attached/implicit signature.
TF06 PadES
Firma CSV (Requiere de Orden/Resolucin o documento que

defina su creacin).
TF01 CSV.
Metadatos mnimos obligatorios
1 - VERSIN NTI
Identificador normalizado de la versin de la
NTI de documento electrnico conforme a la
cual se estructura el documento electrnico.
Para la versin actual tomar el valor:
http://administracionelectronica.gob.es/ENI/
XSD/v1.0/documento-e
2 - IDENTIFICADOR
Identificador normalizado del documento. Tomar la
siguiente forma:
ES_<organo>_<AAAA>_<id_especifico>
Donde:
<organo> se codifica como el metadato rgano (DIR3)
<AAAA> es el ao de fecha de captura
<id_especifico> es un cdigo alfanumrico de 30
caracteres que identifica de forma nica cada documento
dentro de la organizacin responsable.
3 RGANO
Identificador normalizado de la administracin generadora del
documento o que realiza la captura del mismo.
Este dato ser extrado del Directorio Comn de unidades
orgnicas y oficinas.
4 FECHA DE CAPTURA
Fecha de alta del documento en el sistema de gestin
documental. Seguir el formato <ISO 8601>, AAAAMMDD T
HH:MM:SS
5 ORIGEN
Indica si el contenido del documento fue creado por un
ciudadano o por una administracin. '0'=ciudadano;
'1'=Administracin.
6 ESTADO DE ELABORACIN
Indica la naturaleza del documento. Si es copia, indica tambin
si se ha realizado una digitalizacin o conversin de formato en
el proceso de generacin. Puede tomar los siguientes valores:
Original
Copia electrnica autntica con cambio de formato
Copia electrnica autntica de documento papel
Copia electrnica parcial autntica
Otros.
Metadatos mnimos obligatorios (E S TADO DE E LABOR AC IN)
7 NOMBRE DE FORMATO
Formato lgico del fichero de contenido del documento electrnico. Valor extrado de
la lista de formatos admitidos para ficheros definidos en la NTI de catlogo de
estndares.
8 TIPO DOCUMENTAL
Descripcin del tipo documental del documento.
Documentos de decisin:
TD01 Resolucin, TD02 Acuerdo, TD03 Contrato, TD04 Convenio, TD05 Declaracin
Documentos de transmisin:
TD06 Comunicacin, TD07 Notificacin, TD08 Publicacin, TD09 - Acuse de recibo.
Documentos de constancia:
TD10 Acta, TD11 Certificado, TD12 Diligencia
Documentos de juicio:
TD13 - Informe.
Documentos de ciudadano:
TD14 Solicitud. TD15 Denuncia, TD16 Alegacin, TD17 Recursos, TD18 -
Comunicacin ciudadano, TD19 Factura, TD20 - Otros incautados.
Otros: TD99 - Otros
9 TIPO DE FIRMA
Indica el tipo de firma que avala al documento. En caso de firma con
certificado, indica el formato de la firma. Tomar el valor 'CSV', o en caso de
firma electrnica los formatos establecidos en la NTI de Interoperabilidad de
Poltica de firma y certificados de la Administracin (XAdes internally detached
signature, XAdes enveloped signature, CAdes detached/explicit signature,
CAdes attached/implicit signature, Pades).
10 SI TIPO DE FIRMA = 'CSV'..

Se debern definir los siguientes metadatos adicionales:
Valor CSV: Valor del CSV
Definicin generacin CSV: Referencia a la Orden, Resolucin o documento
que define la creacin del CSV correspondiente.
10 IDENTIFICADOR DE DOCUMENTO ORIGEN

Si el estado de elaboracin es copia autntica con cambio de formato o copia
parcial autntica, adoptar el valor del metadato identificador del documento
origen al que corresponde la copia
Metadatos completarios
Atendern a necesidades de descripcin

especficas, conforme a la NTI de poltica de
gestin de documentos electrnicos.
e-EMGDE
Esquema de metadatos para la gestin del
documento electrnico.
Ejemplo: Metadato Rol de firma
Definicin: Indicador normalizado de la
funcin que desempea la firma utilizada.
Valores: valida, autentica, refrenda, visa,
representa, testimonia.
P reguntas frecuentes
Qu formato se emplea para empaquetar toda la informacin presente en un
documento electrnico?
Como formato de intercambio del documento electrnico la NTI de Documento

Electrnico define una estructura XML donde se une el contenido, sus firmas y
sus metadatos.
Los sistemas de informacin deben custodiar internamente la informacin en este

formato XML?
No necesariamente. En el Esquema Nacional de Interoperabilidad no se

establecen previsiones con respecto a la forma de implementacin a nivel
interno de los metadatos que forman parte de un documento electrnico. Slo
en el caso en que un documento electrnico intervenga en un proceso de
intercambio, la implementacin de sus metadatos, junto al resto de sus
componentes, se deber realizar segn la estructura y condiciones de la Norma
Tcnica de Interoperabilidad de Documento Electrnico.
A qu nos referimos cuando nombramos el ENIDOC?
Es un modo comn de referirse a la estructura XML definida para el Documento Electrnico. Este
trmino no se establece en la NTI.
Los metadatos se firman?
No. La firma solo se realiza sobre el contenido.
Cuando se asignan los metadatos?
En el momento de generacin/captura del documento. Solo se prev la posible modificacin de valores

para la correccin de errores en las asignaciones iniciales.
Actualizo los metadatos Identificador y rgano cuando vara el cdigo DIR3 de mi organismo?
No. Si cambia el cdigo DIR3 de mi organismo, el nuevo cdigo DIR3 solo afecta a los documentos
generados/capturados a partir del cambio. Los metadatos de los documentos existentes previamente
no se actualizan.
Por qu en el XML es opcional la firma si la NTI dice que todo documento electrnico ha de
tener al menos una firma?
El XSD de definicin del Documento Electrnico permite la ausencia de firmas para permitir
el intercambio de la estructura XML entre sistemas de informacin que estn en fase de
construccin de un nuevo Documento Electrnico. Ejemplo: un sistema que remite la
estructura XML a Port@firmas para que en Port@firmas se genere la firma electrnica que
posteriormente se incorpora al documento.
El esquema XML permite el uso de cofirmas y contrafirmas?
S. El XSD define una cardinalidad 0..N para las firmas electrnicas.
Cmo se intercambian los metadatos complementarios?
El XSD no lo permite. De existir, deben enviarse externamente al fichero XML ENIDOC,

viajando en una estructura propia que defina cada organizacin.
E jemplo
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
NTI DE E XP E DIE NTE E LE C TR NIC O
C omponentes del E xpediente E lectrnico
NDICE: relacin de documentos
del expediente.
FIRMA DEL NDICE: garantiza
su integridad.
METADATOS: proporcionan
informacin de contexto.
FICHERO DE
VISUALIZACIN:
opcionalmente puede incorporar
un fichero (PDF, imgen..) que
reproduzca el contenido del
ndice.
E structura del ndice
Los documentos pueden
ser clasificados en
carpetas y en sub-
expedientes.
Datos de cada documento:
Identificador
Valor resumen
Funcin HASH
empleada
Opcionalmente, fecha
incorporacin y orden
Firma del ndice
Garantiza su integridad:
Permite detectar que se aaden o eliminan
documentos.
Permite detectar que se sustituyen documentos,
gracias a que en el ndice se incluye el HASH del
contenido de los documentos electrnicos.
Como formatos de firma se admiten:

CSV
Firma electrnica basada en certificados, en
alguno de los formatos admitidos en la NTI de
Catlogo de Estndares.
1 - VERSIN NTI
Identificador normalizado
de la versin de NTI de
expediente electrnico
conforme a la cual se
estructura el expediente.
Para la NTI analizada
tomar el valor
http://administracionelectr
onica.gob.es/E
NI/XSD/v1.0/expediente-e
2 - IDENTIFICADOR
Identificador normalizado del expediente, en el formato:
ES_<rgano>_<AAAA>_EXP_<id_especfico>
Donde:
<rgano> se codifica como el metadato rgano (DIR3)
<AAAA> es el ao de fecha de creacin del expediente
<id_especifico> cdigo alfanumrico que identifica de
forma nica al expediente dentro de los generados por la
administracin responsable. Cada administracin puede
disear el proceso de generacin segn sus necesidades.
3 - RGANO
Identificador normalizado (DIR3) de la
administracin responsable de la
tramitacin del procedimiento. Puede tener
ms de un valor.
4 FECHA DE CAPTURA DEL

EXPEDIENTE
Siguiendo el estndar ISO-8601
5 - CLASIFICACIN
Procedimiento administrativo con el que se
relaciona el expediente. Esquema de valores
normalizado segn el Sistema de Informacin
Administrativa (SIA). Si el procedimiento no se
encuentra en SIA:
<rgano>_PRO_<ID_PRO_especfico>
Donde:
ID_PRO_especfico:
ID_PRO_especfico Cdigo alfanumrico que
identifica al procedimiento dentro de los propios de
cada administracin.
6 - ESTADO
Estado del expediente en el momento del
intercambio. Los valores posibles son
'abierto', 'cerrado, 'ndice para remisin
cerrado'.
7 INTERESADO
De 0 a N identificadores de los interesados
del expediente (DNI/NIE/NIF/DIR3).
Metadatos complementarios
Se podrn asignar metadatos complementarios

para atender a necesidades de descripcin
especficas. Estos metadatos complementarios se
aplicarn, en su caso, de acuerdo con lo previsto
en la Norma Tcnica de Interoperabilidad de
Poltica de gestin de documentos electrnicos.
e-EMGDE
Ejemplo:
TIPO DE ACCESO:
Libre/Parcialmente restringido/Restringido
Qu formato se emplea para empaquetar toda la informacin presente en el expediente
electrnico?
Como formato de intercambio del expediente electrnico la NTI de Expediente Electrnico

define una estructura XML donde se une el ndice, su firma y sus metadatos.
Los sistemas de informacin deben custodiar internamente la informacin en este formato XML?
No necesariamente. Los requisitos de la Norma Tcnica de Interoperabilidad de Expediente

Electrnico no afectan a la implementacin interna del expediente. Las implantaciones
especficas se debern disear valorando la necesidad de aplicar requisitos adicionales en
funcin de las circunstancias especficas. La norma no hace previsiones con respecto a la forma
de implementacin a nivel interno de los diferentes componentes de un expediente electrnico
(ndice, documentos y metadatos) fuera de operaciones de intercambio. No establece ninguna
consideracin relativa al tratamiento del ndice electrnico a nivel interno. En todo caso, se
debe permitir trasladar la informacin a la estructura XML indicada en la norma en caso de
intercambio.
El expediente electrnico incorpora sus documentos?
No. El ndice del expediente solo relaciona los identificadores y la funcin resumen del
contenido de los documentos, pero el contenido de los documentos no est presente en la
estructura XML del expediente electrnico. El ENI no define una estructura contenedora del
expediente electrnico y el contenido de sus documentos.
E jemplo
<eniexp:expediente ---->
<eniexpind:indice>
<eniexpind:IndiceContenido>
<eniconexpind:FechaIndiceElectronico>2016-01-21T18:41:22.913+01:00</eniconexpind:FechaIndiceElectronico>
<eniconexpind:CarpetaIndizada>
<eniconexpind:IdentificadorCarpeta>SOLICITUD TELEMATICA</eniconexpind:IdentificadorCarpeta>
<eniconexpind:DocumentoIndizado>
<eniconexpind:IdentificadorDocumento>ES_A01002823_2015_TREWA0000000000000000000000319</eniconexpind:IdentificadorDocumento>
<eniconexpind:ValorHuella>3a3d614606363a470364ca303ced728fa8f65b62</eniconexpind:ValorHuella>
<eniconexpind:FuncionResumen>SHA-1</eniconexpind:FuncionResumen>
<eniconexpind:FechaIncorporacionExpediente>2015-12-21T12:02:22.000+01:00</eniconexpind:FechaIncorporacionExpediente>
</eniconexpind:DocumentoIndizado>
</eniconexpind:CarpetaIndizada>
</eniexpind:IndiceContenido>
<enids:firmas>
<enids:firma>
<enids:TipoFirma>TF02</enids:TipoFirma>
<enids:ContenidoFirma>
<enids:FirmaConCertificado>
<enids:FirmaBase64>****</enids:FirmaBase64>
</enids:FirmaConCertificado>
</enids:ContenidoFirma>
</enids:firma>
</enids:firmas>
</eniexpind:indice>
<eniexpmeta:metadatosExp>
<eniexpmeta:VersionNTI>http://administracionelectronica.gob.es/ENI/XSD/v1.0/expediente-e</eniexpmeta:VersionNTI>
<eniexpmeta:Identificador>ES_A01002823_2015_EXP_TREWACHAP/2015/000000000000036</eniexpmeta:Identificador>
<eniexpmeta:Organo>A01002823</eniexpmeta:Organo>
<eniexpmeta:FechaAperturaExpediente>2015-12-21T12:02:01.000+01:00</eniexpmeta:FechaAperturaExpediente>
<eniexpmeta:Clasificacion>A01002823_PRO_000000000000000000000000000001</eniexpmeta:Clasificacion>
<eniexpmeta:Estado>E01</eniexpmeta:Estado>
<eniexpmeta:Interesado>75554816T</eniexpmeta:Interesado>
</eniexpmeta:metadatosExp>
</eniexp:expediente>
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA LIBRERAS CONVERS OR-ENI Y
ENIDOCWS
R ecursos para integradores
Ambas libreras, conversor-eni y enidocWS, facilitan el intercambiando de
documentos y expedientes electrnicos entre aplicaciones.
conversor-eni
El mdulo de conversin, consistente en una librera, permite realizar las

transformaciones necesarias para realizar el intercambio de documentos y
expedientes electrnicos segn las estructuras definidas por la NTI de Documentos
electrnico y NTI de Expediente Electrnico, respectivamente.
La librera permite realizar las funcionalidades relativas a la construccin del XML a

partir de un objeto JAVA, al igual que su proceso inverso. sta incluye las
validaciones necesarias para garantizar que se cumplen las consideraciones de
aplicacin y las pautas para la generacin de la estructura definida.
enidocWS
Protocolo basado en REST para el de intercambio de documentos electrnicos entre

sistemas. Permite:
1.Acceso: un sistema cliente solicita a un repositorio de documentos electrnicos el

acceso a uno de ellos, a partir de su cdigo seguro de verificacin.
2.Solicitud de custodia: un sistema cliente solicita a un repositorio de documentos

ENIDOCWS
conversor-eni
conversor-eni
ENIDOCWS
conversor-eni
A continuacin se muestra un ejemplo bsico de lectura de documento ENI:
ENI
ENIDOCWS
conversor-eni
A continuacin se muestra un ejemplo bsico de generacin de expediente ENI:
/**
* Mtodo para generar un expediente electrnico
* @param out
* @throws ConversorException
*/
public void escribirExpedienteElectronico(ByteArrayOutputStream out)
throws ConversorException {
// Nuevo expediente electrnico
ExpedienteEni expEni = new ExpedienteEni();
//Metadatos del expediente
expEni.establecerIdentificador("MEH000000000000000000000000008");
expEni.setClasificacion("A12345678_PRO_ADELEC_PR000000000000000000000");
expEni.setEstado(new Estado("E01"));
expEni.setFechaApertura(new Date());
List<String> ints = new ArrayList<String>();
ints.add("12345678Z");
expEni.setInteresados(ints);
ENIDOCWS
conversor-eni
// Opcional en caso de ser nulo se interpreta como XXXXXXXXX
List<String> orgs = new ArrayList<String>();
orgs.add("A23442888");
expEni.setOrganos(orgs);
//Indice del expediente
IndiceExpedienteEni indiceExpediente = new IndiceExpedienteEni();
indiceExpediente.setFechaIndice(new Date());
List<DocumentoIndice> documentosIndice = new ArrayList<DocumentoIndice>();
DocumentoIndice docInd = new DocumentoIndice();
docInd.setFechaIncorporacionExpediente(new Date());
docInd.setFuncionResumen("SHA-1");
docInd.setIdentificadorDocumento("ES_E00004101_2011_MPR000000000000000000000000003");
docInd.setOrdenDocumentoExpediente("1");
docInd.setValorHuella("c723be19bb2291f8d55d6aad0c07a755801edff3");
documentosIndice.add(docInd);
indiceExpediente.setDocumentosIndice(documentosIndice);
ENIDOCWS
conversor-eni
//Firma del indice electronico
List<FirmaEni> firmas = new ArrayList<FirmaEni>();
FirmaEni firma = new FirmaEni();
firma.setTipoFirma(TipoFirma.TF01);
CsvEni CSV = new CsvEni();
CSV.setValor("bf83ab26478a7a7f4ddf99976a3fee39a110c829");
CSV.setRegulacion("BOE-A-0034-05200");
firma.setCSV(CSV);
firmas.add(firma);
indiceExpediente.setFirmas(firmas);
expEni.setIndiceExpediente(indiceExpediente);
//Visualizacion del indice
VisualizacionIndiceEni visEni = new VisualizacionIndiceEni();
visEni.setNombreFormato("PDF");
byte[] valorBinario = "Visualizacin de expediente".getBytes();
visEni.setValorBinario(valorBinario);
expEni.setVisualizacionIndice(visEni);
//Conversion
expEni.storeToXML(out);
}
LIBRERAS CONVERS OR-ENI Y
ENIDOCWS
enidocws librera de intercambio de documentos entre
sistemas

La NTI de Documento electrnico define un formato XML de
intercambio contenedor del documento electrnico, sin embargo, no
define un protocolo de intercambio de documentos entre sistemas.

ENIDOCWS es una especificacin de servicios web basada en
teconologa REST para el intercambio de documentos electrnicos
entre sistemas.

Actualmente se definen dos servicios:
1)Solicitud a un repositorio de acceso a un documento a partir de su
CSV
2)Solicitud a unSERVICIO
repositorio deDOCUMENTO
ACCESO custodia de un nuevoCUSTODIA
SERVICIO documento.
DOCUMENTO
CLIENTE Accede a los documentos Solicita a un repositorio la
ENIDOCWS custoriados en un repositorio, custodia de un nuevo documento.
Ofrece a sistemas clientes el acceso Acepta la custodia de nuevos
SERVICIO
ENIDOCWS
de los documentos que custodia. documentos procedentes de los
sistemas clientes.
Una aplicacin o sistema puede desempear simultneamente

el rol de cliente y servicio E NIDOC WS .
Pg.-47-
ENIDOCWS
enidocws ejemplo servicio custodia C ompuls@
Los documentos electrnicos capturados en Compus@ se custodian en el
organismo al que pertenece el usuario que realiza la compulsa (copia papel
autntica de documento electrnico).
Pg.-48-
ENIDOCWS
enidocws Objeto P eticin de acceso a documento
El servicio ENDOCWS recibir un objeto Peticin de sus clientes (ejemplo HCV
como cliente)
NOMBRE DESCRIPCIN TIPO DATO CARCTER
peticion Objeto que representa la peticin realizada por la Peticion Obligatori
herramienta centralizada de verificacin. o
El tipo de objeto Peticion se compone de los siguientes parmetros:

idConsultado Cdigo seguro de verificacin vinculado al documento String Obligatori
consultado o
ip Identificador del host que realiza la peticin. String Obligatori

o
perfil Cadena con uno de los siguientes valores String Obligatori
1: Ciudadana o
2: Personal empleado pblico de la Junta de
Andaluca en el ejercicio de sus funciones
3: Otro personal empleado pblico en el ejercicio de
sus funciones
4: Repositorio o sistema de Consejera o entidad de la
Junta de Andaluca
motivo Motivo por el cual el usuario desea acceder al String Opcional
documento.
certEP Certificado de Empleado Pblico Certificado Opcional
Pg.-49-
ENIDOCWS
Detalle del objeto CertificadoEP:
cifEntidad CIF de la entidad String Obligatori
o
nif NIF del empleado String Obligatori
o
nombreApellidosRespons Nombre y apellidos String Obligatori
able o
tipoCertificado Tipo de certificado String Obligatori
o
entidadEmisora Nombre de la entidad emisora del String Obligatori
certificado o
datosSirhus Datos devueltos por el sistema SIRhUS DatosSirhus Opcional
Detalle del objeto CertificadoPF:

nif NIF de la persona String Obligatori
o
able o
o
entidadEmisora Nombre de la entidad emisora del String Obligatori
certificado o
datosSirhus Datos devueltos por el sistema SIRhUS DatosSirhus Opcional
Pg.-50-
ENIDOCWS
Detalle del objeto CertificadoPJ:
nif NIF de la persona String Obligatori
o
cifEntidad CIF de la entidad representada String Obligatori
o
nombreEntidad Nombre de la entidad representada String Obligatori
o
able o
Detalle del objeto DatosSirhus:
o
entidadEmisora
NOMBRE Nombre de la DESCRIPCIN
entidad emisora del String
TIPO DATO Obligatori
CARCTER
consejeria certificado
Nombre de la Consejera String oObligatori
o
organismoAutonomo Entidad a la que pertenece String Obligatori
o
centroDirectivo Centro directivo String Obligatori
o
puestoTrabajo Puesto de trabajo String Obligatori
o
provincia Provincia String Obligatori
La obtencin de datos del sistema SIRhUS a partir del NIF es "tolerante a fallos" o en el
sentido de que si no se obtiene
situacion Situacinrespuesta en un tiempo prudencial,String
o bien se obtiene una
Obligatori
respuesta errnea, se completar el objeto con los correspondientes campos vacos.o
Pg.-51-
ENIDOCWS
enidocws Objeto R espuesta de acceso a documento
El objeto de respuesta, denominado EniDoc, que deben devolver los
sistemas/repositorios tras la peticin de consulta por parte de la herramienta, es
el siguiente: CARCTE
NOMBRE DESCRIPCIN TIPO DATO
R
eniDoc Objeto que representa la respuesta a devolver por EniDoc Obligatori
los sistemas/repositorios o
El tipo de objeto EniDoc se compone de los siguientes parmetros:

CARCTE
NOMBRE DESCRIPCIN TIPO DATO
R
documentoE Documento ENI. Base64 del formato XML definido Base64 Obligator
NI en la NTI de Documento Electrnico. binario io
InformeFirma PDF contenedor de justificante de firma, en el que Base64 Opcional
se incluye el pie de firma. binario
textoLibre Texto libre de respuesta para ser mostrado al String Opcional

usuario final. Si este campo se completa por el
sistema/repositorio se mostrar al usuario nica y
exclusivamente dicho texto, ignorando el resto de la
informacin.
... [Parmetros adicionales Consultar ----- ----
documentacin tcnica]
Pg.-52-
ENIDOCWS
enidocws opciones para implementar servicio
enidocws
Para opciones
integrar en para implementar
un sistema/repositorio servicio
el componente EnidocWS, se ofrecen
dos alternativas:
A.Librera (archivo jar) para que sea integrada en el propio sistema/repositorio
que custodia la informacin. Para utilizar este mtodo de integracin se debe
tener en cuenta, como requisito tcnico, que el sistema/repositorio debe
ejecutarse sobre una JDK 6 o superior.
B.Aplicacin web (archivo war) que contiene la librera del punto anterior, para
que sea desplegada en un contendor web Tomcat con JDK 1.6.
Pg.-53-
ENIDOCWS
Opcin de integracin A Incorporacin librera enidocWS
Si se desea utilizar este mtodo de integracin hay que tener en cuenta, como
requisito tcnico, que el sistema/repositorio debe ejecutarse sobre una JDK 6 o
superior.
Pasos a seguir:
Para la integracin del componente ser necesario seguir los siguientes pasos:
1.Incluir las dependencias java en el classpath del sistema.
2.Definir el servlet del servicio en el fichero web.xml.
3.Establecer la configuracin adecuada en el fichero de propiedades
enidocWS.properties e incluirlo en el classpath del sistema.
4.Implementar la clase de recuperacin de la informacin requerida por la
herramienta centralizada.
Pg.-54-
ENIDOCWS
Opcin de integracin
Dependencias software: A Incorporacin librera enidocWS
Aplicaciones desarrolladas con Maven
El componente enidocWS puede ser incluido en aplicaciones desarrolladas
en maven aadiendo la siguiente dependencia al fichero pom.xml de la
aplicacin:
<dependency>
<groupId>es.juntadeandalucia.nti</groupId>
<artifactId>enidocWS</artifactId>
<version>X.X</version>
</dependency>
Del mismo modo es necesario incluir la referencia al repositorio de software

donde se encuentra el componente. Este componente puede encontrarse en
el Repositorio Maven del Servicio de Coordinacin de Administracin
Electrnica:
<repository>
<id>RepositorioMavenSCAE</id>
<name>Repositorio de la Junta de Andalucia</name>
<url>https://ws024.juntadeandalucia.es/maven/browse</url>
</repository>
Pg.-55-
ENIDOCWS
Opcin de integracin
Dependencias software: A Incorporacin librera enidocWS
Aplicaciones sin Maven
Son necesarias una serie de dependencias (ficheros jar) que deben estar en
el classpath de ejecucin de la librera principal para su correcto
funcionamiento. La librera que implementa el servicio se denomina
enidocWS-x.x.jar y las dependencias mencionadas son:
com.google.guava:guava:jar:14.0.1 org.glassfish.hk2.external:cglib:jar:2.2.0-
com.sun.xml.wsit:xmlsec:jar:1.1 b21
commons-lang:commons-lang:jar:2.3 org.glassfish.hk2.external:javax.inject:jar:2.
2.0-b21
commons-logging:commons-
logging:jar:1.1.1 org.glassfish.hk2:hk2-api:jar:2.2.0-b21
es.juntadeandalucia.nti:conversor- org.glassfish.hk2:hk2-locator:jar:2.2.0-b21
eni:jar:1.2.0 org.glassfish.hk2:hk2-utils:jar:2.2.0-b21
javax.annotation:javax.annotation- org.glassfish.hk2:osgi-resource-
api:jar:1.2 locator:jar:1.0.1
javax.servlet:javax.servlet-api:jar:3.1.0 org.glassfish.jersey.containers:jersey-
javax.validation:validation- container-servlet-core:jar:2.4.1
api:jar:1.1.0.Final org.glassfish.jersey.core:jersey-
javax.ws.rs:javax.ws.rs-api:jar:2.0 client:jar:2.4.1
javax.xml.stream:stax-api:jar:1.0-2 org.glassfish.jersey.core:jersey-
common:jar:2.4.1
log4j:log4j:jar:1.2.17
org.glassfish.jersey.core:jersey-
org.codehaus.castor:castor-core:jar:1.3.2
server:jar:2.4.1 Pg.-56-
ENIDOCWS
Opcinweb.xml:
Fichero de integracin A Incorporacin librera enidocWS
Es requisito indispensable para llevar a cabo la integracin que se defina el
siguiente servlet, como cualquier otro integrante de la aplicacin web cliente, en
el fichero web.xml.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns=http://java.sun.com/xml/ns/j2ee
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" >
<display-name>Web Service Enidoc</display-name>
<servlet>
<servlet-name>EnidocService</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.classnames</param-name>
<param-value>es.juntadeandalucia.nti.ws.eni.services.EnidocWS</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>EnidocService</servlet-name>
<url-pattern>/rest/eni/*</url-pattern>
</servlet-mapping>
</web-app>
Pg.-57-
ENIDOCWS
Opcindede
Fichero integracin
propiedades A Incorporacin librera enidocWS
enidocWS.properties
Para configurar el componente, tan slo hay que establecer las propiedades del
fichero enidocWS.properties e incluirlo en el classpath del sistema que lo
integra.
# Informacin de correspondencia entre la HCV y el repositorio/sistema integrado

# usuario dado de alta en la HCV
usuarioWS = usuario
# password del usuario dado de alta en la HCV
passwordWS = pass
# clase (indicando ruta del paquete separado por puntos .) donde se implementara el mtodo
claseWS = paquete.clase.MiClase
# nombre del mtodo que recibe como parmetro el objeto Peticion y devuelve Enidoc
metodoWS = nombreMetodo
Como alternativa de configuracin basada en fichero de propiedades, el

componente permite invocar interfaces definidas encargadas de obtener la
configuracin de la herramienta. Las implementaciones que puedan hacerse de
estas interfaces podrn rescatar la configuracin de bases de datos u otros
orgenes.
Pg.-58-
ENIDOCWS
Opcin
Clase de integracin
a invocar A Web
por el Servicio Incorporacin librera enidocWS
Es necesario realizar la implementacin de una clase que contenga un mtodo,
necesariamente esttico, con la siguiente especificacin:
public static EniDoc nombreMetodo (Peticion peticion)

Sobre este mtodo recae la responsabilidad de obtener el documento ENI del

sistema/repositorio integrado, as como el resto de informacin complementaria,
para devolver el objeto esperado a la herramienta centralizada de verificacin.
Siendo responsabilidad de los sistemas/repositorios el definir e implantar criterios
y polticas para la gestin de las peticiones de acceso, de manera que cada peticin
de acceso sea validada, teniendo en cuenta para ello la informacin que para
cada peticin se remite desde la herramienta. En caso de que se concluya que no
procede aportar el documento a la persona usuaria de la herramienta, en la
respuesta a generar por el sistema o repositorio se deber expresar un texto
informativo que se le mostrar a la misma.
Pg.-59-
ENIDOCWS
Opcin de integracin B Despliegue aplicacin enidocWS
En caso de que no sea posible realizar la integracin a travs de la librera debido a
incompatibilidades con las dependencias o al requisito de ejecutarse sobre una JDK
6 o superior, se pone a disposicin una aplicacin intermedia entre la herramienta
centralizada de verificacin y el sistema/repositorio, que ofrecer el servicio web de
comunicacin.
Para la correcta implantacin de la aplicacin, los pasos a seguir de forma anloga al
caso de integracin A son:
1.Establecer la configuracin adecuada en el fichero de propiedades
enidocWS.properties.
2.Implementar la clase de recuperacin de la informacin requerida por la
herramienta centralizada.
Para acceder al modelo de datos del sistema/repositorio, es posible que sea
necesario hacer uso de JDBC. Para ello habra que definir el DataSource
correspondiente en el fichero context.xml.
Una vez configurada la aplicacin e implementado el cdigo necesario, se debe
generar el war de la aplicacin y desplegarlo en un servidor de aplicaciones Tomcat
con JDK 1.6.
Pg.-60-
ENIDOCWS
E jemplo implementacin mtodo a invocar por reflexin
A continuacin se muestra un ejemplo bsico de implementacin del mtodo de
recuperacin de la informacin requerida por la herramienta centralizada de
verificacin:
public static EniDoc nombreMetodo (Peticion peticion) {
// 1.- Crear el objeto EniDoc que debemos rellenar

EniDoc eniDoc = new EniDoc();
// 2.- TODO Tratamiento opcional de los datos de la Peticion para definir e implantar
criterios y polticas para la gestin de las peticiones de acceso al documento
String idConsultado = peticion.getIdConsultado();
// 3.- TODO Obtener documento de BBDD mediante el CSV consultado

byte[] documentoBytes = obtenerDocumentoENIPorId(csvConsultado);
// 4.- TODO Rellenar el objeto EniDoc

// 4.1 Cumplimentar el parmetro obligatorio.
Array de bytes que contiene el documento electrnico ENI.
eniDoc.setDocumentoENI(documentoBytes);
// 4.2 Cumplimentar los parmetros opcionales.

// Campo que recoge expresamente, en el caso de firma electrnica basada en certificado, si
// en su momento se validaron los certificados electrnicos utilizados para la firma.
boolean validacionCertificadosFirma = true;
eniDoc.setValidacionCertificadosFirma(validacionCertificadosFirma);
// Campo que indica si se desea habilitar que la persona usuaria de la herramienta pueda
// descargar el correspondiente fichero de firma electrnica y el fichero en formato ENI.
boolean descargarFirmaydocumentoENI = true;
eniDoc.setDescargarFirmaydocumentoENI(descargarFirmaydocumentoENI);
// 5.- Devolver el objeto EniDoc relleno.

return eniDoc;
}
Pg.-61-
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
LA HERRAMIENTA CENTRALIZADA DE
VERIFICACIN
Finalidad de la HC V
Qu es la Herramienta Centralizada de Verificacin?

La Herramienta Centralizada de Verificacin (HCV) implementa un servicio para la
prctica de la verificacin, mediante un cdigo generado electrnicamente, de
documentos firmados electrnicamente en la Administracin de la Junta de
Andaluca, para el contraste de su autenticidad y la comprobacin de su integridad.
Cul es su objetivo?
El propsito de la herramienta centralizada de verificacin es:
Disponer de cara a la ciudadana de un nico punto que permita homogeneizar y

unificar la prctica de la verificacin de documentos en la Administracin de la Junta
de Andaluca.
Posibilitar el cese en el despliegue de nuevas implantaciones de herramientas locales

de verificacin.
Pg.-63-
VERIFICACIN
HC V: S istema nico de verificacin de documentos
La HCV es la nica herramienta que debe utilizarse para la prctica de la

verificacin, mediante un cdigo generado electrnicamente, de documentos
firmados electrnicamente en la Administracin de la Junta de Andaluca, para el
contraste de su autenticidad y la comprobacin de su integridad.
A partir del 31/03/2016 no se prestar soporte tcnico para otras herramientas con
propsito similar que puedan estar implantadas.
La herramienta Portafirmas ya no utiliza una implantacin especfica de una

herramienta de este tipo (Verifirma), y se integra con la HCV.
Pg.-64-
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA LA HERRAMIENTA CENTRALIZADA DE
VERIFICACIN
E squema de funcionamiento
Interfaz comn de comunicacin con los sistemas/repositorios a travs de la

operacin de acceso del protocolo ENIDOCWS.
Cdigos de verificacin con informacin que permita diferenciar el
sistema/repositorio que custodia el documento.
Integracin con el sistema SIRhUS de la Junta de Andaluca.
Pg.-65-
VERIFICACIN
Integracin con repositorios de documentos E NIDOC WS
La existencia de la herramienta centralizada de verificacin para cualquier
sistema/repositorio, hace necesario que para comunicarse con cualquiera de ellos,
interrogadas por un cdigo de verificacin, stos puedan facilitar la siguiente
informacin:
Pg.-66-
VERIFICACIN
C digos seguros de verificacin (C S V) de los documentos
El nuevo cdigo de verificacin aceptado por la herramienta centralizada de

verificacin ser una cadena de 30 caracteres de los cuales los 5 primeros sern
los del identificador nico del sistema/repositorio. Los 25 caracteres restantes
debern cumplir con los requisitos que ha de tener un cdigo seguro de
verificacin en cuanto a impredecibilidad, resistencia a colisiones, unicidad e
irreversibilidad. La documentacin tcnica de la HCV propone un algoritmo de
generacin de cdigos seguros de verificacin.
REPOSITORIO
CSV DENTRO DEL REPOSITORIO
Pg.-67-
VERIFICACIN
Metadato Identificador del documento electrnico
En aquellos casos en los que el repositorio/sistema que custodia el documento no
est en disposicin de asignar identificadores normalizados de documentos segn
lo dispuesto en la Norma Tcnica de Interoperabilidad de Documento Electrnico,
como por ejemplo en el mbito de las entidades no incorporadas al Directorio
Comn de Unidades Orgnicas, el metadato rgano deber adoptar el valor
XXXXXXXXX. Ante esta circunstancia, la HCV ocultar en la pantalla resultante
de una validacin el rea de metadatos.
Si se asigna un valor al metadato mnimo obligatorio Identificador del Documento
Electrnico deber cumplir con los requisitos definidos por la la NTI de
Documento Electrnico y, adicionalmente, los requisitos exigidos por la HCV.
<IDIOMA>_<RGANO>_<AAAA>_<ID_ESPECIFICO>
. Cdigo del idioma o lengua cooficial del documento:
<IDIOMA>
- ES: espaol
<RGANO> Siguiendo lo establecido en el Directorio Comn (DIR3)
<AAAA> Ao de la fecha de captura del documento
Cdigo alfanumrico que identifica de forma nica al documento dentro
de los generados por la administracin responsable. (Longitud: 30
caracteres)
Es indispensable que los 5 primeros caracteres sean el identificador nico
<ID_ESPECIFIC
del sistema/repositorio proporcionado por la HCV.
O>
Para el resto de caracteres, cada administracin puede disear el
proceso de generacin segn sus necesidades, asegurando en cualquier
caso su unicidad y que no coincidan con el valor del cdigo de
verificacin. Pg.-68-
VERIFICACIN
R oles de usuarios
El usuario puede autenticarse en la herramienta mediante certificado electrnico, pudindose el
mismo de persona fsica, persona jurdica o empleado pblico, o bien, mediante usuario y
contrasea de correo (LDAP) siempre que el acceso sea desde Red Corporativa de la Junta
de Andaluca.
Se determinan tres perfiles de acceso a la herramienta:
1. Personal empleado pblico de la Junta de Andaluca en el ejercicio de sus funciones.
2. Otro personal empleado pblico en el ejercicio de sus funciones.
3. Ciudadana.
La herramienta centralizada de verificacin determinar el perfil segn el tipo de acceso:
Certificado:
o Persona Fsica: el usuario podr seleccionar entre todos los perfiles disponibles
Ciudadana Personal empleado pblico de la Junta de Andaluca en el ejercicio de sus
funciones u Otro personal empleado pblico en el ejercicio de sus funciones.
o Persona Jurdica: se determinar por defecto el perfil de Ciudadana.
o Empleado Pblico: se determinar por defecto el perfil de Otro personal empleado pblico
en el ejercicio de sus funciones, en caso de que pertenezca a la Junta de Andaluca ser
entonces Personal empleado pblico de la Junta de Andaluca en el ejercicio de sus
funciones.
LDAP:
Pg.-69-
VERIFICACIN
Atencin a consulta de C S V
El usuario facilita el cdigo de verificacin del documento.

i. Se requerir al usuario que indique un motivo de acceso al documento
segn se haya configurado para cada perfil de acceso.
ii. Con la informacin anterior, la herramienta de verificacin invoca el
correspondiente servicio ENIDOCWS del sistema/repositorio candidato y
recupera el documento, firma e informacin complementaria.
iii. La herramienta de verificacin realizar la validacin de la firma
electrnica respecto de la fecha actual conforme a los criterios de la
Norma Tcnica de Interoperabilidad de Poltica de Firma Electrnica y de
certificados de la Administracin. Para esta validacin se utilizan los
actuales servicios DSS de integracin con la plataforma @firma.
Pg.-70-
VERIFICACIN
P antalla de consulta de C S V
Ejemplo de autenticacin y consulta mediante certificado electrnico de persona fsica.

Pg.-71-
VERIFICACIN
P antalla del resultado de la consulta
Pg.-72-
VERIFICACIN
Validador de firmas
Si se accede a la herramienta de verificacin desde la Red Corporativa de la Junta
de Andaluca se muestra la posibilidad de realizar validaciones de firma.
Se accede, por tanto, a la funcionalidad de validar firmas, mediante la cual se

podr validar un fichero de firma adjuntndolo en el formulario, en ocasiones es
posible que se precise el documento original, que tambin podr ser adjuntado de
forma anloga.
Pg.-73-
VERIFICACIN
Validador de firmas
Una vez incorporada la firma a validar, se comunica con @firma para comprobar
su validez y se obtiene una pantalla de resultado que muestra informacin
relevante de la propia firma, as como la posibilidad de descargar ficheros
asociados a la misma.
Pg.-74-
VERIFICACIN
E jemplo validacin firma certificado FNMT AC Usuarios
revocado
Pg.-75-
VERIFICACIN
E jemplo validacin firma certificado sello electrnico FNMT
Pg.-76-
VERIFICACIN
E jemplo validacin firma certificado AC C omponentes Inf.
FNMT
Pg.-77-
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA LA HERRAMIENTA CENTRALIZADA DE VERIFICACIN
Intermediador de acceso a documentos electrnicos
Las consultas que puede hacer un usuario de HCV
Pg.-78-
Las puede realizar tambin un sistema de tramitacin
Requiere el alta en HCV

del sistema cliente
Pg.-79-
Lgica de control de acceso del servicio ENIDOCWS ofrecido por HCV

Se bloquearn las consultas que contengan un objeto CertificadoPJ.

Se bloquearn las consultas cuyo perfil sea distinto de 2 (empleado JA) y 4
(repositorio o sistema)

Si perfil es 2:

Se bloquearn las peticiones que no contengan objeto CertificadoEP o
CertificadoPF

Si el repositorio ENIDOCWS candidato a la custodia del documento requiere
motivo de acceso, se bloquear la peticin si no se recibe un valor.

Si perfil es 4:

Se bloquearn las peticiones que contenga objeto CertificadoEP o CertificadoPF

El parmetro de entrada motivo deber estar presente.
ENIDOCWS invodado por HCV al repositorio de custodia

Se conserva el valor del parmetro perfil (2/4)

Si valor perfil es 2, se incorporar objeto DatosSirhus a la peticin.

Se incorporan parmetros DIR3 sistema origen de la peticin, si DIR3 es vigente,
identificador y nombre del sistema cliente Pg.-80-
Migracin de sistemas de verificacin anteriores a HC V
Qu ocurre con los informes de firma ya generados para sistemas distintos
a HCV?

Los informes de firma ya generados pueden haber sido impresos y estar guardados
en un cajn.

La URL del viejo sistema de verificacin debe permanecer activa. La migracin a
HCV debe implicar que el documento ya no pueda ser verificado.
Qu hacemos?
1) Implementar un nuevo servicio ENIDOCWS que permita el acceso a los documentos
del viejo sistema de verificacin.
2) Realizar el alta en HCV del servicio ENIDOCWS desarrollado.
3) Redireccin HTTP desde el sistema previo hacia HCV, facilitando como parmetro el
cdigo de repositorio asignado en el alta al repositorio ENIDOCWS.
Pg.-81-
Migracin de sistemas de verificacin anteriores a HC V
Redireccin HTTP:
Ejemplo Apache HTTP Server

RedirectMatch/sistemaX/validaDocumentos(.*)
https://ws050.juntadeandalucia.es/verificarFirma/rep/ABCDE
Pg.-82-
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
HERRAMIENTA PARA LA VALIDACIN Y VERIFICACIN
DE DOCUMENTOS Y EXPEDIENTES ELECTRNICOS
Introduccin
i. Accesible solo desde RCJA.

RCJA
ii. Acceso autenticado. Auditora completa de uso.
iii. Uso exclusivo para la verificacin/formacin de
documentos/expedientes electrnicos vinculados a la
tramitacin administrativa de la Junta de Andaluca o
remitidos desde esta administracin.
iv. No se custodian los documentos ni los expedientes
generados o verificados.
v. La utilidad de formacin de documentos/expedientes se
emplear solo cuando se carezca de un repositorio de
documentos administrativos y/o sistema/herramienta de
tramitacin de expedientes adaptados a las directrices
tcnicas impuestas por el ENI.
Verificacin de documentos y expedientes
Es necesario adjuntar el fichero XML contenedor

del documento o expediente a verificar.
R esultado de la verificacin de un documento electrnico
R esultado de la verificacin de un expediente electrnico
Formacin de documento electrnico E NI
Se emplear solo cuando se carezca de un repositorio de documentos

administrativos y/o sistema/herramienta de tramitacin de
expedientes adaptados a las directrices tcnicas impuestas por el ENI.
Formacin de expediente electrnico E NI
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
GENERACIN DE EXPEDIENTES ELECTRNICOS EN EL
MOTOR DE TRAMITACIN TREWA
Accesible desde la zona de administracin
En la herramienta de administracin de Trew@ existe una funcionalidad

para la exportacin e importacin de expedientes electrnicos en formato
ENI. Para un determinado procedimiento, existe la opcin de realizar
operaciones de este tipo:
Importar expediente: nos permite

importar expedientes en formato ENI.
Al pulsar este botn, aparecer un
asistente de ayuda para la
importacin de expedientes
electrnicos.
Exportar expediente: nos permite
exportar expedientes electrnicos
segn la normativa ENI. Al pulsar
este botn, se generar un fichero
.zip que contiene los XML del
expediente y sus documentos.
R esultado de la exportacin
Una vez exportado se obtiene un zip cuyo

contenido consiste en el fichero xml
correspondiente al expediente electrnico y una
estructura de carpetas (que se corresponde con
las fases por las que ha pasado el expediente) que
contiene los documentos adjuntos en cada fase de
tramitacin.
Firma electrnica del ndice del expediente exportado
Firma del ndice:

La firma electrnica del ndice se realiza con un
certificado de sello electrnico de actuacin
administrativa automatizada.
la Le y 39/2015
NDICE
tramitacin Trew@.
adecuacin al ENI.
PORT@FIRMAS : INTEGRACIN DE APLICACIONES Y
S ERVICIOS CON ADECUACIN AL ENI
Demo P ort@ firmas v4
Renovacin tecnolgica interface de usuario

Sin cambios en servicios web de integracin.
https://cancanaprun1.chap.junta-andalucia.es/pfirma-aefor/
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA S ERVICIOS CON ADECUACIN AL ENI
C reacin de peticiones de firma por referencia
En Port@firmas 2.X las aplicaciones remitentes de peticiones de firma invocaban los
servicios web de integracin de Port@firmas adjuntando el contenido binario de los
ficheros y anexos vinculados a la peticin de firma.
Con el envo por referencia, en lugar de remitir el contenido binario de los

documentos y anexos se enva su resumen HASH y su cdigo de verificacin dentro
del sistema origen remitente.
Exis te alg una dife re nc ia apre c iable para e l us uario firmante ?
Ninguna. El modo en el que la peticin fuera creada no implica ninguna diferencia

apreciable para el usuario final de la aplicacin.
Qu ve ntajas apo rta?

Port@firmas no realiza la custodia de los documentos de las aplicaciones. La
responsabilidad de la custodia de los documentos recae ntegramente en la
aplicacin/sistema/repositorio.
Los servicios web de alta de peticiones de firma no requieren el envo de ficheros, lo

cual implica un menor uso de los recursos de red y una disminucin de los
requerimientos de almacenamiento.
Adecuacin a la normativa vigente en materia de interoperabilidad, repositorios

electrnicos y custodia de documentos. Pg.-96-
C onfiguracin de la aplicacin remitente a P ort@ firmas
La aplicacin remitente podr estar habilitada para crear peticiones de firma con
envo de fichero o por referencia, siendo ambas posibilidades excluyentes entre
s.
Las aplicaciones que realizan peticiones de firma por referencia son responsables de
la custodia de sus propios documentos. Para cada aplicacin dada de alta para
el envo por referencia, es necesario configurar la siguiente informacin en
Port@firmas para que ste pueda acceder a los documentos cuando sea
necesario:
URL servicio ENIDOCWS ofrecido por el sistema remitente.
Usuario y clave de autenticacin ante el repositorio ENIDOCWS
El servicio ENIDOCWS del sistema es el mismo para

Port@firmas y la Herramienta Centralizada de
Verificacin.
Pg.-97-
Diferencias en el proceso de creacin de peticin de firma
En Port@firmas, las aplicaciones remitentes de peticiones de firma hasta ahora
invocaban los servicios web de integracin adjuntando el contenido binario de los
documentos y anexos vinculados a la solicitud de firma. Con el envo por referencia,
en lugar de enviar el contenido binario se enva el resumen HASH y el cdigo de
verificacin que los identifica en el sistema remitente.
Pg.-98-
Diferencias en el proceso de firma/rechazo de la peticin
Durante los procesos de firma electrnica de documentos la nica diferencia
existente entre ambos sistemas de creacin de peticiones reside en determinar
cmo Port@firmas acceder a los documentos a firmar.
Envo clsico con envo de fichero: Port@firmas rescata el documento de su propio

modelo de datos donde custodi el documento en el momento de aceptar la
peticin de firma.
Envo por referencia: Port@firmas rescata el documento desde el servicio

ENIDOCWS del sistema remitente, solo cuando es estrictamente necesario, a partir
del cdigo que se indic en la peticin de firma por referencia.
Cundo re s c ata Po rt@firmas lo s do c ume nto s de s de e l s is te ma
o rig e n? el usuario firmante quiere acceder a su contenido previamente o
Cuado
posteriormente a su firma.
Al generar los informes de firma.

Pue de n firmars e lo s do c ume nto s s in que Po rt@firmas lo s re s c ate
de s de e l s is te ma o rig e n?
S. Cuando los usuarios realizan firmas masivas de peticiones, Port@firmas no
requiere acceder al sistema ENIDOCWS de la aplicacin remitente ya que en el
momento de la peticin, junto a los cdigos de los documentos se adjunt su
resumen HASH que es lo que efectivamente se cifra con el cliente de firma
electrnica. Pg.-99-
CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA PORT@FIRMAS : INTEGRACIN DE APLICACIONES Y
Diferencias en la firma masiva de documentos
En el sistema de envo por ficheros, Port@firmas debe calcular el resumen HASH
de los documentos recibidos. En la firma por referencia, este clculo no es
necesario ya que en la peticin de firma han de incluirse los resumen HASH, cuyo
clculo pasa a ser responsabilidad de la aplicacin remitente.
Pg.-100-
Diferencias en la firma individual de una peticin
En la firma por referencia, Port@firmas deber rescatar el documento del servicio
ENIDOCWS ofrecido por la custodia del sistema remitente.
Pg.-101-
Diferencias en el acceso al informe de firma
Para generar un informe de firma, en la firma por referencia, Port@firmas deber
rescatar el documento del servicio ENIDOCWS ofrecido por la custodia del
sistema remitente.
Pg.-102-
Verificacin de los documentos firmados
Los documentos firmados se verifican en la Herramienta Centralizada de
Verificacin (HCV)
D nde re s c ata la HCV lo s do c ume nto s e n lo s pro c e s o s de
ve rific ac i n?
CON ENVO DE FICHERO HCV accede al servicio ENIDOCWS ofrecido por Port@firmas
HCV accede al servicio ENIDOCWS ofrecido por el sistema

remitente. Port@firmas no interviene en los procesos de
verificacin de documentos.
PETICIN POR
REFERENCIA Es necesario que el sistema remitente mantenga actualizada en
su modelo de datos la relacin de firmas efectuadas sobre el
documento, incluyendo las realizadas en Port@firmas que por
tanto deber rescatar cuando se produzcan.
Qui n as ig na lo s me tadato s y e l c dig o de ve rific ac i n a lo s

do c ume nto s ?
CON ENVO DE FICHERO Port@firmas, estableciendo valores calculados por defecto
El sistema remitente. La unidad de intercambio de informacin

PETICIN POR con Port@firmas es el documento electrnico ENIDOC, la cual
REFERENCIA incorpora ya los metadatos establecidos en el sistema
remitente.
Pg.-103-
Verificacin de documentos firmados
Pg.-104-
Migracin de aplicaciones que an envan contenido de ficheros
Para una aplicacin dada de alta en Port@firmas, los sistemas de envo
mediante fichero o por referencia son excluyentes.
Una vez que una aplicacin dada de alta en Port@firmas tiene creada alguna
peticin, no es posible modificar el modo de envo de peticiones. Por tanto, para
migrar las aplicaciones hacia el envo por referencia, se debe solicitar una nueva
alta en Port@firmas mediante el modo de envo por referencia. La aplicacin
deber gestionar su relacin con Port@firmas discriminando las peticiones
antiguas (con envo de fichero) de las nuevas (por referencia).
La aplicacin a migrar, al igual que cualquier sistema que se integre mediante el

envo por referencia, habr de implementar un servicio ENIDOCWS que ser
consumido por Port@firmas para rescatar los documentos que custodia cuando
sea necesario. Este servicio ENIDOCWS a desarrollar podr ser reutilizado en la
integracin con la Herramienta Centralizada de Verificacin.
La aplicacin remitente deber adaptarse a la NTI de Documento Electrnico,

manteniendo en su modelo de datos un vnculo entre archivos, firmas y
metadatos. Adicionalmente, deber mantener una relacin entre cdigos de
Pg.-105-
C onsideraciones implantacin P ort@ firmas C HAP
Alta de aplicaciones: La creacin de peticiones de firma se realizar aportando
por referencia la relacin de documentos.
Las actuales aplicaciones usuarias debern adaptarse para crear peticiones

aportando por referencia la relacin de documentos.
La aplicacin o el rgano responsable de la misma deber informar a las

personas a las cuales se remitirn peticiones que deben especificar, en su
configuracin particular (apartado "Configuracin", "Datos de contacto") su
direccin de correo electrnico corporativo y activar la opcin Notificar.
Para cada aplicacin usuaria se debe establecer una poltica de gestin de sus
peticiones, en particular para aquellas pendientes durante periodos prolongados
de tiempo por parte de las personas destinatarias.
Los lunes a primera hora se remite automticamente un correo de aviso a

aquellos usuarios que tienen en su bandeja de entrada alguna peticin pendiente
de firma
Pg.-106-

Curso Iaap I17f-Ps23

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curso Iaap I17f-Ps23

Uploaded by

Copyright:

Available Formats

CONS EJERA DE HACIENDA Y ADMINIS TRACIN PBLICA

Instituto Andaluz de Administracin Pblica

Capacidad de los sistemas de informacin y

El Esquema Nacional de Interoperabilidad comprende[r] el

Desarrollo normativo ENI: R.D. 4/2010, de 8 de enero,

El Directorio Comn es un inventario unificado

Registro con la informacin de los

Inventario de procedimientos y servicios de las

Elemento nuclear en el Esquema es la creacin de

TF02 - XAdES internally detached signature.

Firma CSV (Requiere de Orden/Resolucin o documento que

10 SI TIPO DE FIRMA = 'CSV'..

10 IDENTIFICADOR DE DOCUMENTO ORIGEN

Atendern a necesidades de descripcin

Como formato de intercambio del documento electrnico la NTI de Documento

Los sistemas de informacin deben custodiar internamente la informacin en este

No necesariamente. En el Esquema Nacional de Interoperabilidad no se

Los metadatos se firman?

No. La firma solo se realiza sobre el contenido.

Cuando se asignan los metadatos?

En el momento de generacin/captura del documento. Solo se prev la posible modificacin de valores

El esquema XML permite el uso de cofirmas y contrafirmas?

S. El XSD define una cardinalidad 0..N para las firmas electrnicas.

Cmo se intercambian los metadatos complementarios?

El XSD no lo permite. De existir, deben enviarse externamente al fichero XML ENIDOC,

Datos de cada documento:

Como formatos de firma se admiten:

4 FECHA DE CAPTURA DEL

Se podrn asignar metadatos complementarios

Como formato de intercambio del expediente electrnico la NTI de Expediente Electrnico

No necesariamente. Los requisitos de la Norma Tcnica de Interoperabilidad de Expediente

El mdulo de conversin, consistente en una librera, permite realizar las

La librera permite realizar las funcionalidades relativas a la construccin del XML a

Protocolo basado en REST para el de intercambio de documentos electrnicos entre

1.Acceso: un sistema cliente solicita a un repositorio de documentos electrnicos el

2.Solicitud de custodia: un sistema cliente solicita a un repositorio de documentos

* Mtodo para generar un expediente electrnico

public void escribirExpedienteElectronico(ByteArrayOutputStream out)

// Nuevo expediente electrnico

ExpedienteEni expEni = new ExpedienteEni();

//Metadatos del expediente

List<String> ints = new ArrayList<String>();

List<String> orgs = new ArrayList<String>();

//Indice del expediente

IndiceExpedienteEni indiceExpediente = new IndiceExpedienteEni();

List<DocumentoIndice> documentosIndice = new ArrayList<DocumentoIndice>();

DocumentoIndice docInd = new DocumentoIndice();

List<FirmaEni> firmas = new ArrayList<FirmaEni>();

FirmaEni firma = new FirmaEni();

CsvEni CSV = new CsvEni();

//Visualizacion del indice

VisualizacionIndiceEni visEni = new VisualizacionIndiceEni();

byte[] valorBinario = "Visualizacin de expediente".getBytes();

Una aplicacin o sistema puede desempear simultneamente

El tipo de objeto Peticion se compone de los siguientes parmetros:

ip Identificador del host que realiza la peticin. String Obligatori

NOMBRE DESCRIPCIN TIPO DATO CARCTER

El tipo de objeto EniDoc se compone de los siguientes parmetros:

textoLibre Texto libre de respuesta para ser mostrado al String Opcional

Del mismo modo es necesario incluir la referencia al repositorio de software

# Informacin de correspondencia entre la HCV y el repositorio/sistema integrado

Como alternativa de configuracin basada en fichero de propiedades, el

public static EniDoc nombreMetodo (Peticion peticion)