Integración de la seguridad de WS-Policy entre DataPower y WebSphere Application Server

Este artículo le muestra cómo configurar WebSphere DataPower SOA Appliance y WebSphere Application Server para implementar la WS-Policy para la gobernabilidad de servicios SOA. Las credenciales de usuario se transforman en un formato común de token LPTA con propósitos de autorización e inicio de sesión único entre DataPower y una aplicación que se encuentra en WebSphere Application Server. Al poner la gestión de la directiva en manos de DataPower, se logra que WebSphere Application Server ofrezca una mejor funcionalidad a nivel de la aplicación, mientras que DataPower ofrece una gobernabilidad del servicio de alto rendimiento y en toda la empresa.

Russell Butek, SOA and Web services consultant, IBM

Russell Butek is an SOA and Web services consultant for IBM. He has been one of the developers of IBM WebSphere Web services engine. He has also been a member the JAX-RPC Java Specification Request (JSR) expert group. He was involved in the implementation of Apache's AXIS SOAP engine, driving AXIS 1.0 to comply with JAX-RPC 1.0.


Nivel de autor contribuyente en developerWorks

John Rasmussen, Senior I/T Specialist, IBM Software Services for WebSphere, IBM

John Rasmussen is a Senior IT Specialist, WebSphere DataPower and SOA, with IBM in Cambridge, MA. You can contact John at rasmussj@us.ibm.com.



29-07-2011

Introducción

Las solicitudes de recursos empresariales se han expandido y, actualmente, abarcan clientes organizacionales confiables y otros clientes desconocidos que se encuentran en lugares remotos. El éxito de SOA ha provocado la publicación de aplicaciones empresariales en la forma de servicios que se descubrirán y procesarán de manera dinámica.

Las especificaciones SOA, como Lenguaje de Aplicación de servicios web (WSDL), han definido la estructura del método de aplicación, mientras que se han creado mecanismos, como IBM®WebSphere®Registry and Repository o Universal Description Discovery and Integration (UDDI), para publicitar las ubicaciones de los servicios y los requisitos necesarios para ejecutarlos. Los servicios que solían encontrarse en estructuras de programación de aplicaciones predefinidas y predeterminadas ahora son accesibles en una forma de acoplamiento holgado.

Esta exposición de recursos ha estado acompañada por un esfuerzo necesario para garantizar una autenticación muy robusta. La especificación WS-Security ha evolucionado y, en la actualidad, soporta el uso de Security Assertion Markup Language (SAML), certificados X.509, tickets de Kerberos y Username y otras formas de transmisión de identidad dentro de un estándar de metadatos unificado que ofrece estandarización para autenticación y autorización.

A medida que estas herramientas fueron evolucionando, los proveedores de servicios comenzaron a buscar una forma para establecer una gobernabilidad organizacional y directivas organizacionales que no dependan ni de la aplicación ni de la plataforma. El protocolo WS-Policy y las especificaciones que lo respaldan (como, por ejemplo, Web Service Policy Framework, Policy Attachment, WS-SecurityPolicy y WS-ReliableMessagingPolicy), buscan establecer una metodología unificadora que se pueda descubrir y consumir a medida que se vayan descubriendo servicios. De esta forma, el acceso a grupos de servicios se puede controlar en masa en vez de en forma individual.

WS-Policy describe la seguridad y la calidad de los requisitos de servicio en una máquina y en un formato que todas las personas pueden leer, lo que facilita la creación automatizada de solicitudes de servicio. Se pueden tomar decisiones de tiempo de diseño con el objetivo de garantizar que las credenciales adecuadas se transfieran al servicio. Se pueden tomar decisiones de tiempo de ejecución en el caso de las autorizaciones de solicitudes individuales. Y lo que resulta todavía más importante es que WS-Policy no define la implementación de las aserciones sino que define los metadatos que publicitan la aserción (describiendo, por ejemplo, que un servicio requiere un nombre de usuario). La implementación de Policy Decision Point (PDP) se ocupa de interpretar los metadatos de WS-Policy con el objetivo de realizar la aserción real de la existencia del Username Token (UNT).

Este artículo le muestra la implementación de WS-Policy para la gobernabilidad de los servicios SOA por medio de la implementación y el cumplimiento de una configuración PDP dentro de WebSphere DataPower®SOA Appliance (DataPower). DataPower intercambiará la información de identidad con una aplicación que se encuentra en WebSphere Application Server. Al poner la gestión de la directiva en manos de DataPower, WebSphere Application Server logra una mayor capacidad para ofrecer una mejor funcionalidad a nivel de la aplicación, mientras que DataPower ofrece una gobernabilidad del servicio de alto rendimiento y en toda la empresa.

Introducción al token LTPA

Se suelen usar tokens para transmitir la identidad dentro del tráfico del mensaje. Algunos ejemplos de tokens son SAML, el certificado X.509 y los tickets de Kerberos. Los tokens se pueden gestionar y distribuir por medio de Secured Token Services (STS), como se lo describe en la especificación WS-Trust.

Los productos IBM WebSphere e IBM Lotus Domino usan tokens Lightweight Third-Party Authentication (LTPA). Los tokens LTPA incluyen una identidad firmada y encriptada simétricamente usando una clave que tiene fecha de vencimiento y se comparte con entidades confiables. Este procedimiento le ofrece una confidencialidad eficiente sin la típica fase de creación de clave de sesión que establece una clave efímera para la encriptación simétrica que usan las tecnologías de encriptación asimétrica (como, por ejemplo, SSL / TLS). La clave compartida (secreto compartido) se debe comunicar entre estas partes confiables antes de su uso. El token LTPA también se usa para ofrecer un inicio de sesión único (SSO) dentro o entre celdas de WebSphere Application Server.

