Desarrollo e implementación de soluciones de prestación a múltiples clientes, entregadas a través de la Web con Middleware de IBM: Parte 8: Un patrón proxy de mediación de servicio web para el ruteo de solicitudes de múltiples clientes usando el dispositivo de SOA WebSphere DataPower

La Parte 1 de esta serie describe la prestación a múltiples clientes y algunos desafíos técnicos que enfrentan los proveedores de servicios a la hora de implementar soluciones de prestación a múltiples clientes que se entregan a través de la Web. En la parte 4, presentamos el desafío técnico de cómo habilitar la prestación a múltiples clientes para los servicios web de cliente único existentes sin realizar (mayores) cambios en el código, con el objeto de lograr plazos de comercialización más cortos y menores costos. En este tutorial, presentaremos los pasos detallados de la implementación usando un dispositivo® de SOA WebSphere DataPower en combinación con Tivoli® Access Manager.

Indrajit Poddar, Software Architect, IBM

Indrajit PoddarIndrajit Poddar (IP) is a member of the Strategy, Technology, Architecture, and Incubation team at IBM Software Group Strategy, where he leads several integration PoCs for building composite business services delivered in the Software-as-a-Service (SaaS) model.



Devaprasad Nadgir, IBM Certified Senior IT Architect, IBM  

NadgirDevaprasad is a Certified Senior IT Architect and works out of India Software Lab, Bangalore. He is currently involved in Service Registry and Federated SOA Governance initiatives in IBM Software Group. His areas of interest also include Architectural Methods, Cloud Computing, Virtualization and Software-as-a-Service. Check out his blog where he shares some of his insights and technology trends.



01-04-2014

Antes de comenzar

Acerca de este tutorial

Los dispositivos de SOA WebSphere DataPower son dispositivos de red que pueden actuar como mediadores entre los proveedores de servicios y los consumidores de servicios. Entre las ventajas clave que ofrecen estos dispositivos se incluyen el procesamiento de mensajes de servicios web y XML basado en hardware de alto rendimiento, transformación de protocolo, sencillez de configuración y seguridad. En este tutorial, demostraremos cómo pueden los proveedores de servicios explotar con DataPower las características de ruteo de mensajes basadas en el contenido para rutear solicitudes de servicios desde el usuario de un cliente hacia los puntos finales del servicio dedicados a ese cliente. También demostraremos cómo los proveedores de servicios pueden integrar DataPower con Tivoli Access Manager de manera que las directivas de autorización administradas centralmente puedan usarse para autorizar solicitudes de servicios específicas de clientes. Finalmente, demostraremos cómo los proveedores de servicios pueden monitorear las solicitudes de servicios usando características moldeadoras de tráfico de servicios web en DataPower.

Escenario y pasos principales de implementación

Figura 1. Prestación a múltiples clientes con mediación implementada por medio de dispositivos de SOA WebSphere DataPower

En la parte 5 de esta serie, describimos un escenario y un caso de uso en el cual el proveedor del servicio para la aplicación bancaria multi-cliente Jivaro pretende habilitar la prestación a múltiples clientes para su servicio de puntaje crediticio existente. En este tutorial, demostraremos cómo configurar el dispositivo de SOA WebSphere DataPower para implementar un patrón de mediación destinado a la prestación a múltiples usuarios, de la manera que se ilustra en la Figura 1. Llevaremos a cabo los siguientes pasos principales:

  1. Configurar los proxies de servicio web en WebSphere DataPower para las solicitudes del cliente en materia de autenticación, autorización y ruteo
  2. Configurar usuarios y grupos específicos de clientes en Tivoli Access Manager
  3. Establecer directivas de Monitoreo de Nivel de Servicio (SLM, por su sigla en inglés) para monitorear las solicitudes específicas de servicio del cliente

Requisitos previos

En este tutorial se supone que los productos que se mencionan a continuación se han dispuesto de manera que puedan funcionar sobre una plataforma integrada. Una discusión detallada sobre cómo disponer los componentes de hardware y software que aquí figuran está fuera del alcance de este artículo. Sírvase consultar la sección de Recursos para obtener mayores detalles.

Los siguientes productos de desarrollo de IBM son necesarios para habilitar la prestación a múltiples clientes en cuanto a su solución de servicio web de verificación crediticia:

  1. Dispositivo de SOA WebSphere DataPower XI50
  2. Tivoli Access Manager v6.0

Asimismo, se necesita el siguiente software para implementar múltiples instancias de servicio web de verificación crediticia:

  1. WebSphere Portal Server v6.0
  2. WebSphere Process Server v6.1
  3. Tivoli Directory Server v6.0

Implementación del escenario

