source: libros/maquetacion/capitulo6/capitulo6.tex @ 6e29135

%\chapter{Firmas Electr\'onicas}
\chapter{Propuesta de acoplamiento de la firma electr\'onica avanzada en procesos de negocio}


\chapterauthors{V. Bravo y A. Araujo
\chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres}
}
\label{capitulo6}

% Se crea un ambiente bibunit para el cual se creará la bibliografía
\begin{bibunit}[unsrt]
 



%A continuación el contenido del artículo de componente de firmas electrónicas

%\begin{abstract}
Automation is use the information technologies as a direct method for improvement. However, there are elements such as handwritten signature that
have been taken of all the digital area, but which, when recurrent events in organizational processes
stand as a critical factor in the flow of operations.
In response to this situation have developed numerous standards and technologies grouped by
Electronic Signature concepts and PKI, but that in turn have discovered new questions in this field, among them,
those that have to do with the integration processes.
In this paper we propose a software component and a method for connecting
computer systems as essential technology using the Advanced Electronic Signature. In this sense
addresses the document formats, validation infrastructure,
and safety conditions that ensure legal support. The work has
center, the details and problems of integration, and that have been grouped under ``coupling joint`` concept.
%\end{abstract}
%\begin{keywords} Advanced Electronic Signatures, Component, XAdES, PKI, workflow. 
%\end{keywords}





\section{Introducción}
\label{sec:intro}
La adopción de la tecnología de firma electrónica aún no está suficientemente extendida. Esta 
se utiliza en distintas áreas y en muchas  instituciones o empresas alrededor del mundo pero no ha llegado a ser 
equivalente a la firma autógrafa en un sentido amplio. Vinculado a este hecho, surge la pregunta ¿Pueden converger
estas dos tecnologías en un futuro próximo?. Con la finalidad de responder esta interrogante, 
se puede decir que la firma electrónica  debe tener  por lo menos tres  características comunes 
a la autógrafa: identificar a la persona que la realiza; declarar la asunción u obligatoriedad de cumplimiento (contrato) 
del contenido de lo que se firma y por último, servir  como prueba de autenticidad o no repudio del firmante. 
El modelo de firma electrónica basado en una infraestructura de clave pública (PKI por sus siglas en inglés), ha sido jurídicamente aceptado en muchos países,
lo que equivale a decir que en estos casos se cumple con las características antes mencionadas. 


La firma manuscrita se percibe como un elemento tecnológico desacoplado, esto es, no dependiente de otra tecnología o factor (solo 
se necesita papel y lápiz)  que
puede usarse casi en cualquier lugar y con aceptación universal. En cambio la firma electrónica requiere de elementos de software
(manejadores de dispositivos, clientes de firma, etc) y hardware (lector de tarjetas, tarjeta inteligente, computador, tableta o móvil), 
adicionalmente  y por lo general se debe contar con una conexión a internet para la validación. Otra ventaja importante
de la firma manuscrita es la permanencia de factores biométricos que son fundamentales en la realización
de auditorías confiables. A pesar de todas  estas ventajas, en los últimos años ha crecido el uso de la firma electrónica, 
Gobiernos nacionales y locales de España \cite{IEEEhowto:espana}, Alemania \cite{IEEEhowto:eID} y Estonia \cite{IEEEhowto:estonia} tienen disponibles plataformas para sus ciudadanos, y la popularización de la tarjeta
inteligente (smartcard) como elemento de identificación personal ha apoyado este crecimiento. 

En este punto se plantean nuevos  problemas vinculados al hecho de introducir o  sustituir el elemento físico o autógrafo 
por el elemento electrónico,
entre estos podemos señalar:  elección del formato 
o formatos de archivo de los documentos firmados; ubicuidad y ergonomía de la acción de firma; verificación de los documentos
firmados; histórico o archivo de documentos firmados y finalmente la  integración de la firma con sistemas de base de datos relacionales, mapeos 
objetos-relacionales, servicios web, entre otros elementos utilizados en sistemas informáticos actuales. 

En este sentido, este trabajo  plantea un método para integrar un componente \cite{IEEEhowto:software}  de Firma Electrónica Avanzada   denominado 
ComponenteFEA a procesos de negocio, teniendo presente parámetros de seguridad, rapidez y auditabilidad. 



\section{El modelo actual de Firma Electrónica}
\label{sec:modelo}

Una de las acciones  para dar soporte jurídico a la firma electrónica y lograr su equivalencia con la firma manuscrita es
fijar unas condiciones iniciales que garanticen integridad y auditabilidad de los documentos firmados, y que
puedan ser validadados a través de un estándar. Bajo este enfoque, se ha creado el concepto de Firma Electrónica Avanzada,
que por definición debe contar con las siguientes propiedades  a) estar vinculada al firmante de  manera única; b) permitir la identificación del firmante; 
c) haber sido creada
utilizando medios que el firmante puede mantener bajo su exclusivo control y d) estar vinculada a los datos a que se refiere
de modo que cualquier cambio ulterior de los mismos sea detectable.  La formalización de esta idea  ha sido llevado a cabo principalmente 
por el Parlamento Europeo,
y se describe en la directiva  1999/93/EC \cite{IEEEhowto:directiva}.