Los tokens LTPA se pueden transferir entre procesos y aplicaciones WebSphere Application Server por medio de encabezados cookie HTTP o dentro de un WS-Security Binary Security Token. Su naturaleza encriptada le ofrece la confidencialidad necesaria para proteger la información de identidad incluida.

Existen diversas versiones del token LTPA. Los tokens versión 1 incluyen información de identidad y dominio. El dominio se usa para asociar el registro de usuario que WebSphere Application Server usa para la autenticación. Los tokens versión 2, que son más nuevos, se introdujeron en WebSphere Application Server V6 para ejecutar atributos personalizados. Pero recuerde que es necesario realizar una programación personalizada para acceder a ellos o usarlos.

Cuando una aplicación WebSphere Application Server o Domino recibe un token LTPA, no es necesario volver a autenticar el usuario. Sin embargo, es posible que todavía necesite acceder al registro de usuario para crear un objeto Subject (Sujeto) completo que incluya información, como las asociaciones de grupo.

DataPower Appliance puede decodificar y usar la identidad LTPA y crear tokens LTPA nuevos. El producto IBM Tivoli Access Manager WebSEAL también le ofrece esta capacidad. La clave secreta compartida se debe gestionar entre las aplicaciones DataPower y WebSphere Application Server y se deben tratar ciertos temas como, por ejemplo, el período de vigencia de la clave en cuestión. Las características de WebSphere Application Server (como, por ejemplo, la generación automática de clave), pueden provocar fallas en la decodificación si no se comunica la clave nueva de manera adecuada. Por lo tanto, es probable que sea más conveniente gestionar la generación de claves por medio de un proceso programado o mediante la intervención manual. Debido a sus características de rendimiento y soporte en WebSphere Application Server y DataPower, se suelen usar los tokens LTPA cuando DataPower se encuentra antes de los servidores WebSphere Application Server.

Aplicación de muestra

DataPower cumple una función muy valiosa dentro de un típico entorno de aplicación. Mediante el uso de su funcionalidad criptográfica optimizada para el hardware utilizado y creada con un propósito específico, DataPower puede transferir las operaciones que usan al procesador de manera intensiva (como, por ejemplo, la verificación de la integridad de la firma digital y la encriptación y la decodificación de mensajes con fines de confidencialidad). Al delegar este procesamiento intensivo, la aplicación puede realizar el procesamiento del mensaje (que es para lo que se la diseñó) de manera más eficiente.

Los clientes pueden realizar solicitudes de servicios que requieren información de credenciales con el objetivo de autenticar y autorizar el acceso a la aplicación. Se diseñó DataPower para que autentique una gran variedad de tokens de identidad (incluyendo a los certificados X.509, los tokens WS-Security Username, los certificados SSL y los encabezados Basic Authentication). La autorización se puede realizar contra repositorios (como, por ejemplo, directorios LDAP) o por medio de aplicaciones (como, por ejemplo, IBM Tivoli Access Manager).

La aplicación de muestra combina la autenticación con el cumplimiento por medio de las directivas WS-Policy. A continuación, la Figura 1 le muestra una topología en la que los clientes deben enviar solicitudes que incluyan tokens WS-Security Username a través de SSL con el objetivo de garantizar la confidencialidad de la información de identidad. Las identidades se autentican y autorizan para el acceso a la aplicación. Se asigna una identidad de grupo a todos los usuarios autenticados. Esta identidad de grupo se almacena en un token LTPA firmado. Este token se encripta simétricamente usando un secreto compartido entre DataPower y WebSphere Application Server. La encriptación simétrica son órdenes de magnitud más rápida que la asimétrica.

Figura 1. Arquitectura de la aplicación de muestra
Arquitectura de la aplicación de muestra

Una vez que WebSphere Application Server recibe el token LTPA, realiza la decodificación usando el secreto compartido, extrae la información de identidad que incluye el token y la usa para autenticar la solicitud y establecer una identidad JEE. Esta aplicación simple sólo hace eco de una cadena que se incluye dentro del mensaje de solicitud y agrega la identidad JEE provista por el tiempo de ejecución.

Las implementaciones PDP con DataPower y WebSphere Application Server se usan para garantizar el cumplimiento. Dentro de DataPower, una directiva valida la existencia de un token WS-Security Username. Dentro de WebSphere Application Server, una directiva verifica el requisito de un token LPTA dentro de los metadatos del mensaje de solicitud. Nuestro ejemplo comienza con la configuración de WebSphere Application Server. Luego de esto, se realiza la implementación de DataPower.

Configuración de WebSphere Application Server

Esta sección le muestra cómo configurar un proveedor de servicios web WebSphere Application Server V7 para consumir un token LTPA e identificarlo como el contenedor de la identidad del usuario que solicita el servicio.

La configuración de la calidad del servicio web en WebSphere Application Server V7 se realiza por medio de enlaces y conjuntos de directivas. La terminología de la directiva de WebSphere Application Server es levemente diferente de la terminología de WS-Policy. A lo que WebSphere Application Server denomina como una directiva, WS-Policy lo denomina como una expresión de directiva (es decir, una colección de metadatos que describe una regla o un requisito para un servicio). WebSphere Application Server también usa el término conjunto de directivas (que simplemente hace referencia a una colección de instancias de directivas). WebSphere Application Server cuenta con diversas directivas (como, por ejemplo, transporte HTTP, WS-Security y WS-Addressing). Los conjuntos de directivas combinan directivas en entidades únicas y configurables. Por ejemplo, uno de los paquetes de conjuntos de directivas de WebSphere Application Server (el conjunto de directivas predeterminado Kerberos V5 HTTPS) consiste de instancias de directivas de transporte SSL, WS-Security y WS-Addressing).