Configuración de proxies de servicio web en WebSphere DataPower

Configure WebSphere DataPower como un proxy de mediación creando dos proxies de servicio web, SaasCreditCheckService y CreditCheckServices, como se ilustra en la Figura 2.

Figura 2. Proxies de servicio Web en WebSphere DataPower para habilitar la prestación a múltiples clientes a través de mediación: SaasCreditCheckService y CreditCheckServices

El proxy de servicio web SaasCreditCheckService será invocado por una aplicación web basada en un portal front-end para consultar los puntajes crediticios de la manera que se describe en el escenario presentado en la Parte 5 de esta serie. Este proxy asegurará que el usuario esté autenticado y autorizado (utilizando la acción AAA de la directiva de solicitud del proxy de servicio web) antes de rutear la solicitud (usando una acción de ruteo) a los puntos finales específicos del servicio web de verificación crediticia dedicados al servicio web de cada cliente.

El proxy de servicio web CreditCheckServices almacenará los WSDL (Lenguajes de Descripción de servicios web) para proveedores de servicios de puntaje crediticio específicos de terceros (por ejemplo, Expo y S&R) e incluirá un componente controlador frontal correspondiente a cada punto final del proveedor del servicio. Para mayor simplicidad, estamos suponiendo que ambos proveedores de servicios de verificación crediticia tienen la misma interfaz en sus WSDL. Si las interfaces son diferentes, es posible incluir transformaciones XSLT en este proxy de servicio web, de manera de mapear la solicitud a un formato que corresponda a cada proveedor de servicios.

Cargar los archivos WSDL y las claves LTPA en WebSphere DataPower

  1. Inicie sesión en el dispositivo de SOA WebSphere DataPower usando la consola de administrador, y haga clic en Control Panel (Panel de control) > Web Service Proxy (Proxy de servicio web).
  2. En el directorio local, haga clic en Acciones y seleccione Crear Subdirectorio, desde el submenú.
  3. Especifique el nombre del directorio como SaasCreditCheckWSDL.
  4. Haga clic en el menú Acciones, enfrente de SaasCreditCheckWSDL, y seleccione Cargar Archivos, en el submenú.
  5. Navegue y cargue los siguientes archivos en esta carpeta:
    1. CustomerCreditInfo.xsd: es un ejemplo de Objeto de Datos de Servicio (SDO) recibido desde un proveedor de servicios de terceros.
    2. CustomerProfileReq.xsd: es un ejemplo de SDO enviado a un proveedor de servicios de terceros que solicita un puntaje crediticio de un cliente.
    3. ExpoCreditScore.mod_ICreditServicesExport1.wsdl: es un ejemplo de archivo WSDL provisto por un proveedor de servicios de terceros que contiene información de punto final.
    4. ICreditServices.wsdl: es un ejemplo de WSDL que contiene mensajes de entrada y salida y detalles de operaciones.
    5. JivaroCreditCBA.mod_ICreditServicesExport1.wsdl: es un WSDL que contiene información de punto final sobre el proxy de servicio web SaasCreditCheckService.
    6. SandRCreditScore.mod_ICreditServicesExport1.wsdl: es un ejemplo de archivo WSDL suministrado por un proveedor de servicios de terceros que contiene información de punto final.
    7. Clave LTPA exportada desde el servidor del portal WebSphere (para mayor información sobre cómo exportar claves LTPA desde el servidor del portal, consulte la sección de Recursos).
    8. SampleRequest.xml: es un ejemplo de una Solicitud enviada al proxy de servicio web SaasCreditCheckService.

Nota

Anote la contraseña LTPA provista en el servidor del portal WebSphere al exportar la clave LTPA. Ésta será necesaria para configurar la directiva AAA.

Figura 3. Archivos cargados

Configure el proxy de servicio web SaasCreditCheckService para autenticación, autorización y ruteo

Primero cree SaasCreditCheckService dentro del dispositivo de SOA WebSphere DataPower siguiendo los pasos que figuran a continuación:

  1. Inicie sesión en la consola del administrador del dispositivo de SOA WebSphere DataPower y haga clic en Control Panel > Web Service Proxy.
  2. Haga clic en el botón Add (Agregar) para agregar un New s Proxy (Nuevo proxy).
  3. Establezca el nombre del proxy como SaasCreditCheckService y haga clic en el botón Create Web Service Proxy (Crear proxy de servicio Web).
  4. Establezca la URL del archivo WSDL como “local:///SaasCreditCheckWSDL” y “JivaroCreditCBA.mod_ICreditServicesExport1.wsd” en el cuadro de opciones siguiente. Haga clic en Next (Siguiente).
  5. Haga clic en el botón del signo +, debajo de Controlador de Punto Final Local, y seleccione HTTP Front Side Handler (Controlador Frontal HTTP). Un objeto controlador frontal HTTP manipula comunicaciones de protocolo HTTP sobre el puerto especificado. En la ventana emergente, establezca el nombre del controlador HTTP como CreditCheckFSHandler y el número de puerto como 9330, como se ilustra en la Figura 4 más abajo. Haga clic en Apply (Aplicar) para guardar los cambios y cerrar esta ventana.

