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
Introducción...................................................................................................... 3
1_
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
Integración de ASF........................................................................................ 11
2_
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
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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:
Título:
Revisión:
Fecha:
•
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.
Manual de integración de ASF
1.4
junio de 2006
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 SignOn (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
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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:
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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:
Título:
Revisión:
Fecha:
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.
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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);
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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));
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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));
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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
•
Imports
Imports
Imports
Imports
Imports
Imports
Creación de clase de acceso al Web Service:
System
System.ComponentModel
System.Diagnostics
System.Web.Services
System.Web.Services.Protocols
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
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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:
Título:
Revisión:
Fecha:
•
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.
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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"%>
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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");
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
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.
Título:
Revisión:
Fecha:
Manual de integración de ASF
1.4
junio de 2006
23