Un conjunto de directivas le indica lo que es la configuración, pero no le indica cómo lograr esto. Por ejemplo, le indica que se debe encriptar el cuerpo de una solicitud SOAP, pero no le indica cómo hacer esto (es decir, no le indica los keystores de certificados). Para esto sirve el enlace (que es la entidad que completa con la información de la variable, como los keystores).

Gracias a esta breve introducción, usted puede observar que existen tres entidades en WebSphere Application Server con las que usted trabajará: un conjunto de directivas, un enlace y la aplicación. Usted adjunta un conjunto de directivas a una aplicación y, luego de esto, asigna un enlace a dicha aplicación. El resto de esta sección le muestra cómo crear un conjunto de directivas, cómo crear un enlace, cómo adjuntar el nuevo conjunto de directivas a una aplicación y cómo asignar el enlace a la misma aplicación.

Creación del conjunto de directivas LTPA

Usted podría crear un conjunto de directivas desde cero, pero WebSphere Application Server le ofrece paquetes que incluyen una gran cantidad de conjuntos de directivas y una de estas se parece mucho al que usted necesita: LTPA WSSecurity. Por lo tanto, en vez de crear un conjunto de directivas, usted puede hacer una copia del conjunto predeterminado y modificarlo según sus necesidades. El conjunto de directivas predeterminado LTPA WSSecurity trabaja con un token LTPA, que es exactamente lo que usted necesita. Por otra parte, también firma y encripta el mensaje (cosa que usted no necesita). En vez de firmar el mensaje, usted permitirá que SSL realice la encriptación. A continuación, la Figura 2 le muestra la sección de la Administrative Console (Consola Administrativa) desde donde usted dará comienzo a la copia:

  1. Navegue a Services (Servicios) => Policy sets (Conjuntos de directivas) => Application policy sets (Conjuntos de directivas de aplicación).
  2. Seleccione LTPA WSSecurity y haga clic en Copy (Copiar).
  3. En el siguiente panel, seleccione el nombre de su nuevo conjunto de directivas (LTPA over SSL).
  4. Ingrese la descripción que elija y, luego de esto, haga clic en OK:
    Figura 2. Copiado del paquete del conjunto de directivas LTPA
    Copiado del paquete del conjunto de directivas LTPA

Luego de crear su copia, usted la podrá ven en la lista de conjuntos de directivas (como se puede observar en la Figura 3). Los paquetes de conjuntos de directivas no se pueden editar, pero su nuevo conjunto de directivas denominado LTPA over SSLeseditable. Haga clic en LTPA over SSL para editarlo. Aparecerá la ventana que se puede observar en la Figura 4.

Figura 3. Edición de la copia
Edición de la copia

La Figura 4 le muestra que su conjunto de directivas consiste de dos instancias de directiva: WS-Addressing y WS-Security. Usted debe agregar SSL a la configuración:

  1. Haga clic en Add pull-down menu (Agregar menú desplegable).
  2. Seleccione SSL transport (Transporte SSL) desde la lista de directivas disponibles.

Usted puede examinar su nueva instancia de la directiva SSL haciendo clic en ella. Los valores predeterminados son más que suficientes. No es necesario hacer nada más para activar SSL.

Figura 4. Edición del conjunto de directivas
Edición del conjunto de directivas

Ahora, usted debe editar la instancia de directiva WS-Security. Desde la ventana que se puede observar en la Figura 4, navegue a WS-Security => Main policy (Directiva principal):

Figura 5. Eliminación de la protección del mensaje
Eliminación de la protección del mensaje

Lo que hacemos aquí es apagar la protección a nivel del mensaje deseleccionando la casilla correspondiente. Esto no tiene nada que ver con la protección WS-Security y con la firma. Lo que hacemos en confiar en SSL para que se ocupe de la encriptación. Eso es todo lo que tenemos que modificar en su versión del conjunto de directivas LTPA.

Creación del enlace

WebSphere Application Server incluye paquetes de enlaces predeterminados. El enlace predeterminado funciona así como está para el conjunto de directivas denominado LTPA over SSL: El motor de SOAP valida y consume el token LTPA y la llamada al proveedor de servicios web es exitosa. Sin embargo, queremos ir más allá. Al usar el enlace predeterminado, el motor de SOAP consume la identidad (es decir que no se la transfiere a la implementación del servicio web). Nosotros deseamos que la identidad del usuario que realiza la llamada (es decir, la identidad que figura dentro del token LTPA) se transfiera a la implementación. Por lo tanto, necesitamos algo más que lo que ofrece el enlace predeterminado.