Nota:

Asegúrese de que el número de puerto 9330 no esté siendo utilizado por otro objeto dentro del dispositivo de SOA WebSphere DataPower. De otro modo, el controlador Op-State estará desactivado y el controlador frontal no funcionará.

Figura 4. Detalles de CreditCheckFSHandler
  1. En Configurar Pantalla del Proxy de servicio web, especifique el URI como /CreditScoreService y haga clic en el vínculo Agregar para agregar CreditCheckFSHandler. Al hacerlo, toda solicitud a la URL http://<dp-hostname/ip>:9330/CreditScoreService será manejada por este proxy de servicio web. Haga clic en Siguiente para continuar.
Figura 5. Agregar CreditCheckFSHandler al SaasCreditCheckService

Crear directivas para la aceptación de tokens de autenticación LTPA de WebSphere

En la Figura 1, mostramos (con flechas rojas y azules) cómo cada solicitud de cliente llega al proxy WebSphere DataPower desde portales virtuales específicos del cliente. Estos portales virtuales están configurados para autenticar a los usuarios finales y generar tokens de autenticación que luego se propagarán al proxy de WebSphere DataPower como parte del contexto de seguridad de la invocación del servicio web. El desarrollo de la propagación de los tokens LTPA está fuera del alcance de este documento. Sírvase consultar el Paso 2 del artículo (Seguridad de servicios web con WebSphere Application Server V6, Parte 4, para obtener mayor información al respecto. Tenga en cuenta que, además de llevar a cabo los pasos descritos en el Paso 2, usted también tendrá que seleccionar la casilla de verificación jaas.config en WebSphere Integration Developer).

En esta sección, los tokens LTPA de WebSphere se usan para la autenticación dentro del dispositivo de SOA WebSphere DataPower a través de los pasos siguientes:

  1. Haga clic en la pestaña Policy (Directiva) y en la sección Web Service Proxy Policy (Directiva del proxy de servicio web) seleccione la regla de solicitud predeterminada, como se muestra en la Figura 6.
Figura 6. Directiva de solicitud predeterminada de SaasCreditCheckService
  1. Arrastre la acción AAA de la lista de diversas acciones que figuran dentro de la regla. Haga doble clic en la acción AAA recientemente agregada para abrirla y configurarla. Se abrirá una ventana emergente que le permitirá configurar la acción AAA.
Figura 7. Regla de solicitud predeterminada para la Directiva SaasCreditCheck, agregando la acción AAA
  1. En la sección Input (Entrada) de la ventana Configurar Acción AAA, seleccione Entrada en el cuadro de opciones.
  2. Haga clic en el botón +, enfrente de Directiva AAA, para crear una nueva directiva AAA. En la nueva ventana emergente, Configure an Access Control Policy (Configurar una directiva de control de acceso), realice los siguientes pasos:
    1. Seleccione el token LTPA y seleccione el botón de radio enfrente de Use WS-Security Token First (Usar primero token de seguridad de servicio web), en Define how to extract a user's identity from an incoming request (Definir cómo extraer la identidad de un usuario a partir de una solicitud entrante). Haga clic en Siguiente.
    2. Seleccione Accept an LTPA token (Aceptar un token LTPA) como método para autenticar el usuario y WebSphere Version 1 and 2 (Versiones 1 y 2 de WebSphere) como versiones aceptables de LTPA, en la página siguiente. Para configurar el archivo de la clave LTPA, seleccione la carpeta local:///SaasCreditCheckWSDL y seleccione el archivo del token LTPA cargado en el Paso 3.1.1. Proporcione la misma contraseña LTPA y haga clic en Siguiente.
Figura 8. Definir cómo extraer la identidad de un usuario a partir de una solicitud entrante
Figura 9. Definir cómo autenticar la identidad del usuario
  1. Supondremos que las solicitudes SOAP entrantes al servicio SaaSCreditCheck contienen un token LTPA en el encabezado de seguridad del servicio web (WSSE). Este token deberá quitarse después del procesamiento, ya que el proxy de servicio web invocado a continuación no podrá procesarlo y fallará si el token LTPA está presente (ya que el encabezado WSSE tiene el atributo mustUnderstand establecido como verdadero). Haga clic en Siguiente hasta posicionarse en la sección Choose any post processing request (Seleccionar cualquier solicitud de post-procesamiento), luego establezca la opción Run Custom Post Processing Stylesheet (Ejecutar hoja de estilo de post procesamiento personalizada) como activada. En la URL, establezca la carpeta como store:/// y el nombre de archivo como strip-security-header.xsl.