Existen dos grandes dominios tecnológicos para el uso de la Firma Electrónica Avanzada:  uno es el que tiene que ver con los procesos de
identificación, registro, emisión  y validación de certificados electrónicos. De este dominio se ocupan  
las organizaciones que están bajo el esquema PKI, que funcionan como terceros de confianza. Cada certificado brinda identidad
a una persona o empresa en la Internet, y se le otorga al ente bajo la aceptación de un contrato que especifica condiciones de uso. El certificado
es un documento -un archivo-
que autentifica la clave vinculada al ente. La clave secreta/privada se distribuye en una tarjeta inteligente 
o token criptográfico que funciona como un elemento de control de
acceso de nivel 2. Los certificados electrónicos contienen información especificada  bajo el formato X.509 versión 3 \cite{IEEEhowto:x509}, el cual
incluye campos como  fecha de expedición y vencimiento del certificado, Nombre único del propietario (conocido como Nombre Común),
datos del Proveedor del certificado, datos criptográficos del certificado y datos del servidor de validación
que utiliza el protocolo de estado de certificados en línea (OCSP por sus siglas en inglés). 


El segundo dominio corresponde a las  aplicaciones que usa el propietario del certificado para aplicar 
la firma electrónica, y que generan valor agregado. Las aplicaciones de este tipo más utilizadas  cuentan con
una interfaz basada en bibliotecas dinámicas (.dll o .so) para este fin, así como también tienen un archivo de certificados
de autoridades de certificación para validar la vigencia y correctitud del certificado del firmante. Esta interfaz
es básica, solo permite generar un archivo de firma en formato PKCS\#7 \cite{IEEEhowto:pkcs7} separado del documento firmado, lo que conlleva
a que las tareas de almacenamiento, validación y auditoría  deben ser provistas  adicionalmente a través de un programa
o complemento de software. Las aplicaciones de este tipo más utilizadas son navegadores web y clientes de correo electrónico.

Por otro lado, se han especificado diferentes formatos estándares de archivo con firma autocontenida. Por ejemplo el formato PDF 
dada sus características de solo lectura y visualización en pantalla como documento impreso es uno de los más utilizados 
para este fin. El estándar PADES \cite{IEEEhowto:pades} basado en PDF es un ejemplo de ello, también existe el formato PDF nativo, y que es 
verificable por los visores más populares como el de \textit{Adobe Reader}\copyright. 

También existen estándares para archivos con firma electrónica basados en XML. La ventaja de estos
formatos es que pueden integrar  metadatos como la fecha y lugar de la(s) firma(s), y permiten
incluir diferentes tipos de archivos  como fotos, videos, documentos de texto u ofimáticos. Entre los estándares XML más conocidos está el 
XMLDsig \cite{IEEEhowto:xmldsig}. 
Esta estándar cuenta con diferentes implementaciones y extensiones, entre ellas el formato creado por las repúblicas bálticas
llamado BDOC \cite{IEEEhowto:bdoc}, que sigue a su vez el popular estándar OpenDocument, utilizado por el paquete ofimático OpenOffice como formato
principal para sus archivos.





\section{Antecedentes}

La inclusión de la firma electrónica en un proceso de negocio tiene varios aspectos asociados. Se 
pueden señalar como los más relevantes la ergonomía
de la firma (facilidad de uso), los formatos y visualización de documentos, la integración con plataformas de software y la arquitectura de la solución.


