Documento técnico Manual de integración de ASF

Documento técnico Manual de integración de ASF Revisión: v 1.4 Fecha última versión: junio de 2006

Índice 1_ Introducción... 3 1.1_ Descripción de plataforma ASF... 3 1.2_ Módulo WebSigner... 4 1.3_ Módulo de Autenticación Única (SingleSignOn o SSO)... 6 1.4_ Módulo de Validación de Certificados X.509 (X509Validator)... 6 1.5_ Módulo Gestor de Políticas (PolicyManager)... 7 1.6_ Módulo Servidor de Firmas (SignatureServer)... 8 1.7_ Módulo Servidor de Cifrado (EncryptionServer)... 8 1.8_ Módulo TimeStampServer... 9 1.9_ Módulo TimeStampClient... 9 1.10_ Módulo de No Repudio (Non Repudiation)... 9 1.11_ Módulo de OCSP... 10 2_ Integración de ASF... 11 2.1_ Integración del Módulo WebSigner... 12 2.2_ Integración del Módulo de Autenticación única (SSO)... 12 2.3_ Integración con los Módulos que publican Web Services... 12 2.3.1_ Ejemplo de invocación J2EE a Web Services de ASF con axis.. 14 2.3.2_ Ejemplo de invocación.net (VB.NET) a Web Services de ASF 17 2.3.3_ Invocaciones locales a los Web Services de ASF... 20 2.3.4_ Integración del Módulo Gestor de Políticas (PolicyManager)... 22 2.3.5_ Integración del Módulo de Validación de Certificados (X509Validator)... 22 2.3.6_ Integración del Módulo Servidor de Firmas (SignatureServer)... 22 2.3.7_ Integración del Módulo Servidor de Cifrado (EncryptionServer).. 22 2.3.8_ Integración del Módulo TimeStampClient... 22 2.3.9_ Integración del Módulo NonRepudiationService... 22 2.4_ Integracion de Módulos sin Web Services... 23 2.4.1_ Integración con el módulo TimeStampServer... 23 2.4.2_ Integración con el módulo OCSPResponder... 23 Revisión: 1.4 2

1_ Introducción Este documento tiene como finalidad recoger todos los aspectos relacionados con la integración de los distintos módulos que componen la Plataforma de Firma Electrónica Avanzada ASF. Dicha plataforma es una solución completa para la integración de la Firma Electrónica Avanzada en la infraestructura informática de una entidad u organización. 1.1_ Descripción de plataforma ASF La Plataforma ASF es una solución completa para la integración de la Firma Electrónica Avanzada en una infraestructura informática de una entidad u organización. Una de sus características más diferenciadoras es el hecho de permitir la convivencia con más de una Autoridad de Certificación (CA), independizando completamente al resto de los sistemas de la complejidad añadida que supone la compatibilidad con más de una CA. Los principales aspectos que permite resolver la utilización de ASF en cualquier organización incluyen los siguientes: Autenticación. Permite conocer la identidad de los usuarios remotos utilizando certificados X.509 como método de autenticación. Integridad. La generación de documentos con firma electrónica avanzada permite la comprobación de que el documento no ha sido modificado por un tercero desde la generación del mismo. No Repudio. El sistema almacena en una base de datos copias de los documentos firmados, de forma que puedan ser utilizados en caso de necesidad como prueba de autoría. Confidencialidad. La generación de documentos cifrados permite garantizar que sólo los destinatarios de los mismos podrán acceder a su contenido. El entorno ASF establece una solución de principio a fin en la seguridad de las transmisiones con acciones para firmar, cifrar, fechar y transmitir todo tipo de documentos electrónicos de un modo seguro. Revisión: 1.4 3