Figura 10. Post procesamiento de la solicitud entrante

Delegar las decisiones de autorización en Tivoli Access Manager

En esta sección configuraremos WebSphere DataPower para delegar todas las decisiones de autorización a un Tivoli Access Manager central que está configurado con directivas de control de acceso e información de grupos de usuarios.

  1. En la página de control de acceso, seleccione la URL enviada por el cliente como Método de Identificación de Recursos. Complete los siguientes detalles para definir cómo mapear recursos:
    1. Seleccione el Método como Tivoli Access Manager.
    2. Seleccione la Tivoli Object Space Mapping (Mapeo de espacio de objeto Tivoli) como personalizada y el Prefijo de Instancia de Espacio de Objeto Tivoli como servicios web. Esta asignación personalizada se basa en el espacio de objeto creado anteriormente en este artículo. Una vez establecida esta asignación, el recurso enviado por el cliente tendrá prefijos de servicios web antes de solicitar detalles de autorización en TAM. En nuestro ejemplo, el cliente del servicio web envía el mensaje SOAP a la URL siguiente: http://<datapower>:9330/CreditScoreService.

      En este caso, el recurso extraído por el dispositivo es “CreditScoreService”. Con nuestra asignación personalizada, este recurso se convierte en “/web-services/CreditScoreService”, el que se usará luego para consultar a TAM para la autorización.
  2. Haga clic en Siguiente para continuar.
Figura 11. Definir cómo extraer los recursos a partir de una solicitud entrante
  1. Seleccione Contact Tivoli Access Manager (Contactar a Tivoli Access Manager) como método para autorizar solicitudes. Para la Tivoli Access Manager Configuration (Configuración de Tivoli Access Manager), haga clic en el botón del signo + para crear una nueva configuración.
  2. En la página de la nueva configuración, haga clic en el vínculo Create IBM TAM Configuration Files (Crear archivos de configuración para TAM de IBM) como se ilustra en la Figura 12 más abajo, para obtener una nueva ventana emergente con “Crear Configuración para Tivoli Access Manager de IBM”.
Figura 12. Crear una nueva configuración para TAM
  1. Introduzca los detalles requeridos (marcados con *). Consulte la Figura 13 para obtener mayor información.
    1. Output Configuration File Name (Nombre del archivo de configuración de salida) > RT4_TAM_Conf_Files
    2. Tivoli Access Manager Administrator (Administrador de Tivoli Access Manager) > sec_master {TAM Admin username}
    3. Administrator Password (Contraseña de administrador) > {TAM Admin Password}
    4. Tivoli Access Manager Application ID (ID de Aplicación de Tivoli Access Manager) > RT4_TAM_App_Id. {Introduzca el nombre de la aplicación TAM. El nombre especificado se combina con el nombre del host del dispositivo para crear un identificador único para los objetos creados para el cliente TAM.}
    5. Policy Server (Servidor de directivas) > rt4.in.ibm.com {Policy Server Hostname/IP}
    6. LDAP Server (Servidor LDAP) > rt4.in.ibm.com {LDAP Server Hostname/IP}
    7. LDAP Administrator Password (Contraseña de administrador de LDAP) > {LDAP Admin Password}

Nota

Para mayor información sobre cada entrada, haga clic en el vínculo Ayuda, en el extremo superior izquierdo de la misma ventana. Asegúrese de que puede hacer ping en el Servidor de Directivas y en el nombre de host o la dirección IP del servidor LDAP que se ha ingresado aquí, desde el dispositivo de SOA WebSphere DataPower.

Figura 13. Crear una nueva configuración para TAM
Creating a new TAM configuration
  1. Haga clic en Create IBM Tivoli Access Manager Configuration (Crear configuración de Tivoli Access Manager de IBM) para crear los archivos de configuración. Haga clic en el botón Confirm (Confirmar) para terminar y en Close (Cerrar) para cerrar la ventana y regresar a la pantalla Configure IBM Tivoli Access Manager (Configurar Tivoli Access Manager de IBM).

Nota:

