![Cerrar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Sección 2. Explorar el servicio de correo electrónico seguro
El servicio de correo electrónico seguro
La Parte 1 de este tutorial explicó el funcionamiento de las clases de stub de WSA considerando dos aplicaciones de muestra llamadas “servicio de correo electrónico simple” y “servicio de correo electrónico extendido”. Discutimos estas aplicaciones de muestra en detalle y concluimos la Parte 1 de este tutorial introduciendo un nombre de “servicio de correo electrónico seguro”, que es una forma segura del servicio de correo electrónico extendido.
El archivo WSDL para el servicio de correo electrónico seguro se incluyó en la Parte 1. Comencemos con una explicación de cómo el WSDL del servicio de correo electrónico seguro (ver Parte 1, Listado 23) es diferente del archivo WSDL del servicio de correo electrónico extendido (ver Parte 1, Listado 19.)
Servicio de correo electrónico seguro frente a extendido
Tanto el servicio de correo electrónico seguro como extendido definen dos
operaciones de servicio web, getSubjects y getMessage.
Hay sólo dos diferencias entre los archivos WSDL de los dos servicios de correo electrónico:
1. La sección de tipos de datos de archivo WSDL para el servicio de correo
electrónico seguro contiene la definición de un elemento Signature..
El elemento Signature se ha copiado al Listado 1. El
elemento Signature lleva la información de
autenticación del usuario que intenta acceder al servicio de correo electrónico
seguro. El servicio de correo electrónico extendido no tenía el elemento Signature.
Listado 1. Definición del elemento Signature (Firma) para el servicio de correo electrónico seguro
|
Discutiremos el elemento Signature más adelante en la
sección Clases de stub para el tipo complejo de
Signature.
2. Las llamadas de invocación de métodos getSubjects y getMessage del servicio de
correo electrónico necesitan llevar una instancia del elemento Signature.
La instancia Signature se usará del lado del servidor para la autenticación. Esto
se refleja en la sección de tipo de datos del archivo WSDL del servicio de
correo electrónico seguro. Usted ya vio los tipos de datos de un archivo WSDL en
la sección “WSDL components of the hotel Web service” [Componentes WSDL del
servicio web de hotel] de la Parte 1.
El Listado 2 muestra la sección de tipos de datos del archivo WSDL de su servicio de correo electrónico seguro.
Listado 2. Sección de tipos de datos del archivo WSDL para el servicio de correo electrónico seguro
|
Observe que el elemento Signature aparece como elemento
secundario de las definiciones de tipos de complejo getSubjects y getMessage del Listado 2. La llamada de invocación de método getSubjects llevará el tipo de complejo getSubjects y el método getMessagellevará el tipo de complejo getMessage. Como el elemento Signature es
parte de ambos tipos de complejo, aparecerá en ambas llamadas de invocación de
método.
Simplificación del elemento Signature
Usamos la especificación XML Digital Signature (XMLDS) de W3C para incorporar las características de autenticación en aplicaciones WSA.
Una limitación de WSA al usar XMLDS se describe en la sección “Una limitación importante de WSA” de la Parte 1. La sección “Superar la limitación de WSA” de la Parte 1 explica cómo superar la limitación de WSA.
También introdujimos las siguientes simplificaciones al definir el elemento Signature en el Listado 1.
- La definición original del elemento
Signatureen XMLDS tienen muchos puntos de extensibilidad que permiten que los elementos de otros espacios de nombres y esquemas estén incrustados en un elementoSignature.
Por ejemplo, XMLDS especifica un elementoxsd:Anydentro de su elementoKeyInfo, lo que significa que un documento de instancia puede contener cualquier elemento dentro de un elementoKeyInfo.
En la definición de Signature del Listado 1, se han quitado todos los puntos de extensibilidad del elementoSignature. Esto se debe a que el cliente J2ME necesita componer una estructura fija y por lo tanto no necesita extensibilidad. - XMLDS incluye una variedad de elementos para cubrir diferentes escenarios de
aplicaciones. Por ejemplo, el elemento secundario
KeyInfodel elementoSignaturelleva información acerca de qué clave se usó para firmar un mensaje. XMLDS define varios tipos de elementos que se pueden colocar dentro del elementoKeyInfo. Dos de tales elementos sonKeyNameyX509Data.
El elementoKeyNamecontiene el nombre de una clave. Por lo tanto, si usted desea identificar sus claves criptográficas por nombre, deberá usar el elementoKeyName.
Si, por el contrario, usted quiere usar certificados X509 en lugar de nombres de clave, puede usar un elementoX509Dataen lugar de un elementoKeyName. El elementoX509Datacontendrá los datos del certificado en lugar del nombre de clave.
En esta serie de tutoriales usamos exclusivamente los nombres de clave para
identificar claves criptográficas. Por lo tanto, el tipo complejo de Signature del Listado 1 sólo
permite colocar un elemento, (KeyName), dentro de un
elemento KeyInfo.
En resumidas cuentas, estamos tratando de simplificar el cliente WSA seguro sin comprometer su interoperabilidad con XMLDS.
Solicitudes SOAP seguras para el servicio de correo electrónico seguro
Mire el Listado 3, que muestra una solicitud SOAP segura
(o una llamada de invocación de método SOAP seguro) para operaciones
getSubjects.El Listado 3 contiene una instancia del
elemento Signature según la definición Signature del Listado 1.
Listado 3. Solicitud SOAP segura para una operación getSubjects
|
El Listado 3 muestra tanto la estructura como los datos
contenidos en la solicitud SOAP getSubjects. Examine
las porciones del Listado 3 que se muestran en negrita.
Éstas son las únicas porciones que se componen dinámicamente para cada
solicitud getSubjects. El resto de la estructura
será el mismo en todas las solicitudes getSubjects.
A continuación figura una explicación de cada una de las porciones dinámicas que se muestran en negrita en el Listado 3.
- Contenido del elemento
senderEmailAddress, que especifica la dirección de correo electrónico del remitente que usted está buscando. - Contenido del elemento
DigestValue, que representa la forma codificada en base 64 de un valor implícito. Discutiremos el procedimiento para calcular el valor implícito en la sección Implementación del algoritmo implícito SHA-1 en J2ME y los detalles de la codificación en base 64 en la parte siguiente de este tutorial. - Contenido del elemento
SignatureValue, que representa la forma codificada en base 64 de una firma criptográfica. Discutiremos los detalles del cálculo del valor de firma en la parte siguiente de este tutorial. - Contenido del elemento
KeyName, que especifica el nombre de la clave criptográfica usada para firmar el mensaje. La autoría del elementoKeyNamese explica en la sección Creación de una instancia GetSubjectsSignatureKeyInfo.
De manera similar, examinemos la solicitud SOAP segura para la operación getMessage que se muestra en el Listado 4. Usted puede identificar fácilmente las secciones
dinámicamente compuestas del Listado 4 que se muestra en
negrita.
Listado 4. Solicitud SOAP segura para la operación getMessage
|
Ahora que hemos discutido el archivo WSDL y las solicitudes SOAP para el servicio de correo electrónico seguro, es el momento de generar clases de stub para el servicio de correo electrónico seguro.
Usted puede usar una herramienta generadora de clases de stub para generar clases de stub para el archivo WSDL del servicio de correo electrónico seguro. Para su conveniencia, usted encontrará el archivo WSDL acompañado de su código fuente de clases de stub en la sección Descargas de este tutorial.
Clases de stub para el servicio de correo electrónico seguro
El generador de stub genera un total de diez clases para el servicio de correo
electrónico seguro. Cuatro de las diez clases (GetMessage, GetSubjects, SubjectsList y Message)
representan parámetros de entrada y salida de las operaciones getSubjects y
getMessage. La herramienta generadora de stub nombra estas cuatro clases según
los nombres de los elementos del tipo de complejo en el archivo WSDL.
El resto de las clases son:
- SecureMobileEmailService_PortType
- SecureMobileEmailService_PortType_Stub
- Signature
- GetSubjectsSignatureKeyInfo
- GetSubjectsSignatureSignedInfo
- GetSubjectsSignatureSignedInfoReference
SecureMobileEmailService_PortType es una interfaz
similar a la interfaz ExtendedMobileEmailService_PortType que usted vio antes en la sección
“Clases de stub para el servicio de correo electrónico extendido” de la Parte 1 que contiene definiciones getSubjects() y métodos getMessage().
SecureMobileEmailService_PortType_Stub implementa los
métodos getSubjects() y getMessage(). Esto significa que SecureMobileEmailService_PortType_Stub contiene el código que usa
clases e interfaces WSA para:
- comunicarse en forma segura con el servicio de correo electrónico remoto,
- capturar y analizar la respuesta del servicio remoto, y
- devolver los resultados a la aplicación de llamada.
Como podrá adivinar, SecureMobileEmailService_PortType_Stub es la más importante de todas
las clases de stub. La definiremos como una clase “de stub de servicio seguro”.
Usted verá cómo modificar (o mejorar) esta clase más adelante en la sección Mejorar la clase de stub de servicio seguro.
Pero presentemos primero las cuatro clases restantes (Signature, GetSubjectsSignatureSignedInfo, GetSubjectsSignatureSignedInfoReference y GetSubjectsSignatureKeyInfo), que representan el tipo de
complejo Signature que se muestra en el Listado 1.
Clases de stub para el tipo de complejo Signature
Examine la clase Signature, que se ha copiado alListado 5 para una sencilla referencia.
Listado 5. Clase de Signature
public class Signature {
protected secure.GetSubjectsSignatureSignedInfo signedInfo;
protected java.lang.String signatureValue;
protected secure.GetSubjectsSignatureKeyInfo keyInfo;
public Signature() {
}
public Signature(secure.GetSubjectsSignatureSignedInfo signedInfo,
java.lang.String signatureValue,
secure.GetSubjectsSignatureKeyInfo keyInfo) {
this.signedInfo = signedInfo;
this.signatureValue = signatureValue;
this.keyInfo = keyInfo;
}
public secure.GetSubjectsSignatureSignedInfo getSignedInfo() {
return signedInfo;
}
public void setSignedInfo(
secure.GetSubjectsSignatureSignedInfo signedInfo) {
this.signedInfo = signedInfo;
}
public java.lang.String getSignatureValue() {
return signatureValue;
}
public void setSignatureValue(java.lang.String signatureValue) {
this.signatureValue = signatureValue;
}
public secure.GetSubjectsSignatureKeyInfo getKeyInfo() {
return keyInfo;
}
public void setKeyInfo(
secure.GetSubjectsSignatureKeyInfo keyInfo) {
this.keyInfo = keyInfo;
}
}
|
La clase Signature comprende todo el contenido que
contendrá una instancia de tipo de complejo Signature como el elemento Signature del mensaje
SOAP del Listado 3. La clase Signature no contiene un código de autoría o procesamiento para los
datos que comprende.
El procesamiento lógico propiamente dicho de la estructura XML de la firma se implementa en la clase de stub de servicio seguro.
La clase Signature contiene dos constructores; un
constructor predeterminado sin argumento y un constructor de tres argumentos. El
constructor de tres argumentos toma tres objetos, que se convierten en miembros
de datos de la clase Signature:
- En primer lugar, hay una instancia de la clase
GetSubjectsSignatureSignedInfo, que es otra clase de stub que representa el tipo de complejo SignedInfo definido en la estructuraSignaturedel Listado 1. - En segundo lugar, hay una cadena
signatureValueque representa la forma codificada en base 64 de una firma criptográfica. - Finalmente, hay una instancia de clase
GetSubjectsSignatureKeyInfo, una clase de stub que representa el elementoKeyInfodel Listado 1.
La clase Signature tiene métodos establecedores y
captadores para establecer y captar sus tres miembros de datos. Hemos mostrado a
la clase Signature junto con sus miembros de datos como
una estructura de una caja dentro de otra en la Figura
1.
Figura 1. Clase de firma con sus miembros de datos
Usted puede extender la Figura 1 para incluir miembros de datos de los miembros de datos de la firma. Usted obtendrá algo así como la Figura 2, que muestra en detalle cómo las clases de stub mantienen a otras clases de stub, así como a los tipos de datos primitivos y sus miembros de datos. Todos los nombres de clases de la Figura 2 se muestran en negrita mientras que los miembros de datos de tipo primitivo se muestra en cursiva.
Usted puede encontrar las cuatro clases de stub relacionadas con la firma en la Figura 2.
Figura 2. La estructura de firma completa
Observe que los nombres de clases generados por la herramienta generadora de stub son bastante extensos y contienen nombres de diferentes tipos de complejos en el archivo WSDL.
Por ejemplo, el nombre de clase GetSubjectsSignatureSignedInfo contiene nombres de todos los
antecesores (GetSubjects y Signature) del elemento SignedInfo del archivo WSDL del Listado 1.
En aras de conveniencia, no usamos los nombres completos de clase GetSubjectsSignatureSignedInfo, GetSubjectsSignatureSignedInfoReference y GetSubjectsSignatureSignedInfoKeyInfo en la discusión de este
tutorial. En su lugar, usamos las clases SignedInfo, Reference y KeyInfo, respectivamente.
Ahora que hemos presentado las clases de stub del servicio de correo electrónico seguro, explicaremos y demostraremos la estrategia para mejorar estas clases de stub en la siguiente sección.
Tabla de contenidos
- Antes de comenzar
- Sección 2. Explorar el servicio de correo electrónico seguro
- Sección 3. Mejorar las clases de stub de servicio seguro
- Sección 4. Mejorar las clases de stub de la firma
- Sección 5. Mejorar la clase SignedInfo
- Sección 6. Componer la forma canónica de datos XML
- Sección 7. Implementar el algoritmo implícito SHA-1 en J2ME
- Sección 8. Conclusión
- Descargar
- Recursos
- Sobre el autor