ASF está compuesto de un conjunto de módulos que permiten abarcar de manera ágil y sencilla todos los aspectos relacionados con el proceso de implementación de Firma Electrónica Avanzada dentro de cualquier aplicativo. Cada módulo está especializado en una tarea específica, interactuando entre ellos para dar la solución completa. De esta forma las tareas habitualmente comunes de un entorno PKI están implementadas sólo en uno de los módulos de utilidad. Por ejemplo, cuando cualquiera de los módulos necesita conocer la validez de un certificado, interactúa con el módulo X509 Validator, quien le confirmará o le rechazará la validez del certificado. ASF contempla el ciclo de vida completo de utilización de certificados proporcionando herramientas para: Constituir una autoridad de certificación Creación de documentos firmados Validación y control de documentos firmados Validación de la vigencia de los certificados Registro de información de la firma de documento, de cara al no repudio Cifrado y descifrado de documentos Establecer políticas de firma a nivel de aplicaciones y/o operaciones. 1.2_ Módulo WebSigner El módulo WebSigner está compuesto por una serie de componentes y tecnologías que permiten la generación de documentos firmados en formato PKCS#7, CMS y XMLDSIG en sistemas basados en tecnología web. Asimismo, permite el cifrado y descifrado de documentos en formato PKCS#7 y CMS. WebSigner es el componente cliente de ASF diseñado para permitir a un usuario la firma y el cifrado de documentos y formularios web desde una página HTML para enviar al servidor. La integración es posible en aplicaciones de diversa índole, tales como en mecanismos de identificación (autenticación de cliente) para el acceso a Revisión: 1.4 4

servicios web, como para la transmisión de documentos digitales o formularios firmados. Debido a que se trata de un componente cliente se han cuidado los aspectos de compatibilidad entre distintos navegadores y tecnologías así como la usabilidad de cara al usuario. WebSigner proporciona utilidades para permitir filtrados de certificados autorizados en cada proceso. WebSigner expone un Interfaz Javascript común, para la invocación de los componentes de firma y cifrado, y la independización de la tecnología utilizada. Para Internet Explorer, WebSigner basa su solución en la innovadora CAPICOM, un control ActiveX que proporciona una interfaz COM para la biblioteca criptográfica Microsoft CryptoAPI, para la firma XMLDSIG basa su solución en las librerias XERCES, XALAN y XSEC de Apache implementando el modulo en C++. Para Netscape 6.x o superior, la solución está basada en un applet Java que accede al almacén de certificados propietario de Netscape y realiza las operaciones de firma a través de JSS/NSS. Este mismo applet es la solución adoptada para el uso de Websigner en Mozilla desde las version 1.x, teniendo en cuenta que para algunas versiones de este navegador será necesario descargar el JDK. En el caso del applet existen dos versiones, una versión "ligera", que no soporta el formato XMLDSig, y una versión completa, de tamaño mucho mayor, que soporta XMLDSig. La versión completa está basada en las librerias XERCES, XALAN y XSEC de Apache. Las funcionalidades incluidas en WebSigner son las siguientes: Uso de firma única o múltiple (mancomunada) en formato PKCS#7, CMS y XMLDSIG. Este módulo ha sido diseñado para permitir la firma de cualquier tipo de documento o formulario por más de una persona en los tres formatos especificados para su posterior envio al servidor, permitiendo su integración en cualquier aplicación. Filtrado de certificados autorizados para el proceso. Esta funcionalidad permite facilitar al usuario la selección del certificado que puede utilizar, en función de las políticas de confianza definidas para el proceso en el servidor. Cifrado y descifrado de un formulario o un documento. Gracias a la implementación de WebSigner es posible cifrar cualquier tipo de documento o formulario que deseemos enviar al servidor. Revisión: 1.4 5