Verifique si los archivos de configuración de TAM se crean con éxito. Navegue a Panel de Control > Administración de Archivos. Expanda la carpeta Cert y la carpeta Local. - RT4_TAM_Conf_Files.kdbM
- RT4_TAM_Conf_Files.sth
- RT4_TAM_Conf_Files.conf
- RT4_TAM_Conf_Files.conf.obf
En caso de que no se creen los archivos mencionados anteriormente, verifique los archivos de registro para obtener mayor información.

  1. Introduzca los siguientes detalles en Configurar pantalla de Tivoli Access Manager de IBM:
    1. Nombre: scenario1tam.
    2. Archivo de configuración de TAM: Establezca la ubicación del archivo conf, en el primer cuadro de opciones, como “local:///” y el archivo en el segundo cuadro de opciones como < Nombre del archivo de configuración de salida >.conf
    3. Archivo de Clave SSL: Establezca la ubicación del archivo kdb de SSL, en el primer cuadro de opciones, como “cert:///” y el archivo en el segundo cuadro de opciones como < Nombre del archivo de configuración de salida >.kdb
    4. Archivo Intermedio de Clave SSL: Establezca la ubicación del archivo sth de SSL, en el primer cuadro de opciones, como “cert:///” y el archivo en el segundo cuadro de opciones como < Nombre del archivo de configuración de salida >.sth