Podríamos crear un enlace desde cero, pero eso significaría volver a crear una gran parte de la configuración que ya forma parte del enlace predeterminado. Por lo tanto, realizaremos una copia y la editaremos. Para realizar una copia del enlace predeterminado, haga lo siguiente:

  1. Navegue a Services => Policy sets => General provider policy set bindings.
  2. Haga una copia de Provider sample (Muestra del proveedor) de la misma forma en la que copió el conjunto de directivas LTPA predeterminado y colóquele el siguiente nombre: Demo provider sample.
  3. En este momento, a modo de paso opcional, si desea ahorrar algo de tiempo en el futuro, usted puede configurar Demo provider sample para que sea el enlace predeterminado. Navegue a Services => Policy sets => Default policy set bindings (Enlaces del conjunto de directivas predeterminados) y configure Demo provider sample como el enlace predeterminado.
  4. Para realizar nuestra modificación, pase a la instancia de la directiva WS-Security del enlace nuevo. En primer lugar, podrá observar el panel que se encuentra hacia la izquierda:
    Figura 6. Creación del llamador
    Creación del llamador
  5. El llamador define qué token usar (en caso de usar alguno) como ID del llamador en la implementación. Un mensaje puede incluir algunos tokens o ninguno. En nuestro caso, incluirá uno. Pase al próximo panel haciendo clic en Caller (Llamador). De manera predeterminada, usted puede observar que no hay ninguna identidad de llamador. Para agregar una, haga clic en New (Nuevo):
    Figura 7. Configuración del llamador
    Configuración del llamador
  6. En esta ventana, ingrese cualquier nombre para el llamador (no es un dato realmente importante). Sin embargo, los valores de los próximos dos campos son muy importantes (tenga cuidado con los errores tipográficos). Estos dos campos definen el nombre completamente calificado del token desde el mensaje a usar como identidad del llamador. Además, estos valores deben corresponderse en su totalidad con los valores que figurarán en el mensaje SOAP. Haga clic en Apply (Aplicar).

Es probable que se pregunte exactamente dónde puede encontrar los valores adecuados para los campos local part (parte local) y namespace (espacio de nombre). Para este artículo, ya los hemos provisto. ¿Pero cuáles son los valores si usted desea usar otros tipos de token? Si memorizó en detalle las páginas del centro de información sobre estos temas y las diversas especificaciones de WS-Security, usted simplemente sabrá cuales son. Pero la mayoría de nosotros no puede retener toda esa información. Por lo tanto, hay un lugar en la consola de administración donde el asistente ingresa estos valores por usted. Usted puede usar esa página a modo de referencia:

  1. Navegue a un enlace que tenga una directiva WS-Security.
  2. Navegue desde dicho enlace hasta WS-Security => Authentication and protection (Autenticación y protección) => New token (Token nuevo) (debajo de Authentication tokens [Tokens de autenticación]) => Token generator (Generador de token).
  3. Seleccione el tipo de token deseado.
  4. El asistente completa los campos "Local part" (Parte local) y "Namespace URI" (URI del espacio de nombre), como se puede observar en la Figura 8 a continuación. Estos campos corresponden a los campos "Caller identity local part" (Parte local de identidad del llamador) y "Caller identity namespace URI" (URI del espacio de nombre de identidad del llamador), respectivamente, como se puede observar en el panel que se encuentra en la Figura 7 con anterioridad.
    Figura 8. Búsqueda del nombre completamente calificado de un tipo determinado de token
    Búsqueda del nombre completamente calificado de un tipo determinado de token

¿Cómo se adjunta el conjunto de directivas?

En las secciones anteriores, usted creó un conjunto de directivas y un enlace. Ahora, usted debe configurar una aplicación con dicho conjunto de directivas y enlace. Para este ejemplo, use una variante de la muestra EchoService (que forma parte de las muestras JAX-WS que se incluyen en WebSphere Application Server). Si optó por no instalar las muestras cuando instaló WebSphere Application Server, puede usar la versión de la muestra que se incluye en este artículo.

  1. Navegue a Services (Servicios) => Service providers (Proveedores de servicios) => EchoService, como se puede observar en la Figura 9 a continuación.
  2. Seleccione EchoService.
  3. Haga clic en Attach Policy Set (Adjuntar conjunto de directivas) y seleccione el conjunto de directivas que acaba de crear desde el menú desplegable:
    Figura 9. ¿Cómo se adjunta nuestro conjunto de directivas LTPA a la aplicación proveedora?
    ¿Cómo se adjunta nuestro conjunto de directivas LTPA a la aplicación proveedora?

Luego de realizar estos pasos, el conjunto de directivas denominado LTPA over SSL aparece como el conjunto de directivas adjuntado y el enlace será el enlace predeterminado.

Asignación del enlace

Si usted configura el enlace Demo provider sample (Muestra de demostración del proveedor) para que sea su enlace predeterminado, no tendrá que hacer nada más. El enlace predeterminado se asigna automáticamente. Si no lo configuró como enlace predeterminado, haga lo siguiente:

  1. Seleccione el servicio en la ventana que aparece en la Figura 9 con anterioridad.
  2. Haga clic en Assign Binding (Asignar enlace) para desplegar el menú de enlaces.
  3. Seleccione Demo provider sample.

La aplicación que se usó en este artículo