A alto nivel, los servicios más importantes ofrecidos por este módulo son: Obtención de la lista de certificados de la máquina (almacén del navegador y tarjeta criptográfica) Firma de un documento/formulario con diferentes algoritmos (PKCS#7, CMS, XMLDSig) Añadir firmantes a una firma realizada Verificación de la corrección del formato de una firma (sin comprobación de la revocación) Cifrado utilizando un certificado Descifrado utilizando un certificado 1.3_ Módulo de Autenticación Única (SingleSignOn o SSO) El Módulo de Autenticación Única (en adelante, SingleSignOn) permite integrar varias aplicaciones en un sistema único de autenticación, de forma que una vez que un usuario se autentique en una de ellas, no necesita autenticarse para acceder al resto. Todas las aplicaciones que se integren con un mismo servidor de Single Sign- On (es decir, que interactúen todas ellas con el módulo SingleSignOn del mismo servicio ASF) deben pertenecer a uno de los dominios admitidos por el servidor de Single Sign On, no siendo posible con una misma sesión navegar entre dominios distintos. 1.4_ Módulo de Validación de Certificados X.509 (X509Validator) El módulo de Validación de Certificados X.509 (en adelante, X509Validator) es el encargado de validar tanto el periodo de validez como el estado de revocación de certificados X.509. El módulo abarca diversos protocolos de validación del estado de revocación, OCSP, CRLs mediante LDAP, HTTP y explotación de toda la información Revisión: 1.4 6

disponible en los propios certificados (Puntos de Distribución de CRLS e Información de Acceso a la Autoridad con URLs de servidores OCSP). Este módulo hace uso del módulo PolicyManager para obtener los prestadores de confianza, los métodos de comprobación de revocación asociados a un prestador, etc. y del módulo NonRepudiation para registrar en la base de datos de no repudio la información utilizada para comprobar la revocación de los certificados (CRLs, respuestas OCSP, etc.). A alto nivel, los servicios más importantes ofrecidos por este módulo a las aplicaciones son: Validación de un certificado (no caducidad ni revocación) Validación de un certificado y extracción de los datos incluidos en el mismo (mediante la utilización del módulo de gestión de políticas) 1.5_ Módulo Gestor de Políticas (PolicyManager) El Módulo Gestor de Políticas (en adelante, PolicyManager) proporciona servicios de configuración al resto de móudulos de ASF. El PolicyManager se encarga de acceder a la BD de ASF, donde se almacena toda la información que define el comportamiento de la plataforma. El PolicyManager proporciona al resto de módulos información de: los prestadores dados de alta y los métodos de comprobación de revocación asociados a cada prestador las aplicaciones dadas de alta y sus operaciones de firma, verificación y cifrado los prestadores válidos para cada aplicación y operación de verificación y cifrado los certificados de firma y cifrado asociados a las operaciones las restricciones de acceso asociadas a las aplicaciones A alto nivel, los servicios ofrecidos por más importantes este módulo a las aplicaciones son: Revisión: 1.4 7

Obtención de las CAs válidas para una aplicación / operación. Obtención de los datos de un certificado, según la estructura definida en la consola de administración. Obtención de LDAP usados por el sistema. 1.6_ Módulo Servidor de Firmas (SignatureServer) El Módulo Servidor de Firmas (en adelante, SignatureServer) firma datos y documentos en distintos formatos y con distintos algoritmos, y verifica firmas realizadas en cualquiera de esos formatos y con cualquiera de esos algoritmos. El Servidor de Firmas es capaz de generar firma múltiple secuencial y paralela, tanto directa como diferida. Este módulo hace uso de los módulos PolicyManager para obtener los certificados válidos para firmar, los prestadores válidos para verificar, etc., X509Validator para verificar el estado de los certificados implicados en las operaciones de firma y verificación y NonRepudiation para registrar todas las operaciones de verificación de firmas realizadas. A alto nivel, los servicios ofrecidos por más importantes este módulo a las aplicaciones son: Verificación de firma y obtención de los datos de los firmantes. Posibilidad de almacenamiento en el no repudio (utilizando el módulo de no repudio) Verificación de que los datos firmados se corresponden con los deseados y no fueron modificados antes de llevar a cabo la firma Firma en servidor con los algoritmos soportados por la plataforma 1.7_ Módulo Servidor de Cifrado (EncryptionServer) El Módulo Servidor de Cifrado (en adelante, EncryptionServer) realiza cifrado y descifrado de documentos en distintos formatos y con distintos algoritmos. Revisión: 1.4 8

Este módulo hace uso de los módulos PolicyManager para obtener los certificados y prestadores válidos para cifrar y X509Validator para verificar el estado de los certificados implicados en las operaciones de cifrado y descifrado. A alto nivel, los servicios ofrecidos por más importantes este módulo a las aplicaciones son: Cifrado con los algoritmos admitidos por ASF Descifrado con los algoritmos implementados en ASF 1.8_ Módulo TimeStampServer El Módulo de TimeStampServer permite a aplicaciones y componentes añadir sellos de tiempo a documentos o firmas, dotándolas de validez a lo largo del tiempo. Las características principales de dicho componente son la recepción de peticiones, procesado de la petición y envió de sello de tiempo según el RFC 3161. Se permiten restricciones de acceso al servicio de sellado exigiendo que las mismas vengan firmadas y encapsuladas en un mensaje PKCS7-CMS SignedData. 1.9_ Módulo TimeStampClient El Módulo de TimeStampClient ofrece una sencilla interfaz basada en Web Services (SOAP) para obtener sellos de tiempo, oculta la complejidad de las autoridades de sellado concentrando en un único punto toda la funcionalidad del sellado de tiempo. Se permite una configuración completa a través de la consola de administración de ASF, tanto de los certificados con los que firman las respectivas Autoridades de Sellado (TSA en adelante) como los certificados necesarios para la firma de peticiones en caso de que las TSAs exijan la firma de las mismas. 1.10_ Módulo de No Repudio (Non Repudiation) El Módulo de No Repudio (en adelante, NonRepudiation) registra en la Base de Datos de No Repudio (incluida dentro de la base de datos de ASF) todas las Revisión: 1.4 9

firmas verificadas por el módulo SignatureServer, junto con toda la información utilizada para comprobar el estado de revocación de los certificados implicados: CRLs, respuestas OCSP, etc. 1.11_ Módulo de OCSP El módulo servidor de OCSP (OCSP responder) es el encargado de devolver información del estado de los certificados de múltiples CAs, en el instante que se recibe una petición en el servidor, de acuerdo con el estándar descrito en el RFC 2560. Realiza una comprobación inicial de la firma de la petición OCSP efectuada por un cliente OCSP y también de su autorización para efectuar este tipo de peticiones, si no está autorizado se rechaza la petición sin devolver ningún tipo de información. Revisión: 1.4 10

2_ Integración de ASF La integración con ASF tiene cinco partes diferenciadas: Integración con el componente cliente WebSigner. Integración con los módulos que publican web services (PolicyManager, X509Validator, SignatureServer, EncryptionServer, NonRepudiationService, TSAClient) salvo con el módulo de autenticación única (SingleSignOn). Integración con el módulo de autenticación única (SingleSignOn) Integración con la Autoridad de Sellado de Tiempo (TimestampServer) Integración con el módulo de OCSP. En los siguientes apartados se describe la integración con todos estos componentes. Para facilitar la integración con los módulos que publican web services, se dispone de un Agente de Seguridad, cuya integración está descrita en el documento TBS_ASFv3.5_Manual de integración Agente de seguridad_20060110_v1.0.doc. En caso de utilizar el agente de seguridad, no es necesario realizar la integración de esos módulos tal y como se describe en el presente documento. Revisión: 1.4 11

2.1_ Integración del Módulo WebSigner La API del componente WebSigner, así como el orden lógico de llamadas al mismo a la hora de integrarlo en una página HTML o jsp junto con algunos ejemplos de integración pueden encontrarse en TBS_ASFv3.5_Manual de integración WebSigner_20060222_v1.0.doc. 2.2_ Integración del Módulo de Autenticación única (SSO) El módulo SingleSignOn consta de dos partes. Por un lado está la parte servidora que se encarga de mantener la información de las sesiones y por otro lado está la parte cliente que solicita a la anterior información del usuario. Ambas partes están descritas en TBS_ASFv3.5_Manual de integración SSO_20060222_v1.0.doc, junto con la descripción de todas sus propiedades y ejemplos de integración. 2.3_ Integración con los Módulos que publican Web Services La integración con todos los módulos que ofrecen Web Services (PolicyManager, X509Validator, SignatureServer, EncryptionServer, NonRepudiationService, TSAClient, SingleSignOnService) es similar. Los pasos a seguir para invocar a un Web Service de ASF son los siguientes: Disponer en el cliente (aplicación invocante) de estructuras de datos y constantes equivalentes a las utilizadas en la función a invocar. Si la aplicación cliente es J2EE, ASF proporciona las librerías con las estructuras de datos y las constantes. Si la aplicación cliente es C, C#, etc., deben generarse las estructuras de datos y las constantes. Indicar la URL del Web Service y el método a invocar. Especificar los parámetros y el valor de retorno. Revisión: 1.4 12

Especificar el método de serialización de parámetros. Realizar la invocación. ASF permite firmar las invocaciones SOAP, pudiendo identificar de esta forma a la aplicación invocante y permitirle o no el acceso.para posibilitar la comprobación de los permisos de acceso, la aplicación invocante debe pasar un parámetro invokingapp identificándose. En caso de utilizar algún tipo de wizard (ya sea java,.net, etc.) para generar el cliente que realizará las invocaciones a los web services, es muy importante mantener el nombre de los parámetros, es decir, el parámetro en el que se pase el invokingapp debe llamarse invokingapp. Revisión: 1.4 13

2.3.1_ Ejemplo de invocación J2EE a Web Services de ASF con axis Inclusión de las librerías de estructuras de datos y constantes (asf_data.jar y asf_client.jar) y de las librerías de axis dentro del CLASSPATH de la aplicación cliente. Importar las clases de axis y las clases de asf_data.jar y asf_client.jar implicadas en la invocación: <%@ page import = " jfactory.exchange.resultinfo, java.util.arraylist, com.tbsolutions.asf.demo.util.util, org.apache.axis.client.call, org.apache.axis.client.service, org.apache.axis.encoding.xmltype, javax.xml.namespace.qname, javax.xml.rpc.parametermode, com.tbsolutions.asf.util.constants, com.tbsolutions.asf.policymanager.sa.certappoperationrestrictionsinfoset, com.tbsolutions.asf.policymanager.sa.certappoperationrestrictionsinfo, com.tbsolutions.asf.policymanager.sa.restrictioninfo, com.tbsolutions.asf.policymanager.sa.certtypeinfo" contenttype="text/html; charset=iso-8859-1"%> Creación de los objetos implicados en la invocación (axis): Service service = new Service(); Call call = (Call) service.createcall(); Establecimiento de la URL del Web Service y el método a invocar: call.settargetendpointaddress( new java.net.url( http://localhost:8080/asf/services/policymanager ) ); call.setoperationname("getvalidcassigns"); Establecimiento de parámetros: call.addparameter("applicationid", XMLType.XSD_STRING, ParameterMode.IN); call.addparameter("operationid", XMLType.XSD_STRING, ParameterMode.IN); call.addparameter("invokingapp", XMLType.XSD_STRING, ParameterMode.IN); Revisión: 1.4 14

Información para la serialización: QName qcaor = new QName( "urn:jfactory", "CertAppOperationRestrictionsInfoSet" ); call.registertypemapping(certappoperationrestrictionsinfoset.class, qcaor, new org.apache.axis.encoding.ser.beanserializerfactory(certappoperationrestric tionsinfoset.class, qcaor), new org.apache.axis.encoding.ser.beandeserializerfactory(certappoperationrestr ictionsinfoset.class, qcaor)); QName qcaor2 = new QName( "urn:jfactory", "CertAppOperationRestrictionsInfo" ); call.registertypemapping(certappoperationrestrictionsinfo.class, qcaor2, new org.apache.axis.encoding.ser.beanserializerfactory(certappoperationrestric tionsinfo.class, qcaor2), new org.apache.axis.encoding.ser.beandeserializerfactory(certappoperationrestr ictionsinfo.class, qcaor2 QName qr = new QName( "urn:jfactory", "RestrictionInfo" ); call.registertypemapping(restrictioninfo.class, qr, new org.apache.axis.encoding.ser.beanserializerfactory(restrictioninfo.class, qr), new org.apache.axis.encoding.ser.beandeserializerfactory(restrictioninfo.class, qr)); QName qcti = new QName( "urn:jfactory", "CertTypeInfo" ); call.registertypemapping(certtypeinfo.class, qcti, new org.apache.axis.encoding.ser.beanserializerfactory(certtypeinfo.class, qcti), new org.apache.axis.encoding.ser.beandeserializerfactory(certtypeinfo.class, qcti)); QName qri = new QName( "urn:jfactory", "ResultInfo" ); call.registertypemapping(resultinfo.class, qri, new org.apache.axis.encoding.ser.beanserializerfactory(resultinfo.class, qri), new org.apache.axis.encoding.ser.beandeserializerfactory(resultinfo.class, qri)); Revisión: 1.4 15

Establecimiento del valor de retorno: call.setreturntype( qcaor ); Invocación: String applicationid = 1 ; String operationid = 1 ; String invokingapp = 1 ; CertAppOperationRestrictionsInfoSet listacas = (CertAppOperationRestrictionsInfoSet) call.invoke( new Object[]{applicationID, operationid, invokingapp} ); Invocación Java a Web Services de ASF con axis: Los parámetros se mandan siempre como objetos. El valor de retorno es siempre un objeto. Los tipos básicos se serializan automáticamente: o Tipos numéricos: int / Integer, long / Long, etc. o Cadenas de caracteres o Arrays o Fechas o Axis serializa de forma automática los Java Beans, con tal que se le indiquen las clases a serializar QName qr = new QName( "urn:jfactory", "RestrictionInfo" ); call.registertypemapping(restrictioninfo.class, qr, new org.apache.axis.encoding.ser.beanserializerfactory(restrictioninfo.class, qr), new org.apache.axis.encoding.ser.beandeserializerfactory(restrictioninfo.class, qr)); Revisión: 1.4 16

Todos los Web Services de ASF utilizan tipos básicos o Java Beans (Info s). 2.3.2_ Ejemplo de invocación.net (VB.NET) a Web Services de ASF Creación de estructuras de datos análogas a las enviadas por ASF Namespace Types <System.Xml.Serialization.SoapTypeAttribute("ResultInfo", "urn:jfactory")> _ Public Class ResultInfo '<remarks/> Public [error] As Boolean '<remarks/> Public errorpage As String '<remarks/> Public message As String '<remarks/> Public subcode As String End Class End Namespace Creación de clase de acceso al Web Service: Imports System Imports System.ComponentModel Imports System.Diagnostics Imports System.Web.Services Imports System.Web.Services.Protocols Imports System.Xml.Serialization Namespace X509Validator <System.Diagnostics.DebuggerStepThroughAttribute(), _ System.ComponentModel.DesignerCategoryAttribute("code"), _ System.Web.Services.WebServiceBindingAttribute( Name:="X509ValidatorSoapBinding", [Namespace]:="X509Validator"), _ System.Xml.Serialization.SoapIncludeAttribute(GetType(Types.InfoAccessor))> _ Public Class X509ValidatorService Inherits System.Web.Services.Protocols.SoapHttpClientProtocol End Class End Namespace Revisión: 1.4 17

En la clase creada, establecimiento de la URL del Web Service : Public Sub New() MyBase.New() Me.Url = "http://localhost:8080/asf/services/x509validator" End Sub Creación de métodos para cada método del Web Service: <System.Web.Services.Protocols.SoapRpcMethodAttribute("", RequestNamespace:="X509Validator", ResponseNamespace:="X509Validator")> _ Public Function validateremote(byval in0 As Types.ParamsX509Info) As <System.Xml.Serialization.SoapElementAttribute("validateRemoteReturn")> Types.ResultVerifyCertInfo Dim results() As Object = Me.Invoke("validateRemote", New Object() {in0}) Return CType(results(0), Types.ResultVerifyCertInfo) End Function Private Function BeginvalidateRemote(ByVal in0 As Types.ParamsX509Info, ByVal callback As System.AsyncCallback, ByVal asyncstate As Object) As System.IAsyncResult Return Me.BeginInvoke("validateRemote", New Object() {in0}, callback, asyncstate) End Function Private Function EndvalidateRemote(ByVal asyncresult As System.IAsyncResult) As Types.ResultVerifyCertInfo Dim results() As Object = Me.EndInvoke(asyncResult) Return CType(results(0), Types.ResultVerifyCertInfo) End Function Invocación.NET a Web Services de ASF: El entorno de desarrollo Visual Studio.NET ofrece un Wizard que facilita el desarrollo de invocaciones a Web Services. Indicando la URL del fichero WSDL con la descripción del Web Service, genera el código de las invocaciones y las clases y estructuras de datos necesarias. El Wizard genera código redundante => es conveniente repasar el código generado. Debido a la arquitectura que utiliza ASF, todos los parámetros de los objetos usados como parámetros y valores de retorno (Info s) están replicados. Existe el [parámetro] y el correspondiente [parámetro]object. Revisión: 1.4 18

Cuando se invoca desde un lenguaje distinto de J2EE, deben rellenarse ambos campos, [parámetro] y [parámetro]object, o bien eliminar el [parámetro] en el Info equivalente generado, y dejar sólo los parámetros Object. Esta segunda opción es más eficiente, ya que evita enviar información duplicada, pero en lenguajes como PowerBuilder no funciona correctamente. La integración directa con los Web Services de ASF obliga a las aplicaciones cliente a implementar toda la lógica de invocación a Web Services. Además, en caso de ser necesaria la firma de las invocaciones, obliga a las aplicaciones a realizar las firmas. ASF dispone de un agente de seguridad que facilita la integración de aplicaciones cliente J2EE. Dicho agente oculta la complejidad de las invocaciones Web Services y ofrece un sencillo API. Las aplicaciones cliente simplemente debe importar la librería que contiene el agente de seguridad, e invocar a funciones del API. El agente de seguridad, además, se encarga de firmar las invocaciones si así se le indica. Los pasos a seguir para invocar a ASF a través del agente de seguridad están descritos en el documento TBS_ASFv3.5_Manual de integración Agente de seguridad_20060222_v1.0.doc. Revisión: 1.4 19

2.3.3_ Invocaciones locales a los Web Services de ASF Los módulos que publican Web Services pueden ser accedidos también a través de invocaciones locales. En ese caso, las aplicaciones cliente simplemente deben importar las clases a utilizar, e invocar a funciones del API. La funcionalidad es la misma que si el acceso es a través de Web Services, salvo el control de acceso. No se puede restringir el acceso por IP ni firmando las invocaciones, pero el acceso es más eficiente. Los pasos a seguir para invocar a ASF a través de invocaciones locales son los siguientes: ASF debe residir en la misma máquina que la aplicación que va a invocarlo. La aplicación invocante debe incluir en su CLASSPATH todas las librerías y ficheros de propiedades (carpeta propertyfiles) de ASF (carpetas WEB-INF/lib y WEB-INF/classes). Crear el objeto de interfaz del módulo que desea invocar (paquete webservice del módulo a invocar). Realizar la invocación. Ejemplo: Inclusión de las librerías y ficheros de propiedades (carpeta propertyfiles) de ASF dentro del CLASSPATH de la aplicación cliente. Importar la clase webservice y las clases de asf_data.jar implicadas en la invocación: <%@ page import = " jfactory.exchange.resultinfo, java.util.arraylist, com.tbsolutions.asf.demo.util.util, com.tbsolutions.asf.signatureserver.sa.resultsigninfo, com.tbsolutions.asf.x509validator.sa.resultverifycertinfo, com.tbsolutions.asf.signatureserver.sa.paramssigninfo, com.tbsolutions.asf.util.constants, com.tbsolutions.asf.signatureserver.webservice.signatureserver" contenttype="text/html; charset=iso-8859-1"%> Revisión: 1.4 20

Creación del objeto webservice que desea invocar SignatureServer signatureserver = new SignatureServer(); Invocación: ParamsSignInfo params = new ParamsSignInfo(); params.setapplicationid("1"); params.setoperationtypeid("2"); params.setdetached(false);. ResultSignInfo result=signatureserver.signs(params,"1"); Revisión: 1.4 21

2.3.4_ Integración del Módulo Gestor de Políticas (PolicyManager) La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. 2.3.5_ Integración del Módulo de Validación de Certificados (X509Validator) La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. 2.3.6_ Integración del Módulo Servidor de Firmas (SignatureServer) La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. 2.3.7_ Integración del Módulo Servidor de Cifrado (EncryptionServer) La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. 2.3.8_ Integración del Módulo TimeStampClient La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. 2.3.9_ Integración del Módulo NonRepudiationService La información completa de los métodos disponibles en este módulo está recogida en la documentación en formato javadoc. Revisión: 1.4 22

2.4_ Integracion de Módulos sin Web Services 2.4.1_ Integración con el módulo TimeStampServer La integración con este módulo viene especificada por el RFC 3161. Las peticiones y respuestas deben codificarse siguiendo la normativa DER específica para la sintaxis ASN.1. De entre los posibles métodos de transporte definidos por el RFC se ha implementado el método basado en HTTP (HyperText Transfer Protocol). Este protocolo define dos objetos MIME para ser intercambiados: Content-Type: application/timestamp-query <<the ASN.1 DER-encoded Time-Stamp Request message>> Content-Type: application/timestamp-reply <<the ASN.1 DER-encoded Time-Stamp Response message>> 2.4.2_ Integración con el módulo OCSPResponder La integración con este módulo viene especificada por el RFC 2560. Revisión: 1.4 23