Figura 14. Nueva pantalla de configuración de TAM con detalles
  1. Haga clic en la pestaña Siguiente, Authorization Server Replicas (Réplicas del Servidor de Autorización) (las réplicas indican la ubicación en la red del servidor remoto de autorización TAM). Haga clic en el botón Agregar para agregar una nueva entrada con los detalles siguientes:
    1. Authorization Server Replica Host: (Host de Réplica del Servidor de Autorización Introduzca Dirección IP/Nombre de Host del servidor de autorización TAM.
    2. Authorization Server Replica Port: (Puerto de Réplica del Servidor de Autorización Déjelo como predeterminado si no se ha cambiado en TAM.
    3. Authorization Server Replica Weight (Peso de réplica del servidor de autorización) Déjelo como predeterminado.
  2. Haga clic en el botón Guardar para guardar la réplica del servidor de autorización y Aplicar para guardar los detalles de configuración de TAM y regresar a la pantalla Define how to map resources (Definir cómo mapear recursos). Seleccione la acción predeterminada como [WebService]i. Haga clic en Siguiente.
Figura 15. Definir cómo autorizar la solicitud entrante

Nota:

Usamos una acción “personalizada” llamada [WebService]i. Usted puede elegir aquí cualquier otra acción y consultar la autorización TAM. Usted debe asegurarse de que se habiliten las acciones adecuadas para el usuario o grupos de usuarios para el recurso solicitado en TAM.

  1. Haga clic en Commit (Asignar) para terminar de configurar la directiva AAA y cerrar esta ventana. Haga clic en Done (Finalizado) para terminar de configurar la acción AAA y cerrar la ventana.

Configurar una acción de ruteo para seleccionar puntos finales de servicios web específicos de cliente

En esta sección, configuraremos reglas de ruteo basadas en contenido en el componente proxy de servicio web SaaSCreditCheckService del dispositivo de SOA WebSphere DataPower, de manera que las solicitudes para un cliente se redirijan hacia el punto final del servicio web destinado a ese cliente. Supongamos que la información del cliente (por ejemplo, bank1 o bank2) se especifica en el encabezado de solicitud de servicio web de la manera que se muestra en el archivo adjunto SampleRequest.xml. Es responsabilidad del cliente de servicios Web (por ejemplo, el portlet de puntaje crediticio en los portales virtuales específicos de cliente de la Figura 1) introducir la información del cliente en el contexto de servicios web para cada solicitud.

  1. Para configurar la acción, en la misma pestaña de directiva y en la regla de solicitud predeterminada de SaaSCreditCheckService WS-Proxy, arrastre y suelte la acción Rutear después de la acción AAA. Haga doble clic para abrir y configurar la acción Rutear.
  2. En la ventana emergente, Configure Route (Configurar Ruta) (Usando Hoja de Estilo o Expresión XPath), establezca el método de selección como Use XPath to select destination (Usar XPath para seleccionar el destino). Haga clic en el botón + para crear un nuevo mapa de ruteo.
  3. Establezca el nombre del mapa de ruteo como CreditCheckRoutingMap, en la nueva ventana emergente Configure XPath Routing Map (Configurar mapa de ruteo XPath).
  4. Navegue a la pestaña Rules (Reglas) y haga clic en el botón Agregar para agregar una nueva regla. En la propiedad Adding new Rules property of XPath Routing Map (Agregar nueva propiedad de reglas del mapa de ruteo XPath) haga clic en XPath Tool (Herramienta XPath) para agregar una expresión XPath, como se muestra en la Figura 18.
Figura 16. Agregar reglas a CreditCheckRoutingMap
  1. Establezca la URL del documento XML de muestra como local:///SaasCreditCheckWSDL y el nombre de archivo como SampleRequest.xml, y seleccione Compare Local Name Only (Comparar nombre local solamente) para la manipulación del espacio de nombres, en la ventana emergente para Select XPath Expression for something in an XML File (Seleccionar expresión XPath para algo en un archivo XML). El contenido de SampleRequest.xml se exhibirá en la misma ventana. En la sección de Contenido, haga clic en bank1 (en soapenv:header -> tenantInfoURI:TenantID). La expresión XPath para el mismo se generará bajo la sección XPath. Haga clic en Done para agregar esta expresión.
Figura 17. Configuración del mapa de ruteo XPath usando una herramienta XPath para el primer cliente (bank1)
  1. Establezca la dirección IP externa de WebSphere DataPower (ya que la solicitud se redirigirá al proxy de servicio web Expo CreditCheckServices) como IP de host remoto y número de puerto 9332 (en el caso de bank1, todas las solicitudes se reenviarán al punto final de empresa Expo), en la propiedad Adding new Rules property of XPath Routing Map. Haga clic en Save (Guardar) para agregar esta regla y cerrar la ventana.
  2. Repita los pasos 4 a 6 para agregar otra regla que permita rutear solicitudes al servicio de verificación crediticia de S&R. En el paso 5, modifique bank1 por bank2 en la expresión XPath y cambie el número de puerto a 9331 (el cual se usará para el controlador frontal del punto final de empresa S&R).
Figura 18. Configurar el mapa de ruteo XPath usando la herramienta XPath para el segundo cliente (bank2)

En la pestaña de reglas de mapa de ruteo XPath, las reglas deben verse como se muestra en la Figura 19.

Figura 19. Reglas para ambos clientes definidos en el mapa de ruteo XPath
  1. Haga clic en el botón Apply para guardar los detalles del Mapa de Ruteo. Haga clic en Done para guardar la configuración de la acción de ruteo.

Nota

Asegúrese de que la salida de una acción (por ejemplo, AAA) sea la entrada de la próxima acción de la directiva (por ejemplo, Ruta). Verifique la misma abriendo la acción respectiva (doble clic) o simplemente pasando el puntero del mouse sobre dicha acción. Como referencia, consulte la Figura 20.

Figura 20. Pasaje del puntero del mouse sobre AAA y Acción de Ruteo para verificar las variables de entrada y salida
  1. En la pantalla de configuración del proxy de servicio web, haga clic en Proxy Settings (Configuraciones de proxy). En la configuración general, elija el Type (Tipo) como Dynamic Backend (Back-end dinámico) (ya que el back-end para este proxy de servicio web no se tomará de WSDL y se decidirá dinámicamente en base a esta acción de ruteo).
  2. Haga clic en el botón Apply para guardar los detalles de configuración. Navegue hacia Control Panel > Web Service Proxy para verificar el estado de SaasCreditCheckService. Debe estar activado como se muestra a continuación en la Figura 21. En caso de que esté desactivado, sírvase verificar los registros de Datapower para obtener más detalles.
Figura 21. Verificación del estado de SaasCreditCheckService

Una vez que la solicitud del cliente es autenticada y autorizada por SaasCreditCheckService, ésta se redirige al punto final respectivo, dentro de la aplicación de SOA WebSphere DataPower, en base al ID del cliente.

Configuración del proxy de servicio web CreditCheckServices

A continuación, configure dos controladores frontales en el Proxy de servicio web CreditCheckServices para cada cliente, es decir, los puntos finales de verificación crediticia para Expo y S&R:

  1. Inicie sesión en la consola de administrador Web-GUI WebSphere DataPower y haga clic en Control Pane > Web Service Proxy (en la sección de Servicios).
  2. Haga clic en el botón Add para agregar un nuevo proxy.
  3. Especifique el nombre de proxy como CreditCheckServices y haga clic en Create Web Service Proxy.
  4. Ingrese los siguientes detalles:
    1. Seleccione el WSDL ExpoCreditScore.mod_ICreditServicesExport1.wsdl.
    2. Ingrese los siguientes detalles para el nuevo controlador de punto final local:
      - Nombre: ExpoFSHandler
      - Puerto: 9332

Nota

Asegúrese de que el puerto 9332 no esté siendo usado por otro objeto dentro del dispositivo. De otro modo, el controlador Op-State estará desactivado y no funcionará.

Figura 22. Detalles del Proxy de servicio web CreditCheckServices
  1. El proxy de servicio web CreditCheckServices contiene los WSDL de los servicios web para las empresas Expo y S&R. En un paso anterior configuramos el WSDL para la empresa Expo. Para agregar el WSDL de la empresa S&R en el proxy de servicio web CreditCheckServices, siga los pasos siguientes:
    1. Navegue a Control Panel > Web Service Proxy, y seleccione CreditCheckServices.
    2. Seleccione la pestaña de WSDL y haga clic en el botón de radio Add WSDL.
Figura 23. Agregar WSDL de verificación crediticia de S&R al proxy de servicio web CreditCheckServices
  1. Seleccione el WSDL SandRCreditScore.mod_ICreditServicesExport1.wsdl
  2. Use los siguientes detalles para el nuevo Local Endpoint Handler (Controlador de punto final local)
    1. Nombre: SandRFSHandler
    2. Puerto: 9331
  3. Para verificar el estado del proxy CreditCheckServices, navegue a Control Panel > Web Service Proxy.
Figura 24. Verificación del Estado de CreditCheckServices

Configuración de los usuarios y grupos específicos del cliente en Tivoli Access Manager

A continuación configuraremos las directivas de autorización en Tivoli Access Manager. Se configurarán usuarios y grupos específicos del cliente, un nuevo espacio de objeto personalizado y una lista de control de acceso para el servicio de verificación crediticia, por medio de los siguientes pasos:

  1. Inicie sesión en la herramienta pdadmin dentro del sistema Tivoli Access Manager.
C:\>pdadmin -a sec_master -p
                    <password> pdadmin sec_master>
  1. Establezca los usuarios que necesitan acceso al Servicio de Puntaje Crediticio. Suponga que hay dos usuarios para cada banco cliente, bobnottingham para bank1 y carrieserrano para bank2. En el listado siguiente se importan dos usuarios llamados “bobnottingham” y “carrieserrano” del registro LDAP existente. Las cuentas importadas de usuarios están deshabilitadas de manera predeterminada y es por ello que éstos deben validar sus cuentas.
pdadmin sec_master> user import bobnottingham "uid=
bobnottingham,cn=users,dc=bank1,dc=com"
pdadmin sec_master> user import carrieserrano "uid=
carrieserrano,cn=users,dc=bank2,dc=com"
pdadmin sec_master> user modify bobnottingham account-valid yes
pdadmin sec_master> user modify carrieserrano account-valid yes
  1. Cree un grupo de usuarios llamado CreditScoreUsers e incluya a los usuarios “bobnottingham” y “carrieserrano” como parte de este grupo.
pdadmin sec_master> group create CreditScoreUsers 
        cn=CreditScoreUsers,dc=ibm,dc=com CreditScoreUsersContainer
pdadmin sec_master> group modify CreditScoreUsers add bobnottingham
pdadmin sec_master> group modify CreditScoreUsers add carrieserrano
  1. Cree un espacio de objeto llamado “servicios web” y cree un objeto CreditScoreService bajo el cual podamos aplicar directivas de seguridad.
pdadmin sec_master> objectspace create /web-services "Web Services Object Space" 0
pdadmin sec_master> object create /web-services/CreditScoreService 
        "Credit Score Service v1" 0 ispolicyattachable yes
  1. Cree un grupo de acción llamado “WebService” y un nombre de acción personalizado también llamado “WebService”. Asignaremos una letra de un solo dígito para esta acción, que definiremos como “i”. Tenga en cuenta que WebSphere DataPower puede consultar a TAM para realizar solicitudes de autorización basadas en este nombre de acción personalizado.
pdadmin sec_master> action group create WebService
pdadmin sec_master> action create i "WebService Custom Action" 0 WebService
  1. Cree una Lista de Control de Acceso llamada “CreditScoreACL” para el grupo CreditScoreUsers con la acción WebService personalizada creada en el paso anterior.
pdadmin sec_master> acl create CreditScoreACL
pdadmin sec_master> acl modify CreditScoreACL set group CreditScoreUsers T[WebService]i
  1. Adjunte el CreditScoreACL al objeto CreditScoreService
pdadmin sec_master> acl attach /web-services/CreditScoreService CreditScoreACL

Como alternativa, estos comandos se pueden almacenar como un script en un archivo de texto para luego ejecutar todos los comandos como se muestra más abajo. El TAM_configuration.txt se proporciona en la sección Recursos.

pdadmin –a sec_master –p <password> TAM_configuration.txt

Verifique que el CreditScoreACL esté adjunto al objeto CreditScoreService y cuente con el acceso necesario otorgado a CreditScoreUsers como se muestra en la figura siguiente, usando el Administrador de Portal Web de TAM.

Figura 25. Uso del administrador de portal Web de TAM para verificar el espacio del objeto y los derechos de acceso

Establecer directivas de monitoreo de nivel de servicio

A continuación configuraremos el Monitoreo de Nivel de Servicio (SLM) para limitar el número de solicitudes que los usuarios de bank2 pueden enviar en un período breve de tiempo, a fin de evitar una denegación de adjunción de servicio. Configuraremos el componente SaasCreditCheckWSProxy por medio de los siguientes pasos:

  1. Inicie sesión en la consola de administrador de WebSphere DataPower
  2. Navegue a Control Panel > Web Service Proxy y haga clic en SaasCreditCheckService.
  3. Seleccione la pestaña de SLM.
  4. En la tabla de Web Service Proxy SLM (SLM de proxy de servicio web), en Request (Solicitud), ingrese los siguientes valores para ICreditServicesExport1_ICreditSreviceHttpService
    1. Intervalo (seg) > 300
    2. Límite->4
    3. Acción -> reducción del flujo de tráfico

Con estos valores establecidos, el servicio aceptará sólo 4 solicitudes en 300 segundos y reducirá el flujo de tráfico para toda solicitud adicional. La misma configuración se puede establecer para las transacciones fallidas.

Figura 26. Configuración del SLM
  1. Haga clic en Apply para guardar la configuración
  2. Una vez que se ha realizado la configuración, invoque el proxy de servicio Web con más de 4 solicitudes en 300 segundos.
  3. Haga clic en el vínculo Graph (gráfico) (como se muestra en la Figura 26 más arriba) en la pestaña Web Service Proxy SLM de SaasCreditCheckService. Una nueva ventana emergente gráfica mostrará el número de transacciones/errores/solicitudes limitadas de flujo de los últimos 10 minutos (como se muestra en la Figura 27).
  4. Para visualizar más datos, modifique el Intervalo de tiempo en la ventana del gráfico
Figura 27. Gráfico de monitoreo del nivel de servicio para el proxy de servicio web

Conclusión

Hemos mostrado cómo el dispositivo de SOA WebSphere DataPower se puede usar para implementar un patrón proxy de mediación a fin de redirigir solicitudes de servicios web de múltiples clientes. Este patrón de diseño ofrece la ventaja de no requerir la realización de cambios en el código de los servicios web existentes para habilitar la prestación a múltiples clientes. Hemos creado una acción de ruteo en un proxy de servicio web para rutear solicitudes específicas de clientes. También demostramos cómo WebSphere DataPower se puede usar para proporcionar funciones adicionales de mediación como autenticación y autorización (acción AAA).


Descargas

DescripciónNombretamañoMetodo de descarga
Sample implementation for this articleDataPowerSampleSource.zip10KBHTTP
A related PDF (not of the article)1MediationUsingWDPScriptv9.pdf50KBHTTP

Información sobre métodos de descarga          Get Adobe® Reader®

Nota

  1. Ésta es una nota de ejemplo sobre PDF.

Recursos

  • Participar en el foro de debate.
  • Dispositivo de SOA WebSphere DataPower productpage.
  • Desarrollo e implementación de soluciones de prestación a múltiples clientes, entregadas a través de la Web con middleware de IBM Parte 1: Desafíos y modelos arquitectónicos.
  • Patrones de mediación de servicios web para el ruteo dinámico de solicitudes de múltiples clientes usando dispositivos de SOA WebSphere DataPower demostración.
  • El artículo “Managing services dynamically using WebSphere DataPower SOA Appliances with WebSphere Service Registry and Repository” [Administración dinámica de servicios usando dispositivos de SOA WebSphere DataPower con WebSphere Service Registry and Repository] productpage (developerWorks, febrero de 2008) discute cómo desacoplar a los solicitantes de servicios y a los proveedores de servicios a nivel del transporte implementando un proxy de servicio web que asigne dinámicamente el punto final de servicio apropiado a la solicitud del servicio.
  • Redpaper: IBM WebSphere DataPower SOA Appliances Part I [Dispositivos de SOA WebSphere DataPower de IBM, Parte I] Generalidades y primeros pasos.
  • Redpaper: IBM WebSphere DataPower SOA Appliances Part II [Dispositivos de SOA WebSphere DataPower de IBM, Parte II] Autenticación y autorización.
  • Redpaper: IBM WebSphere DataPower SOA Appliances Part IV [Dispositivos de SOA WebSphere DataPower de IBM, Parte IV] Administración y gobernabilidad.

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=SOA y servicios web , WebSphere
ArticleID=427923
ArticleTitle=Desarrollo e implementación de soluciones de prestación a múltiples clientes, entregadas a través de la Web con Middleware de IBM: Parte 8: Un patrón proxy de mediación de servicio web para el ruteo de solicitudes de múltiples clientes usando el dispositivo de SOA WebSphere DataPower
publish-date=04012014