Como ya lo hemos mencionado, la aplicación que se usó en este artículo es una variación de la aplicación EchoService que forma parte de las muestras que se incluyen en WebSphere Application Server. Usted puede optar por usar la muestra EchoService que se incluye en WebSphere Application Server, pero con esa versión de la aplicación, usted no tendrá forma de verificar si la identidad que figura en el token LTPA llegó al servicio. Para poder demostrar esto, modificamos la aplicación EchoService para que haga eco de la cadena de entrada y de la identidad del llamador (como se puede observar en el resultado a modo de ejemplo que figura en elListado 6en la sección de DataPower que figura a continuación. Por lo tanto, esto demuestra que la identidad realmente viaja desde DataPower hasta la aplicación de WebSphere Application Server. Si desea usar la muestra modificada, la puededescargaral final de este artículo.

Integración de WebSphere Application Server y DataPower: El archivo de clave LTPA

Exportación del archivo de clave LTPA desde WebSphere Application Server

Hasta este momento, usted ha configurado una aplicación WebSphere Application Server para que acepte mensajes de solicitud del token LTPA. El emisor (DataPower en nuestro caso) debe saber algo sobre la configuración LTPA de WebSphere Application Server. Esta información se almacena en un archivo de clave LTPA. Por lo tanto, usted debe exportar el archivo de clave LTPA de manera tal que DataPower lo pueda importar con posterioridad. Para exportar este archivo, haga lo siguiente:

  1. Debajo de Authentication (Autenticación), seleccione Security (Seguridad) => Global security (Seguridad global) => LTPA.
  2. Debajo de Cross-cell single sign-on (Inicio de sesión único de celda transversal), como se puede observar en la Figura 10 a continuación, ingrese la contraseña que desee. Usted deberá recordar esta contraseña para cuando importe el archivo de clave hacia DataPower.
  3. Ingrese un nombre de archivo de clave y haga clic en Export keys (Exportar claves):
    Figura 10. Exportación del archivo de clave LTPA desde WebSphere Application Server
    Exportación del archivo de clave LTPA desde WebSphere Application Server

Hay algo que debe tener en cuenta si exporta claves LTPA. WebSphere Application Server regenera las claves LTPA automáticamente con el paso del tiempo. Cuando usted exporta claves LTPA, en algún momento, las claves que figuran en el archivo exportado dejarán de funcionar. Para que sigan funcionando, usted puede desactivar la generación automática de claves LTPA. Luego de hacer esto, usted deberá gestionar la regeneración de claves por sí mismo en vez de dejar que WebSphere Application Server lo haga por usted.

Para desactivar la generación automática de claves, en la Figura 10, haga clic en Key set groups (Grupos del conjunto de claves) debajo de "Key generation" (Generación de clave) en la parte superior del panel. Luego de esto, haga clic en su grupo del conjunto de claves (que, en este ejemplo, es NodeLTPAKeySetGroup). En el panel que se puede observar en la Figura 11, deseleccione la casilla de verificación denominada Automatically generate keys (Generar claves automáticamente) debajo de "Key generation".

Figura 11. Desactivación de la generación automática de la clave LTPA
Desactivación de la generación automática de la clave LTPA

Importación del archivo de clave LTPA hacia DataPower

Cargue el archivo de clave LTPA en el directorio cert:// de DataPower Appliance. En donde se discute la configuración de DataPower, usted podrá observar como la directiva de Autenticación, Autorización y Auditoría (AAA) del dispositivo crea un token LTPA usando esta clave LTPA.

Configuración de DataPower

Se diseñó DataPower para que actúe como un punto de cumplimiento de directivas (PEP) para WS-Policy, que se lo soporta dentro del objeto de servicio web Service Proxy (WSP). En las versiones 3.7.3 o posteriores del firmware de DataPower, se soportan las siguientes especificaciones de WS-Policy:

  • WS-Policy 1.2 y 1.5
  • Web Service Policy Framework y Policy Attachment 1.5
  • WS-SecurityPolicy 1.2 y 1.5
  • WS-ReliableMessagingPolicy 1.2

WS-Policy Attachment le ofrece soporte para la WS-Policy creada dentro del documento WSDL. Además, se pueden adjuntar directivas a varios sujetos WSDL (como, por ejemplo, mensajes, servicios, enlaces o sujetos de operación que usan la Interfaz Gráfica de Usuario [GUI] WS-Proxy). El soporte para dominios estándar de WS-Policy (como, por ejemplo, WS-Security) se implementa por medio de las plantillas que se encuentran en el directorio store://policies//templates de DataPower Appliance. Allí, usted encontrará plantillas predeterminadas para realizar acciones de directiva estándar (como, por ejemplo, hacer cumplir con las firmas digitales, la encriptación, la presencia del token Username y el uso de protocolos seguros entre otras tantas plantillas de directivas).

En la configuración de DataPower que figura a continuación, usted configurará un WSP para soportar los requisitos de la misma aplicación y su interacción con las restricciones de WS-Policy impuestas por la aplicación de WebSphere Application Server. Éstas son las siguientes:

  • Use WS-Policy para requerir el token Username cuando el cliente lo solicite
  • Requiera transporte seguro cuando el cliente lo solicite
  • Convierta el token Username en el encabezado de WS-Security con el token LTPA

Se asume la configuración básica de WSP. Por lo tanto, en este caso, se enfatizan los requisitos primarios de WS-Policy y no se muestran algunos pasos básicos no relacionados con esto. Para mayor información sobre la configuración básica de WSP, vea ladocumentación de WebSphere DataPower SOA Applianceso elWebSphere DataPower SOA Appliance Handbook (Manual de WebSphere DataPower SOA Appliance).

Configuración del mensaje de solicitud entrante

El primer paso para configurar el WSP consiste en crear el WSP y asignarle el WSDL. El servicio en WebSphere Application Server expone el WSDL usando la URLhttps://9.30.197.37:9443/WSSampleSei/EchoService?WSDL. Se obtiene el WSDL y se lo carga en el directorio local:// del dispositivo por medio de File Management WebGUI. La Figura 12 le muestra la asignación del WSDL al WSP UNT-LTPA-Proxy recientemente creado:

Figura 12. Asignación del WSDL al WSP
Asignación del WSDL al WSP

DataPower soporta métodos alternativos de asignación de WSDL. Usted puede usar Universal Description Discovery and Integration (UDDI) o WebSphere Service Registry and Repository para traer el WSDL. Se puede usar WebSphere Service Registry and Repository para establecer intervalos de selección para agregar los cambios a WSDL. Por ejemplo, si se modifica la ubicación del servicio remoto (la aplicación de WebSphere Application Server), se podría configurar el WSP para que use la URL nueva automáticamente. Para mayor información sobre UDDI o WebSphere Service Registry and Repository, vea ladocumentación de WebSphere DataPower SOA Appliances.

WSDL contiene un solo servicio que expone un solo puerto para el tráfico de mensajes. Este puerto se expone a través de HTTPS y es el punto final desde el que DataPower reenviará todas las solicitudes validadas hacia EchoService. El Listado 1 le muestra la sección del servicio desde el WSDL:

Listado 1. Asignaciones del puerto de servicio WSDL

<wsdl:service name="EchoService"> <wsdl:port
                name="EchoServicePort" binding="tns:EchoSOAP"> <soap:address
                location="https://9.30.197.37:9443/WSSampleSei/EchoService"/>
                </wsdl:port> </wsdl:service>

DataPower puede exponer múltiples puertos de protocolo delantero para recibir el tráfico de clientes. En este caso, se ofrece un puerto HTTPS. De manera predeterminada, la dirección remota contiene la información sobre el punto final desde el puerto WSDL. Esto se puede modificar de ser necesario. A esto también se lo puede asignar dinámicamente si, por ejemplo, el punto final difiere según las diferentes clases de solicitud (como, por ejemplo, un servicio de alta velocidad para clientes "oro" y un proveedor de servicios de menor calidad para el tráfico normal). La asignación dinámica se lleva a cabo por medio de la directiva de DataPower, Route action (Acción de rutear), o dentro de XSLT en una acción de transformación. La Figura 13 le muestra la asignación de puntos finales locales y remotos:

Figura 13. Asignaciones de puntos finales locales y remotos
Asignaciones de puntos finales locales y remotos

El controlador de punto final local es un Front Side Protocol Handler (FSH) denominado untLTPA_HTTPS_FSH (un HTTPS FSH básico que acepta tráfico por el puerto 8082). Ahora, usted ha definido un WSP simple que acepta tráfico HTTPS y lo reenvía haciaHTTPS://9.30.197.37:9443/WSSampleSei/EchoService.

El próximo paso de configuración consiste en usar WS-Policy para garantizar que las solicitudes del cliente incluyan el token Username que requiere nuestra aplicación de muestra. Todas las asignaciones de WS-Policy se realizan desde la pestaña WSP Policy. Se puede adjuntar la directiva a cualquier nivel del WSDL: servicio, proxy, operación y como el WSDL en sí mismo. Cuando se la adjunta, se la hace cumplir en todos los demás niveles (por ejemplo, la directiva que se adjunta al servicio es a nivel de la operación). Usted debe garantizar que todo el tráfico correspondiente a todos los servicios contenga el UNT, lo que usted puede hacer presionando el botón WS-Policy:

Figura 14. Pestaña del WSP proxy
Pestaña del WSP proxy

Los requisitos consisten en garantizar que se entregue el UNT en todas las solicitudes del cliente. Como ya lo mencionamos, DataPower soporta WS-SecurityPolicy 1.2. Laespecificación WS-SecurityPolicy 1.2contiene directivas de aserción del token Username que se pueden usar para aseverar la existencia de este token. Como DataPower es un PDP (punto de decisión de directiva), ofrece la implementación para ésta y otras directivas de aserción de token.

DataPower incluye una plantilla de muestra denominada wsp-sp-1-1-usernametoken.xml en el directorio store://policies//templates, que es muy similar a nuestro requisito.

La especificación WS-SecurityPolicy 1.2 incluye opciones para muchas variaciones de la aserción del token Username. Por ejemplo, las variaciones del atributo sp:IncludeToken modifican los requisitos de la existencia del UNT en mensajes de solicitud y / o respuesta. No todas las variaciones se soportan por medio de una plantilla preexistente en DataPower. Por lo tanto, en algunos casos, es posible que usted deba modificar las plantillas de DataPower. Hay una plantilla en DataPower para aseverar la existencia del UNT en mensajes de solicitud y respuesta. No hay ninguna plantilla preexistente para la aserción en el UNT sólo en el mensaje de solicitud. De todas formas, usted puede crear una.

El Listado 2 le muestra una sección de esta directiva. Esta directiva busca un UNT en el formato 1.1. La plantilla también incluye una directiva que busca el UNT con formato 1.0.

Listado 2. Fragmento del código de wsp-sp-1-1-usernametoken.xml

<wsp:All>
   <sp:SupportingTokens>
      <sp:UsernameToken sp:IncludeToken=
      "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always">
         <wsp:Policy>
            <sp:WssUsernameToken11/>
         </wsp:Policy>

      </sp:UsernameToken>
   </sp:SupportingTokens>
</wsp:All>

En la especificación WS-SecurityPolicy 1.2, en la sección 5.1.1 Valores de inclusión de token, se encuentra la siguiente descripción (Tabla 1) de expectativas de token según lo determinado por el atributo sp:IncludeToken:

Directiva WS-Security: Descripción de sp:IncludeToken

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never
El token NO SE DEBE incluir en ningún mensaje enviado entre el iniciador y el receptor. En cambio, se debería usar una referencia externa al token.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Once
El token SE DEBE incluir en sólo un mensaje enviado desde el iniciador hasta el receptor. Las referencias al token PUEDEN usar un mecanismo de referencia interno. Todos los mensajes subsiguientes relacionados entre el receptor y el iniciador podrán hacer referencia al token usando un mecanismo de referencia externo.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
El token SE DEBE incluir en todos los mensajes enviados desde el iniciador hasta el receptor. El token NO SE DEBE incluir en ninguno de los mensajes enviados desde el receptor hasta el iniciador.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator
El token SE DEBE incluir en todos los mensajes enviados desde el receptor hasta el iniciador. El token NO SE DEBE incluir en ninguno de los mensajes enviados desde el iniciador hasta el receptor.
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always
El token SE DEBE incluir en todos los mensajes entre el iniciador y el receptor. Éste es el comportamiento predeterminado.

El valor de http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always, cuando se lo asigna al atributo sp:IncludeToken, requiere un UNT tanto en la solicitud como en la respuesta que se envía al cliente. El requisito consiste en sólo requerir el UNT en la solicitud. Por lo tanto, usted puede modificar el atributo sp:IncludeToken para que pase a ser http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient y así sólo requiera el UNT en el mensaje de solicitud (y no en el de respuesta).

En vez de modificar la directiva en store://policies//templates (lo que usted no está autorizado a hacer), copie esto a local://, cambie el nombre por wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml y realice el cambio que se mencionó con anterioridad (AlwaysToRecipient).

Ahora que ha creado una directiva personalizada, es necesario adjuntarla al nivel de servicio del WSDL. La Figura 15 le muestra la ventana emergente que aparece al hacer clic en el botón WS-Policy. La pestaña Sources (Fuentes) se usa para asignar la directiva. Navegue a el directorio local:// para seleccionar la directiva recientemente creada (wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml).

Algunos documentos de directiva siempre tendrán múltiples directivas diferenciadas por un único atributo wsu:Id. Cuando encuentre uno de estos documentos, elija cuál usar seleccionando el wsu:Id adecuado. En este ejemplo, sólo hay uno. Haga clic en Attach Source (Adjuntar fuente) y Apply (Aplicar) para que el WSP complete la asignación:

Figura 15. ¿Cómo se adjunta WS-Policy a WSDL?
¿Cómo se adjunta WS-Policy a WSDL?

La directiva UNT no requiere ninguna información adicional, pero algunas directivas requieren algunos parámetros extra para estar completas. Por ejemplo, una directiva que se ocupa de ejercer el cumplimiento de una firma digital requiere que el nombre de un DataPower Crypto Certificate verifique la firma. La pestaña Processing (Procesamiento) le permite asignar estas propiedades. Además, la pestaña Enabled Subject (Sujeto activado) le permite poner a punto las fases de mensaje y los elementos WSDL sobre los que se ejerce la directiva. Por ejemplo, es posible que usted sólo desee exigir el cumplimiento de la directiva en la fase de solicitud del mensaje y no en la fase de respuesta.

Si usted envía una solicitud simple a este servicio por medio de DataPower sin la UNT, ocurre una violación. El Listado 3 le muestra una EchoRequest sin una UNT:

Listado 3. EchoRequest de muestra sin UNT

<?xml version="1.0" encoding="UTF-8"?>
                <S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
                oasis-200401-wss-wssecurity-secext-1.0.xsd"
                xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
                oasis-200401-wss-wssecurity-utility-1.0.xsd"
                xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:tns="http://com/ibm/was/wssample/sei/echo/"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"> <S11:Body>
                <tns:echoStringInput> <echoInput> Are you talkin' to
                me?</echoInput> </tns:echoStringInput>
                </S11:Body> </S11:Envelope>

Al usar cURL (http://www.haxx.se/), usted puede enviar esta solicitud y ver los resultados. El Listado 4 le muestra la respuesta de DataPower:

Listado 4. Mensaje de error devuelto sin UNT

curl -k -d @echoRequestNoUNT.xml 
https://9.33.96.224:8082/WSSampleSei/EchoService -H "Content-type: 
text/xml" -H "SOAPAction: echoOperation" --key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>
Required elements filter setting reject: expression /*[local-name()='Envelope' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]/*[local-name()='Header' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]//*[local-name()=
'UsernameToken' and namespace-uri()='http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'] 
was not satisfied (from client)</faultstring></env:Fault></env:Body></env:Envelope>

Al agregar una UNT a la solicitud, como se puede observar en el Listado 5, se deberían cumplir los requisitos de la directiva recientemente agregada. Se agregó la UNT al elemento wsse:Header, wsse:Security:

Listado 5. EchoRequest con UNT

<?xml version="1.0" encoding="UTF-8"?>
                <S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
                oasis-200401-wss-wssecurity-secext-1.0.xsd"
                xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
                oasis-200401-wss-wssecurity-utility-1.0.xsd"
                xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/"
                xmlns:tns="http://com/ibm/was/wssample/sei/echo/"
                xmlns:xs="http://www.w3.org/2001/XMLSchema"> <S11:Header>
                <wsse:Security> <wsse:UsernameToken wsu:Id="username">
                <wsse:Username>fred</wsse:Username>
                <wsse:Password>flintstone</wsse:Password>
                </wsse:UsernameToken> </wsse:Security>
                </S11:Header> <S11:Body>
                <tns:echoStringInput> <echoInput>Are you talkin' to
                me?</echoInput> </tns:echoStringInput>
                </S11:Body> </S11:Envelope>

Configuración del mensaje de solicitud saliente

Antes de enviar una solicitud a la aplicación de WebSphere Application Server, hay que hacer algunas cosas adicionales. WebSphere Application Server hace cumplir la identidad de usuario solicitante en el token LTPA. Además, mientras que usted puede permitir que varios clientes realicen solicitudes, WebSphere Application Server está configurada para que sólo un usuario utilice la aplicación. Por lo tanto, usted debe mapear las solicitudes validadas hacia un nombre distinguido y aceptado por WebSphere Application Server mediante la acción AAA de la directiva de procesamiento. La Figura 16 le muestra la regla de solicitud predeterminada con la adición de una directiva AAA:

Figura 16. Directiva de proxy con acción AAA
Directiva de proxy con acción AAA

La directiva AAA acepta las credenciales del cliente desde la UNT, como se puede observar en la Figura 17, lo que demuestra la fase de extracción de identidad de la acción AAA:

Figura 17. Extracción de identidad de la acción AAA
Extracción de identidad de la acción AAA

Mientras que una aplicación real usaría un mecanismo como LDAP para autenticar las credenciales UNT, este ejemplo usa un archivo AAA Info XML almacenado en el dispositivo. La Figura 18 le muestra la fase de autenticación:

Figura 18. Autenticación de la acción AAA
Autenticación de la acción AAA

El archivo AAA Info le ofrece una forma conveniente para que WebSphere Application Server asigne la credencial nueva. Usted puede usar métodos alternativos (como, por ejemplo, Tivoli Federated Identity Manager, Secured Conversation u otros métodos personalizados, como una consulta xPath en el documento de solicitud o en el XSLT del cliente). La Figura 19 le muestra el mapeo desde el archivo AAA Info:

Figura 19. Mapeo de la credencial de información de AAA
Mapeo de la credencial de información de AAA

El último paso del procesamiento AAA consiste en convertir la UNT en el token LTPA. En esta fase de postprocesamiento, se seleccionó Generate LTPA Token (Generar token LTPA). La opción predeterminada consiste en almacenar el token LTPA en un encabezado HTTP Cookie. De manera opcional, el token se puede almacenar en el elemento del encabezado WS-Security. Ésta es la opción que elegimos aquí. DataPower le ofrece un recuadro desplegable (LTPA Token Version [Versión de token LTPA]) que se usa para designar el formato del token LTPA. Los objetivos consisten en seleccionar la versión del token (V1 / V2) y determinar si conviene colocar el token en un HTTP Cookie o en un Binary Security Token (BST). Además, existen dos formas de BST disponibles (generalmente usadas con el tráfico de servicios web) que tienen diferentes declaraciones de espacio de nombre.

Las opciones de LTPA Token Version de Domino, WebSphere Version 1 y WebSphere Version 2 son autodescriptivas. WebSphere Version 1 FIPS le ofrece una mayor seguridad en cumplimiento con el Estándar Federal de Procesamiento de Información (FIPS) para el token versión 1. De manera inherente, el token versión 2 cumple con el FIPS. Y se usa WebSphere V7 Version 2 para crear un BST con el espacio de nombre wwst:LTPAv2. Estos valores estaban en etapa de revisión cuando se publicó este artículo. Por lo tanto, usted debería controlar las guías de producto de DataPower para obtener la información más actualizada sobre la revisión de su firmware. La Figura 20 le muestra la selección de LTPA:

Figura 20. Postprocesamiento AAA para la creación del token LTPA
Postprocesamiento AAA para la creación del token LTPA

En referencia a la introducción a LTPA, existen múltiples versiones del token LTPA. Hemos seleccionado el formato WebSphere V7.0 Version 2. Además, el archivo de clave LTPA, como se lo obtuvo de WebSphere Application Server (vea la explicación de la configuración de WebSphere Application Server) se carga en el directorio cert:// del dispositivo y se ingresa la contraseña. Se podrían haber ingresado LTPA User Attributes (Atributos de usuario LTPA). Estos pares de nombre-valor requieren la programación de aplicación en la aplicación de WebSphere Application Server para permitir el consumo y la interpretación.

Al completar la acción AAA, se finaliza la configuración de la directiva WSP. Las solicitudes enviadas a la aplicación por medio de la aplicación DataPower ahora se validan por medio del WSP y la WS-Policy. Los tokens Username se convierten en tokens LTPA mediante la directiva AAA y se los envía a la aplicación de WebSphere Application Server. El Listado 6 le muestra un ejemplo de una solicitud y una respuesta usando cURL. La aplicación responde con la cadena y el nombre de usuario (wsadmin) exactos que se extraen del token LTPA.

Listado 6. Presentación de la solicitud por medio de DataPower

curl -k -d @echoRequest.xml https://9.33.96.224:8082/WSSampleSei/EchoService -H 
"Content-type: text/xml" -H "SOAPAction: echoOperation" 
--key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns2:echoStringResponse xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">
<echoResponse>JAX-WS==>> Are you talkin' to me? (user: wsadmin)</echoResponse>
</ns2:echoStringResponse></soapenv:Body>

</soapenv:Envelope>

Conclusión

Se diseñó la WS-Policy con el objetivo de ofrecer gobernabilidad SOA en toda la empresa. Este artículo demostró su uso e implementación dentro de WebSphere DataPower SOA Appliance para ejercer el cumplimiento de los tokens Username y dentro de WebSphere Application Server para ejercer el cumplimiento de los tokens LTPA. Los tokens LTPA son un método efectivo y eficiente de inicio de sesión único, ya que ofrecen información sobre la identidad que no es necesario volver a autenticar.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=457216
ArticleTitle=Integración de la seguridad de WS-Policy entre DataPower y WebSphere Application Server
publish-date=07292011