En relación con el  tema de la ergonomía   Xyzmo SIGNificant\footnote{Para ver información completa
sobre Xyzmo Significant visitar la dirección web: http://www.xyzmo.com} es una novedosa propuesta. Xyzmo es una una aplicación comercial
de código fuente propietario, que introduce elementos innovadores en el área de ergonomía y adaptación al cambio:
no obliga a aprender una nueva técnica de firma sino que ofrece a los usuarios de esta tecnología el uso la firma
manuscrita a través de una tableta electrónica o teléfono con interfaz multitoque (multitouch) bajo sistemas operativos
Android\copyright \hspace{0.2cm}y iOS\copyright, esto sin desvincularse del esquema PKI. Este modelo proporciona al usuario la metáfora de 
la firma manuscrita mostrando el documento tal cual como si fuese impreso, habilitando la firma electrónica avanzada  a través del 
uso  de los  dedos o de un lápiz para pantalla táctiles. Para el proceso de validación se utilizan parámetros biométricos tales
como ritmo, velocidad o características del trazo, y  también técnicas criptográficas estandarizas vinculadas
al esquema PKI.

Existen diferentes implementaciones  de software para las  gestión y visualización de los
dos tipos de formatos  principales: PDF y XML. Para el caso del formato  PDF la visualización está automáticamente disponible ya que existen numerosos lectores
para este tipo de archivo, por ejemplo, el Adobe Reader\copyright \hspace{0.2cm} visualiza la firma electrónica o digital como un sello (imagen) dentro del documento,
 y muestra también su contenido con características de  forma (encabezado, líneas, tablas, logos, etc.) que pueden ser parte o no del documento firmado,
pero que en muchos casos son necesarias para la elaboración de documentos formales o legales.
En el caso de los formatos XML la visualización no es automática, por lo tanto si se requiere visualizar
el contenido con elementos de forma se debe disponer de un software visualizador que formatee el contenido. En \cite{IEEEhowto:neubauer} se muestra una propuesta
para documentos XML que necesitan por disposiciones legales o formales de gobierno aplicar forma a documentos
firmados electrónicamente.

Una de las potencialidades de la firma electrónica es su integración con sistemas informáticos para la 
mejora de procesos mediante la eliminación de puntos lentos. Es por ello que los temas
de integración y arquitectura juegan un papel preponderante. En esta tendencia se inscribe el proyecto \textit{@firma}: 
una solución desarrollada por el Ministerio de Hacienda y Administraciones Públicas de España,
 que se plantea como una plataforma de firma electrónica orientada a brindar servicios de gobierno electrónico, y que está integrada
con el sistema de identificación Español. Cuenta con
una aplicación de escritorio que puede usarse en diversos sistemas operativos, y un \textit{applet} \cite{IEEEhowto:java}  para usar la firma
a través de la web. Estas características habilitan a \textit{@firma} para el desarrollo de aplicaciones de gobierno
electrónico, así como también para la integración con sistemas empresariales.



\section{Acoplamiento de la Firma Electrónica Avanzada}



La conexión entre un  componente (software) y el sistema informático se denomina acoplamiento. Este procedimiento debe cumplir con un
conjunto de requisitos que tienen que ver con  características
tales como reutilización, cohesión y la exportación de una interfaz definida. 
A continuación se describen los elementos desarrollados en este trabajo.


\subsection{Componente de Firma Electrónica Avanzada}

Se desarrolló un componente que permite realizar diferentes operaciones
asociadas con la firma electrónica: subir un documento desde el computador cliente;
realizar la firma utilizando una tarjeta inteligente con PIN (contraseña) desde el computador cliente y
entregar un archivo firmado en formato XAdES\cite{IEEEhowto:xades}  al programa servidor. El componente se ha denominado
de Firma Electrónica Avanzada (ComponenteFEA), ya que cumple con las condiciones citadas  en la sección \ref{sec:modelo}  sobre este tipo
de firma.


Las funcionalidades que implementa el ComponenteFEA son las siguientes:
\begin{enumerate}
 \item Firmar electrónicamente (para este caso se asume que lo electrónico está asociado un dispositivo en hardware como una tarjeta inteligente, y
 en relación a ello debe connotar vinculación jurídica, lo digital solo a una clave en software) un documento de tipo de archivo definido por especificación MIME \cite{IEEEhowto:mime}. 
\item Firmar digitalmente  
(usando un archivo PKCS\#12 \cite{IEEEhowto:pkcs12}) un documento de tipo de
archivo definido por especificación MIME .
\item Verificar un archivo firmado electrónicamente  usando o no validación OCSP.
\item  Verificar un archivo firmado digitalmente  usando o no validación OCSP.
\item Mostrar propiedades como algoritmos utilizados, fecha y lugar de la firma de un archivo firmado 
 \item Firmar electrónicamente utilizando un componente para el navegador  un documento de tipo de archivo definido por 
especificación MIME.
\end{enumerate}
 

\begin{verbatim}

class BDocDocument : QObject {
// *** Métodos para firma electrónica
    BDocDocument();
    void init();
    void create( const QString file );
    bool openBDocContainer(const QString path);
    void saveBDocContainer(const QString path);      
    bool signWithP12(const QString  profile,...);
    void addDocument(const QString path);

// ** Mètodos de firma por navegador web
    bool presignWeb(const QString  profile, ...);
    bool postsignWeb(const QString  profile, ...);


// ** Métodos para validación
    QString signatureAlgorithm(int index );
    bool validateOffline() const ;

// ** Métodos para Gestión de archivos
    QString signatureFormat(int index );
    QString signatureDateTime(int index );
    QStringList signatureLocation(int index );
    QString signatureRol(int index );
    QString signatureDigestMethod(index )
    QString subjectCertificateCommonName(int i);
    QString documentName(int docId);
    int documentCount();
    int signatureCount();
    void saveDocument(int docId...);


}
\end{verbatim}
\begin{center} \textbf{Listado 1.} API del ComponenteFEA en C++ accesible desde \textit{python}
\end{center}

Bajo esta perspectiva  se propone tratar las funcionalidades 
asociadas a la Firma Electrónica Avanzada, es decir, empaquetar las funcionalidades exportando una interfaz de programación de aplicaciones (API por su siglas en inglés) 
que puede ser utilizada de forma  encapsulada y separada por una aplicación anfitrión,
escrita teóricamente en cualquier lenguaje de programación. 
Uno de las aplicaciones que trabaja bajo este esquema de complementos o componentes es el navegador web, este  diseño ha permitido 
contar con grandes repositorios que extienden las funcionalidades del navegador casi para cualquier uso.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/uml.png}
\includegraphics[scale=1]{imagenes/uml.jpeg}
\caption{Diagrama UML de acoplamiento}
\label{fig:uml}
\end{figure}

La figura \ref{fig:uml} muestra un diagrama en lenguaje UML del componente y su conexión con un sistema
informático. Existen tres tipos de funcionalidades que exporta el ComponenteFEA: ''Firmar'', interfaces para firma electrónica y digital, 
''Validar``, interfaces para validación fuera de línea y en línea de certificados electrónicos, y ''Gestionar``, interfaces para la almacenamiento
y búsqueda de archivos firmados.


A nivel de lenguaje de programación se provee un paquete o \textit{package} para \textit{python} que está construido envolviendo
 una librería de firma electrónica avanzada escrita en lenguaje \textit{C/C++}.
El listado \textbf{1}  muestra los métodos que son accesibles desde \textit{python}.



\subsection{Método de conexíón}


El diagrama de flujo de la figura \ref{fig:acoplamiento} muestra los pasos a seguir para incorporar el ComponenteFEA
 dentro de un proceso de una organización.  Los primeros dos pasos de este diagrama  corresponden a la  
identificación de  los puntos de firma y validación dentro del proceso de negocio, 
para luego conectar los métodos (mensajes)  correspondientes del ComponenteFEA  en dichos puntos. 



\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/flujoComponenteFE.jpg}
\includegraphics[scale=1]{imagenes/flujoComponente.jpeg}
\caption{Diagrama de flujo para el acoplamiento del ComponenteFEA}
\label{fig:acoplamiento}
\end{figure}


En un siguiente paso y dependiendo del tipo de proceso a automatizar se adoptará un esquema de conexión para el
servidor.  En esta fase se establecen algunos aspectos importantes relativos al sistema
informático a colocar en funcionamiento, entre estos están la existencia de un sistema automatizado, 
el tipo de lenguaje de programación y sistemas operativos a utilizar, el soporte de la PKI, la asignación de las tarjetas inteligentes, entre otros.


En este punto el desarrollador tiene la libertad 
de utilizar el componente de firma
según su criterio, sin embargo, puede seguir algunas pautas  relacionadas con el  proceso a automatizar.  Si el proceso no se encuentra automatizado se recomienda 
seleccionar para el desarrollo de software el lenguaje
\textit{python}.  Para el caso anterior o si el sistema se implementó utilizando este lenguaje se sigue el paso 7.1 de la figura \ref{fig:acoplamiento} que 
corresponde
con la instalación del componente ''servidor`` para la Firma Electrónica Avanzada.


En el caso de que los procesos de negocio se encuentren automatizados bajo un lenguaje
diferente a \textit{python}, se utilizan la interfaz de  servicios web\footnote{La interfaz de servicios web 
está disponible en: http://bazaar.launchpad.net/\~esignature/esignature/bdoc/files/head:/server/} que provee del ComponenteFEA (Paso 8.1 de la figura \ref{fig:acoplamiento}).



Un tema a tomar en cuenta es el relativo al tipo de repositorio donde se almacenan los archivos firmados. El ComponenteFEA genera archivos tipo XAdES con extensión
\textit{.bdoc}. Para este fin puede utilizarse un directorio en el sistema de archivos o un gestor de  base de datos relacional. En este
punto también hay que trabajar sobre el nombramiento, es decir la forma como se  identifican unívocamente los archivos para que puedan ser encontrados. Para ello  se puede utilizar la vinculación de 
metadatos en los registros de las tablas de la base de datos relacional, o simplemente
asignar un nombre como clave única a los archivos firmados.




Como último paso se debe habilitar un módulo para gestionar los archivos firmados (paso 9 de la figura \ref{fig:acoplamiento}), es decir, 
proveer una interfaz de usuario para las acciones
 de visualización de propiedades de  archivos, validación
de firmas electrónica, búsqueda, entre otras. Estas funcionalidades las provee el ComponenteFEA 
mediante los métodos que se nombran en la sección 
''Métodos para Gestión de archivos`` del Listado \textbf{1},
y pueden ser extendidas utilizando algunas de las funcionalidades del gestor de datos que se utilice.


\section{Casos de estudio}

A continuación se muestran tres casos de integración utilizando un mismo proceso con diversos sistemas informáticos.
El proceso tratado es el conocido como ''Orden de compra``, el cuál está presente en muchas organizaciones.
Consiste en realizar un proceso de negocio con la finalidad de  obtener un conjunto de productos o servicios necesarios para la organización a través de una búsqueda y evaluación de
un cierto número de cotizaciones y que siguen una serie de criterios, como por ejemplo, las características de calidad y precio. El proceso en pasos
se puede describir así:
\begin{enumerate}
 \item Generar una requisición o documento de solicitud para el conjunto de productos o servicios
\begin{itemize}
 \item Firma del solicitante
\end{itemize}
 \item Obtener por los menos n  $(n\geq2)$  cotizaciones para el conjunto de productos o servicios
\item Seleccionar una cotización y generar un acta 
\begin{itemize}
 \item Firma del analista de compras
\end{itemize}
\item Generar una orden de compra 
\begin{itemize}
 \item Firma del gerente del departamento
\end{itemize}
\end{enumerate}

Generalmente este proceso se lleva a cabo utilizando firmas manuscritas en coordinación con un sistema informático: 
se imprime desde el sistema el documento (requisición, acta u  orden de compra), se firma, y luego se actualiza la información en el sistema informático.

Para el caso de estudio planteado se  puede sustituir  la primera, la segunda  o las tres  firmas manuscritas por sus respectivas firmas electrónicas. 
También es posible agregar firmas electrónicas en puntos donde no existen firmas manuscritas.

La segunda funcionalidad a conectar del ComponenteFEA es la validación de los documentos firmados electrónicamente.
 Para ello se identifican los puntos donde se actualiza la información
sobre la firma manuscrita. Una tercera funcionalidad es la que tiene que ver con la visualización de  los atributos  de los documentos firmados electrónicamente. 

Después del proceso de identificación, para  cada punto que se determinó en la fase anterior,  se incorporan  los métodos
del ComponenteFEA con llamadas locales o remotas  según sea el caso. A continuación se presenta tres  implementaciones del proceso 
''Orden de compra`` para tres sistemas informáticos diferentes. 


\subsection{Caso OpenERP }

OpenERP\footnote{Ver la dirección web: http://www.openerp.com} es un software de Planificación de Recursos Empresariales (ERP, por sus siglas en inglés), software libre, 
que tiene un gran número de instalaciones. En su base incluye el proceso de  ''Orden de compra``. Para realizar el acoplamiento se creó
un nuevo módulo
de OpenERP. Se identificaron los puntos de firma y validación y se sustituyeron por las llamadas
respectivas al ComponenteFEA. Como elemento agregado, se creó un nuevo módulo basado en bandejas de documentos -archivos generados por OpenERP- 
(similar a las usadas en los clientes de correo electrónico)
asociadas a los documentos a ser firmados electrónicamente.


La figura \ref{fig:openerp} muestra la interfaz de usuario para gestionar los archivos firmados electrónicamente. Los usuarios autorizados pueden utilizar una
tarjeta inteligente para firmar los documentos correspondientes al proceso de ''Orden de compra``, teniendo la misma validez legal (especificado por 
las políticas de la PKI y la legislación del país) que la firma manuscrita.
 Primero el solicitante firma  la requisición, y este documento se envía a  la bandeja del analista de compra, quién busca las cotizaciones correspondientes y
  selecciona el conjunto de productos a comprar. Se generan los documentos ''Acta'' y ``Orden de compra'', este último es enviado a la bandeja del gerente quién 
lo firma  para aprobar la compra del conjunto de productos o servicios seleccionados.


OpenERP provee al desarrollador patrones Modelo-Vista-Controlador (MVC) y un motor de flujo de trabajos o \textit{Workflow} para implementar nuevas funcionalidades. 
Usando estas herramientas los documentos firmados se vinculan al modelo de datos y las validaciones de firma electrónica se realizan 
extendiendo el flujo de trabajo relacionado con el proceso ``Orden de compra'' base de OpenERP.


\begin{figure}[htb]
\centering
\includegraphics[scale=1]{imagenes/openerp.jpeg}
\caption{Interfaz de usuario OpenERP para el ComponenteFEA}
\label{fig:openerp}
\end{figure}


La última captura de pantalla de la figura \ref{fig:openerp} muestra un cuadro  de diálogo que pide un PIN o contraseña  al usuario. Esta interfaz forma
parte del complemento Web que debe ser instalado en el cliente (navegador) y que tiene interacción con el certificado firmante contenido en una
tarjeta inteligente.



\subsection{Caso SAID}


SAID\footnote{Ver la dirección web: http://said.cenditel.gob.ve/wiki } es un sistema administrativo que incluye procesos contables 
y administrativos para instituciones que operen en el sector público venezolano.
Entre los procesos que implementa SAID está el de `Orden de compra``, que incluye entre sus capacidades la posibilidad de utilizar firmas electrónicas basadas en el formato  PKCS\#7. 

El sistema fue escrito en PHP Versión 4.X, y
es de código libre. Los puntos de firma y validación están claramente identificados, ya que son los indicados por las firmas electrónicas, 
en este caso solo se sustituyen las llamadas a la API del motor criptográfico local, por llamados a los servicios web del ComponenteFEA. El listado
 \textbf{2} muestra
las llamadas que se insertaron en el código fuente para extender el sistema de tal manera que funcione con firmas electrónicas avanzadas.
 El repositorio de archivos firmados a utilizar es
PostgreSQL Version 8.4 (El mismo que utiliza SAID). El listado \textbf{2} muestra el código en PHP para validar una firma electrónica y mostrar los firmantes de un
documento del proceso de Orden de compra: requisición, acta u orden.  Después de realizar la conexión al servidor \textit{localhost} por el puerto 4242, se procede
a abrir un archivo firmado con el método ''openBDocContainer`` a través de una llamada remota, luego se utiliza el método ''validateSignature`` para validar
la firma, y finalmente se listan todos los firmantes  utilizando el método  ''subjectCertificateCommonName``.

\begin{verbatim}
 <?php

include('xmlrpc.php');

$connec = new XMLRPCClient('localhost:4242');
$identificador = 'prueba1';
$connec->__call('init', array($identificador));
$connec->__call('openBDocContainer', 
array($identificador,
'detalle_curso.odt.bdoc'));
$resp = $connec->__call('signatureCount', 
array($identificador));
$firmantes = Array();
for($pos=0; $pos<$resp; $pos++)
{       
        $datos = Array();
        $valida = 'No válido';
        if($connec->__call('validateSignature', 
array($identificador,$pos)))
        {
           $valida = 'Válido';
           $nombre = 
 $connec->
   __call('subjectCertificateCommonName',
array($identificador,$pos));
           $firmantes[] = array('nombre'=> $nombre,
'valida'=>$valida);
        }
}

for($i=0;$i<count($firmantes);$i++)
{
        echo "{$firmantes[$i]['nombre']} 
{$firmantes[$i]['valida']}\n";
}
?> 
\end{verbatim} \begin{center} \textbf{Listado 2.} Conexión mediante servicios web-rpc desde SAID al ComponenteFEA
\end{center}


De forma similar al caso OpenERP, se provee un complemento para el navegador de tal manera que los usuarios puedan
realizar la firma de forma remota, utilizando una tarjeta inteligente desde su estación de trabajo. Luego el documento
se procesa por el sistema SAID, y se almacena en la base de datos del servidor. 

\subsection{Caso Flujos de Trabajo}

El proceso especificado en esta sección puede modelarse  usando un motor de flujo de trabajo. Los flujos de trabajo son ampliamente utilizados para modelar procesos
a través de un lenguaje descriptivo como BPM o BPEL \cite{IEEEhowto:bpel}.  Para implementar el proceso de ''Orden de compra`` se utilizó el motor 
SAFET \cite{IEEEhowto:safet}, ya que incorpora
el ComponenteFEA nativamente, solo se necesitan especificar los puntos en el proceso donde se requiere la firma electrónica. La validación la realiza el motor de forma
automática. Para este caso los pasos 1 y 2 del Diagrama de flujo para el acoplamiento del ComponenteFEA, se realizan sin  la necesidad de agregar o modificar
código fuente, solo se especifica en el archivo de definición de flujo. 

\begin{verbatim}
<task id="Requisicion" 
 title="Acción de solicitud de bien o servicio" >
<port side="forward" type="split" >
<connection source="Cotización" 
query="vRequisicion SIGN NombreComunUsuario" 
options="" >
</connection>
</port>
<variable id="vRequisicion" scope="task"
tokenlink="" 
documentsource="select  id,
nombre,descripcion,
fechageneracion 
from requisiciones" >
</variable>
</task>
\end{verbatim}  \begin{center} \textbf{Listado 3.} Tarea de firma de requisición usando SAFET (XML)
\end{center}

El listado \textbf{3} muestra la definición de la acción de firma electrónica  en un flujo de trabajo (SAFET).  El usuario definido por 
el \textit{NombreComunUsuario} debe firmar electrónicamente el documento de requisición para pasar a la siguiente actividad 
que en este caso se denominada \textit{Cotización}.
La sentencia \textit{vRequisicion \textbf{SIGN} NombreComunUsuario} indica al motor de flujo de trabajo lo descrito anteriormente.


\section{Conclusiones}

En un mediano plazo la Firma Electrónica Avanzada  puede consolidarse como una tecnología fundamental en los procesos
de negocio ya que propone la digitalización de un elemento  imprescindible en este contexto como lo es la firma manuscrita. 
Los retos de la digitalización son diversos y complejos, y tienen que ver con aspectos disímiles como lo son por ejemplo los formatos
de archivo de firma electrónica y la ergonomía para el uso de esta tecnología. 

En este trabajo se detalla un método para la integración de un componente de software con sistemas informáticos
que automatizan procesos de negocio. En la fase de  acoplamiento se define la identificación
de puntos de firma electrónica, se especifica la  validación de los certificados firmantes por una PKI, 
se muestra la habilitación del navegador web para la firma electrónica (basada en tarjetas inteligentes) 
a través de un complemento y se discute sobre los parámetros de seguridad de los formatos de firma electrónica.
Las tareas como la construcción de un gestor de archivos firmados se proponen como una actividad  complementaria.


Con la finalidad de mostrar la aplicación del método  propuesto en sistemas en situaciones reales se mostraron tres casos de estudio,
cada uno con sus particularidades.
 El acoplamiento del ComponenteFEA con los sistemas
informáticos OpenERP, SAID y SAFET siguen el método descrito en el trabajo, evaluando para todos los casos especialmente el tipo de conexión 
a utilizar  (local o remota), el tipo de almacenamiento y el procedimiento para la conexión en los puntos de firma electrónica y validación.


El análisis de vulnerabilidades  es un tema omnipresente en el área
de seguridad informática, y está relacionado con este trabajo a través del análisis de los formatos, protocolos y
tecnologías utilizados en el proceso de integración. 

Existen otros aspectos que no se discuten en este trabajo pero que se consideran importantes para la  aprehensión de la 
tecnología de firma electrónica. Entre ellos se pueden señalar la mejora de  la experiencia del usuario  
y la visualización de  los archivos de formato XML firmados electrónicamente. 

En el tema específico de integración, en \cite{IEEEhowto:eID} se discute sobre la necesidad de 
abrir el compás de aplicaciones
compatibles con la tecnología de Firma Electrónica Avanzada, y en general, sobre la asunción de un nuevo paradigma en el despliegue
de procesos de negocio.






% el siguiente comando establece la ubicación de las referencias
\putbib[bibliografia]

% el siguiente comando cierra el ambiente bibunit para la cual se generan las
% referencias.
\end{bibunit}



 


% \begin{thebibliography}{1}
% 
% \bibitem{IEEEhowto:espana}
% Portal del DNI Electrónico Español. Disponible en: http://www.dnielectronico.es/. Febrero 2013.
% 
% \bibitem{IEEEhowto:eID}
% Andreas Poller, Ulrich Waldmann, Sven Vowe, Sven Turpe, Electronic Identity Cards for User Authentication
% Promise and Practice, IEEE Security \& Privacy10, vol. 10, no. 1, pp. 46-54, January/February, 2012
% 
% 
% \bibitem{IEEEhowto:estonia}
% Oficial Gateway to Estonia. Disponible en: http://estonia.eu/about-estonia/economy-a-it/e-estonia.html. Febrero 2013.
% 
% 
% \bibitem{IEEEhowto:software}
% Campderrich Falgueras, Benet. Ingeniería del Software. Editorial UOC. Barcelona, España. 2003.
% 
% 
% \bibitem{IEEEhowto:directiva}
% DIRECTIVA 1999/93/CE DEL PARLAMENTO EUROPEO Y DEL CONSEJO. Diciembre 1999. Disponible en: http://www.cert.fnmt.es/legsoporte/D\_1999\_93\_CE.pdf
% 
% \bibitem{IEEEhowto:x509}
% Cooper D.,  Santesson S., y otros. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Request for Comments (RFC) 5280. May 2008.
% Disponible en: http://www.ietf.org/rfc/rfc5280.txt. Febrero 2013.
% 
% \bibitem{IEEEhowto:pkcs7}
% PKCS\#7.Cryptographic Message Syntax. Disponible en: https://tools.ietf.org/html/rfc2315. Febrero 2013.
% 
% \bibitem{IEEEhowto:pades}
% PAdES. PDF Advance Electronic Signatures. Disponible en: http://www.etsi.org/deliver/etsi\_ts/
% 102700\_102799/10277801/01.01.01\_60/ts\_10277801v010101p.pdf. Febrero 2013.
% 
% \bibitem{IEEEhowto:xmldsig}
% Bartel M., Boyer J., y otros. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June 2008.
% Disponible en: http://www.w3.org/TR/xmldsig-core/. Febrero 2013.
% 
% \bibitem{IEEEhowto:bdoc}
% Formato para firmas electrónicas. Disponible en: http://www.signature.it/-TOOLS/Bdoc-1.0.pdf. Febrero 2013.
% 
% \bibitem{IEEEhowto:neubauer}
% Neubauer, T.; Weippl, E.; Biffl, S., "Digital signatures with familiar appearance for e-government documents: authentic PDF," Availability, 
% Reliability and Security, 2006. ARES 2006. The First International Conference on , vol., no., pp.8 pp.,, 20-22 April 2006
% 
% \bibitem{IEEEhowto:java}
% Richardson Clay, Avondolio Donald, others. Professional Java, JDK. 5th Edition. Wrox. February. 2005.
% 
% \bibitem{IEEEhowto:xades}
% Cruellas, J. Karlinger G., y otros. XML Advanced Electronic Signatures (XAdES). W3C Note 20 February 2003.
% 
% \bibitem{IEEEhowto:mime}
% Security Multiparts for MIME. Multipart/Signed and Multipart/Encrypted. Disponible en: http://tools.ietf.org/html/rfc1847. Febrero 2013.
% 
% \bibitem{IEEEhowto:pkcs12}
% PKCS\#12.Personal Information Exchange Syntax Standard. RSA Laboratories. Disponible en: https://www.rsa.com/rsalabs/node.asp?id=2138. Febrero 2013.
% 
% \bibitem{IEEEhowto:bpel}
% Matjaz Juric, Mathew Benny. Business Process Execution for Web Services BPEL and BPEL4WS. 2 Ed. Packt Publishing. 2006.
% 
% \bibitem{IEEEhowto:safet}
% Bravo, V. Araujo A., SAFET: Sistema para la generación de aplicaciones de firma electrónica. Revista Puente. Vol 6. Número 1. Bucaramanga, Colombia. 2011.
% 
% 
% % el siguiente item no se está utilizando
% \bibitem{IEEEhowto:pki}
% Duane. N. Brink, J. PKI: Infraestructura de Clave Pública. McGrawHill 2002.
% 
% \end{thebibliography}

%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{victor.png}}]{Víctor Bravo}
% Víctor Bravo nació en Maracaibo, Venezuela. Es Ingeniero de Sistemas y tiene una maestría en Computación de la Universidad de los Andes (ULA),Venezuela. 
% Ha trabajado como director en importantes
% proyectos vinculados a procesos de Certificación Electrónica masiva tal como ''Software de Gestión Autoridad Raíz de la
% PKI Pública Nacional``. Ha dictado conferencias sobre temas de certificación electrónica en varios países. Actualmente está 
% adscrito como Investigador a la Fundación CENDITEL, y ha sido profesor desde el año 2005 de la cátedra de Matemáticas Discretas del
% Departamento de Computación de la ULA.
%\end{IEEEbiography}


%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{antonioaraujo.jpg}}]{Antonio Gregorio Araujo Brett}
% Antonio Araujo es Ingeniero de Sistemas, egresado de la Universidad de Los Andes, en
% Mérida, Venezuela. Actualmente
% cursa estudios de Maestría en Computación de la Facultad de Ingeniería
% de la Universidad de Los
% Andes. Ha asesorado
% proyectos de certificación
% electrónica y participado como ponente en varias jornadas y congresos de
% certificación electrónica y
% firmas electrónicas en el país.
% Se desempeña desde el año 2007 como Analista de la gestión de
% desarrollado en Tecnologías Libres de
% la Fundación Centro Nacional de Desarrollo e Investigación en
% Tecnologías Libres – CENDITEL Nodo
% Mérida.
%\end{IEEEbiography}

%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{jogerquintero.jpg}}]{Joger André Quintero Escalante}

% Joger Quintero es Técnico Superior en Informática, egresado del Instituto Universitario Tecnológico de Ejido, en
% Ejido, Venezuela.  Se desempeña como Analista Desarrollador en CENDITEL(Nodo Mérida) desde el año 2011. 
%\end{IEEEbiography}