Potenciar DataPower SOA Appliances para extender las capacidades de seguridad de InfoSphere Master Data Management Server

IBM® InfoSphere™ Master Data Management (MDM) Server proporciona la habilidad para gestionar datos maestros, al confiar fuertemente en servicios web y XML. IBM WebSphere ®DataPower® SOA Appliances proporciona la habilidad para despliegues seguros de los servicios web. En este artículo, observe cómo usted puede apalancar algunas de las capacidades de DataPower para extender la seguridad del MDM Server.

Dmitriy Fot, Software Engineer, IBM

Dmitriy Fot photoDmitriy Fot está trabajando como un ingeniero de software en la Arquitectura Avanzada para el departamento de Gestión de la Información en Austin, Texas. Dmitriy ha trabajado en el área de Master Data Management desde que se unió al Centro de Excelencia para el equipo MDM con base en IBM Boeblingen Lab, en Alemania. Su experiencia incluye numerosos proyectos de integración que envuelven MDM Server y otros sistemas que pertenecen o no a IBM. Después de unirse a IBM Austin Lab, Dmitriy cambió su enfoque hacia la seguridad de la información y participó en varios proyectos en el área de control de acceso, seguridad basada en política y seguridad de bases de datos.



Martin Oberhofer, DB2 Everyplace Consultant, IBM

Photo: Martin OberhoferMartin Oberhofer se unió a IBM en IBM Silicon Valley Labs, en Estados Unidos, a comienzos de 2002 como ingeniero de software. En un rol de arquitecto para Enterprise Information Management y Master Data Management, actualmente trabaja con grandes empresas alrededor del globo dándole forma a la base de arquitectura de la información, resolviendo problemas comerciales intensos de información. Sus áreas de experiencia son Master Data Management, Enterprise Information Integration, tecnologías de bases de datos, desarrollo de Java e integración de sistemas de IT. La sincronización y la distribución de datos maestros dentro del entorno operacional de IT es su área de enfoque, en particular el intercambio de datos maestros con sistemas de aplicación de SAP. Proporciona Enterprise Information Architecture y talleres de trabajo de la Solución para cliente y a los principales integradores de sistemas. En un rol de Lab Advocate, provee consejos expertos para Gestión de la Información para clientes muy grandes de IBM. Sostiene un grado de Master en matemática de la Universidad de Constance, Alemania.



26-07-2011

Objetivos

Al final de este artículo, usted debería ser capaz de:

  • Entender el valor de un despliegue de junta de InfoSphere MDM Server y DataPower SOA Appliances para proteger su solución de datos maestra
  • Demostrar una habilidad para crear Web Service Proxy y políticas de seguridad, al utilizar DataPower SOA Appliances
  • Crear y desplegar en escenario de demostración mostrando cómo se ejecuta una política de seguridad con DataPower protegiendo MDM Server

Condiciones Previas

Este artículo está escrito para arquitectos y especialistas en IT que tienen interés en aprender más sobre dar seguridad a un despliegue de InfoSphere Master Data Management Server. Tener cualquiera de las siguientes aptitudes es una ventaja, al facilitar el entendimiento de este artículo; sin embargo, ellas no son necesarias, debido a que este artículo realiza una introducción de todo lo que se necesita para garantizar su entendimiento:

  • Experiencia y habilidades en el desarrollo de J2EE
  • Familiaridad con servicios web de MDM Server
  • Familiaridad con MDM y la arquitectura de seguridad
  • Familiaridad con DataPower SOA Appliances

Requisitos del Sistema

Este artículo está diseñado para funcionar en un entorno distribuido que consiste de al menos los siguientes sistemas conectados a través de una infraestructura de red TCP/IP:

  • Su laptop hospedando un entorno de desarrollo de MDM Server debería tener:
    • 2GB de memoria o más.
    • 10GB de espacio libre en disco.
    • Cualquier sistema operativo en el que InfoSphere MDM Server V8.5 e IBM Rational® Software Architect 7.0 se pueda instalar. Este artículo también puede trabajar con versiones anteriores del producto, pero el escenario no ha sido probado con ellos. Se utiliza un servicio de MDM Server para mostrar cómo el pedido de este servicio puede ser protegido con DataPower SOA Appliance.
  • El WebSphere DataPower Integration Appliance XI50 como un dispositivo de ejemplo de la familia DataPower SOA Appliance. El escenario también trabaja con WebSphere DataPower XML Security Gateway XS40. Sin embargo, no funciona con WebSphere DataPower XML Accelerator XA35.

Introducción

Este artículo tiene cuatro áreas principales:

El artículo luego concluye con una sección en pruebas.

¿Qué es la gestión de datos maestros?

Una introducción detallada de la gestión de datos maestros (MDM) está más allá del ámbito de este artículo. Este artículo proporciona una introducción muy breve del tema, explicando porqué las compañías que están introduciendo o ya han desplegado un sistema MDM deberían proteger su entorno de MDM. (Para una discusión global sobre la gestión de datos maestros, ver Recursos.)

Los datos maestros son los datos principales de una empresa. Representa entidades tales como el cliente, producto, cuenta, contrato y ubicación, los que ciertamente están entre los activos de información crítica de más valor que una empresa posee. Por ejemplo, la pérdida de información del cliente entrega típicamente un serio golpe para la reputación de una empresa. La Gestión de Datos Maestros es una disciplina que consiste de:

  • Arquitectura de la información
  • Tecnología (productos de software utilizados para desplegar una solución MDM)
  • Procesos y gobernancia de datos para operar una solución MDM, la que incluye un cambio organizacional que introduce un Data Governance Board horizontal a lo largo de una empresa si no se establece previamente
  • Personas

De esa manera, MDM no es sólo una cuestión tecnológica para una empresa; afecta muchos otros aspectos también. Este artículo hace una introducción de los componentes clave desde la perspectiva tecnológica. El software MDM se puede caracterizar entre tres dimensiones clave:

  • Dominios de datos maestros, tales como clientes, proveedores, productos, cuentas, contratos o ubicación con relaciones de dominio-cruzado, tales como productos de clientes o de proveedores
  • Métodos de uso:
    • Método colaborativo de uso caracterizado por personas de departamentos diferentes o con roles de trabajo diferentes que colaboran a través de flujos de trabajo al trabajar con datos maestros. El proceso de New Product Introduction (NPI) es un ejemplo típico
    • El método operacional de uso caracterizado por interacciones en tiempo real y respuestas a solicitudes con sistemas MDM; la creación o la actualización de la información del cliente es un ejemplo típico
    • El método analítico de uso, caracterizado por realizar análisis dentro de sistemas MDM (por ejemplo, descubrir cuántos nuevos clientes fueron adquiridos durante la última semana) o por operacionalizar un entendimiento analítico a partir de Depósito de datos (por ejemplo, entendimiento derivado y agregado de quiénes son clientes rentables) o Sistemas Analíticos de Identidad (por ejemplo, relaciones descubiertas a escondidas que no son obvias para combatir el fraude)
  • Estilos de implementación que proporcionan diferentes niveles de valor para los consumidores de datos maestros y que tienen diferentes características respecto a la complejidad del despliegue:
    • Estilo de Implementación del Registro
    • Estilo de Implementación de Coexistencia
    • Estilo de Implementación de Centro Transaccional

Con una solución MDM, las compañías direccionan problemas comerciales tales como pérdida de oportunidades de ingresos, informes de ingresos imprecisos para clientes y productos, ineficiencias de la cadena de suministro o la falta de conformidad con los reglamentos legales. En el lado técnico, las compañías direccionan problemas calidad de datos maestros para muchas conexiones punto a punto.

Master Data Management y seguridad

Introducir MDM en una empresa crea una paradoja. En un lado de la moneda, el valor de los datos maestros es mejorado significativamente al tenerlo con un sistema de alta calidad, gestionado y centralizado, permitiendo que un sistema visualice ejemplos de datos maestros con una vista de 360 grados. Sin embargo, de igual forma a la moneda, el riesgo de compromiso de los datos maestros aumenta de manera significativa. Ahora un atacador (externo o interno) necesita comprometer sólo un único sistema para obtener acceso a todos los datos maestros. Compare esto para cuando el sistema MDM aún no se introdujo. Un atacador habría necesitado abarcar múltiples sistemas (en grandes empresas, probablemente desde docenas a unos pocos cientos de sistemas) para tener acceso a todas las entidades de datos maestros con menor calidad de datos debido a que la limpieza, tales como la estandarización y la re-duplicación, aún no se han realizado.

Este riesgo aumentado sólo se puede prevenir con la seguridad correcta y bien definida. La buena noticia es que con un sistema centralizado gestionando datos maestros, tal como MDM Server, ahora hay un único logar para aplicar seguridad, reduciendo los costos y la complejidad. Para asegurar una solución MDM Server, es necesario aplicar medidas apropiadas de seguridad para ciertas áreas, como muestra la Figura 1:

Figura 1. Visión general de alto nivel de áreas relacionadas con la seguridad en una solución MDM
Visión general de alto nivel de áreas relacionadas con la seguridad en una solución MDM

Las áreas funcionales incluyen, como mínimo, lo siguiente:

  • Firewalls separando redes—internos y externos (1)
  • Autenticación—repositorios esclavos y maestros LDAP (2)
  • Autorización—MDM Server en WebSphere Application Server (3a y 3b)
    • ¿Quién puede llamar a qué servicio?
    • ¿Quién puede leer/grabar un atributo de una grabación de datos maestros?
  • Auditoría—ESB en MDM Server en WebSphere Application Server (4)
  • Enmascaramiento de datos (por ejemplo, para datos maestros utilizados en desarrollo y pruebas, si los reglamentos lo requieren); no mostrados en la Figura 1
  • Encriptación de datos en descanso (por ejemplo, copias de seguridad)—Servidor de archivo (5)

Se puede encontrar una discusión completa de la arquitectura de seguridad para soluciones de MDM en el Capítulo 4 del libro Enterprise Master Data Management: An SOA Approach to Managing Core Information (IBM Press, 2008). (Ver Recursos.) Los servicios de MDM Server están disponibles como servicios web (además para otros protocolos, tal como la invocación del método remoto), los que incluyen no sólo datos intercambiados, pero también la capa del protocolo para la invocación utilizando SOAP/HTTP o SOAP/HTTPS es una estructura XML. Por consiguiente, las medidas de seguridad necesitan incluir protección eficiente contra ataques XML. En un alto nivel, existen al menos los siguientes cuatro tipos de amenazas XML:

  • Mensaje único y múltiple XML Denial of Service (XDoS) utilizando técnicas tales como elementos de repetición, mega tags, análisis obligatorio y flujo de XML
  • Acceso no autorizado utilizando técnicas tales como ataque al diccionario y mensaje falsificado
  • Integridad de datos y ataques de confidencialidad de datos utilizando mecanismos tales como templadura de datos, XPath, XSLT e inyección SQL (lenguaje de consulta estructurado), o monitoreo de mensajes
  • Compromiso del sistema utilizando métodos tales como infracción del espacio de la memoria o virus

(Las técnicas individuales mencionadas para cada una de las cuatro amenazas, no son una lista completa). Para más detalles sobre esos ataques, ver el artículo "Bill Hines: La amenaza (XML) está ahí..." (developerWorks, Marzo 2006).

La buena noticia es que usted puede proteger MDM Server contra muchas de estas amenazas al utilizar DataPower Appliances, así como WebSphere DataPower XML Security gateway XS40, el que también funciona para el escenario detallado en este artículo.

InfoSphere Master Data Management Server

El IBM InfoSphere Master Data Management Server es una solución integral y de límite destacado, capaz de soportar dominios múltiples de datos maestros, métodos de uso y estilos de implementación soportando todas las demandas comerciales críticas para la gestión de datos. MDM Server en un nivel muy alto consiste de cuatro partes principales:

  • MDM Server en si mismo, que es una aplicación de J2EE que se despliega en un servidor de aplicación J2EE, tal como WebSphere Application Server, explotando capacidades de agrupación en clúster verticales proporcionadas por WebSphere Application Server para calcular y para alta disponibilidad
  • Un motor de base de datos relacional para la persistencia, tales como IBM DB2® en Linux®, UNIX® y Windows® o DB2 en z/SO®
  • Uls basadas en la web para desempeñar tareas como administración y gestión de datos
  • MDM Workbench para el desarrollo dirigido por modelos de nuevos servicios o mejora de los servicios existentes, el que está disponible a través de la herramienta Rational Software Architect

La aplicación MDM que es pura de J2EE, es desarrollada utilizando principios de SOA y en un alto nivel consiste de las siguientes capacidades:

  • Una interfaz de servicio de SOA para más de 800 servicios comerciales soportando la invocación de los servicios comerciales a través de varias tecnologías, donde Web Services, JMS, CICS y Remote Method Invocation (RMI) son los ejemplos mejor conocidos.
  • Una solución de MDM que ofrece más de 800 servicios comerciales listos para usar, para soportar procesos comerciales simples y complejos en datos maestros, tales como ventas cruzadas e incrementos de ventas en Introducción a Un Nuevo Producto. El modelo de datos está basado en modelo de datos probado e integral; y los servicios comerciales son abiertos y fáciles de extender al utilizar MDM Workbench.
  • Los servicios comerciales de MDM con capacidades de integridad de datos severos, tales como prevención duplicada incorporada para hacer cumplir las reglas de integridad de datos maestros, ya que los datos maestros necesitan ser mantenidos con alta calidad. Además, debido a la arquitectura abierta y basada en estándares, los servicios comerciales pueden consumir fácilmente las capacidades de integridad de los datos si es necesario, a partir de plataformas de integración integrales de información, tal como IBM InfoSphere Information Server.
  • Servicios comerciales que soportan reglas comerciales basadas en eventos, tal como notificaciones, ya que los datos maestros deben ser accionables para ser útiles para la explotación. Un ejemplo del mercado bancario podría ser la notificación que un consumidor pueda necesitar un préstamo debido a la detección de un evento de archivo basado en un cambio de datos maestros, indicando que alguien contrajo matrimonio.
  • Servicios comerciales que son habilitados para implementar la autorización en un nivel de atributo o servicio, soportando aspectos de privacidad y seguridad de los datos maestros, ya que necesita seguridad y gobernabilidad.
  • Funciones de MDM data governance— incorporadas en los servicios comerciales MDM que permiten autorización en nivel de atributo y de servicio, permitiendo así la privacidad y seguridad de datos.

La serie de artículos Understand IBM InfoSphere MDM Server security (developerWorks) provee una introducción a los dispositivos de seguridad de MDM Server, donde usted puede encontrar por ejemplo, cómo las interfaces de MDM Server con LDAP proporcionan autenticación en escenarios básicos de seguridad.

WebSphere DataPower SOA Appliances

El WebSphere DataPower SOA Appliances es una familia de productos que contiene:

  • WebSphere DataPower XML Security Gateway XS40
  • WebSphere DataPower Integration Appliance XI50
  • WebSphere DataPower XML Accelerator XA35
  • WebSphere DataPower B2B Appliance XB60
  • WebSphere DataPower Low Latency Appliance XM70

Estos productos son elementos clave que soportan la estrategia integral de SOA de IBM, en particular en el área de ESB. Ellos representan dispositivos de hardware de red fáciles de desplegar y especializados para dar seguridad y simplificar despliegues de servicios web y XML como parte de una implementación de SOA. El proceso de XML es acelerado por el hardware, aumentando el rendimiento y la velocidad del proceso.

Con la adopción rápida de SOA, surgen los siguientes retos clave:

  • Idoneidad: Las pilas complejas de middleware que soportan servicios web, no son fáciles de mantener a lo largo del tiempo, debido a sus interdependencias. Lograr la idoneidad mientras de retiene la sostenibilidad no es así de fácil.
  • Seguridad: Como mostrado arriba, los servicios web son usuarios pesados de XML, y existen muchas formas diferentes de ataque conocidas para XML hoy.
  • Rendimiento: Desde una perspectiva computacional, el proceso de datos representado en XML es más costoso que las representaciones de datos en tipos de datos nativos. De esta manera, la conversión de XML para tipos de datos nativos entendidos por los ciclos de procesamiento de costos de la CPU. Poniendo en la cima cantidades constantemente en crecimiento de datos que necesitan ser procesados e intercambiadas entre sistemas, agrega de manera medible un valor a la demanda de más energía y velocidad de la computación.

Estos tres retos son direccionados por DataPower SOA Appliances y un caso típico de uso es mostrado en la Figura 2. Un caso típico de uso incluye una De-Militarized Zone (DMZ) para separar clientes internos y externos de los sistemas de programas de fondo. Como parte del DMZ, incluyendo un Proxy Reverso, se necesitan firewalls, los que se podrían implementar al utilizar el dispositivo DataPower XS40, por ejemplo. Si hay una aplicación de programa de fondo que ofrece una interfaz basada en XML, tal como los servicios web, DataPower XI 150, pueden ser utilizados.

Figura 2. Un caso de uso típico de DataPower SOA Appliance
Un caso de uso típico de DataPower SOA Appliance

Desde una perspectiva de alto nivel, DataPower SOA Appliances proporciona las siguientes capacidades:

  • Dispositivos de red montables de bastidores
  • Dispositivos de firewall XML/SOAP y seguridad XML en nivel de atributo con validación de datos
  • Control de acceso completo para servicios web XML, incluyendo la virtualización del servicio
  • Intermediación del mensaje y la habilidad para unir redes importantes de transacción para SOAs y ESBs
  • Alto rendimiento acelerado por hardware, pasos múltiples, procesamiento de mensaje con velocidad de alambre para XML-, XSLT-, transformaciones basadas en XPath y validación de esquema XML
  • Gestión de política y del nivel de servicio para servicios web que está centralizado
  • Soporte completo para varios estándares de servicios web (WS), tales como SOAP, WSDL, UDDI, WS-Security, SAML, WS-Federation, WS-Trust, WS-SecureConversation, WS-Policy, WS-SecurityPolicy, WS-ReliableMessaging XKMS, Radius, XML Digital Signature y XML-Encryption
  • Soporte para varios protocolos de transporte, tales como MQ, SSL, HTTP, HTTPS y FTP
  • Transformaciones de mensajes a velocidad de alambre y alta escalabilidad con transformaciones de mensajes de comunicaciones entre todo tipo de dispositivos que soportan formatos tales como texto, binarios, planos, CICS, CORBA o EDI

Para más detalles sobre lo que DataPower SOA Appliances pueden hacer y cómo utilizarlos, ver Recursos.

Con este entendimiento básico de MDM Server y DataPower SOA Appliances, hagamos un resumen sobre en qué partes DataPower SOA Appliances pueden ayudar a proteger su solución MDM basada en MDM Server. Primero, esto le permite prevenir ataques basados en XML. Segundo, usted puede desplegarlos cuando los firewalls son necesarios para compilar un DMZ, por ejemplo. Tercero, ellos le proporcionan las capacidades para implementar autenticación, autorización y facilidades de auditoría poderosas para su solución MDM. Ahora exploremos esto con más detalle, utilizando un escenario e implementación concreta.


El escenario de demostración

Para demostrar cómo MDM Server puede apalancar los servicios de seguridad proporcionados por DataPower Appliances, configuremos un componente proxy del servicio web que hará cumplir las políticas de autenticación y autorización en solicitudes de servicio web de MDM entrantes. Al hacerlo, usted puede lograr:

  • Soporte para despliegues de MDM más allá de los límites empresariales, al proveer autorización de primer nivel y correlación de identidad en DataPower.
  • Soporte para contexto confiable, lo que es un buen enfoque para asegurar servicios MDM. Usted puede utilizar DataPower para restringir qué servicios MDM pueden ser llamados por aplicaciones específicas, declarando un conjunto limitado de identidades. Hoy, MDM permite que cualquier aplicación interna autorizada llame a cualquier servicio con cualquier identidad declarada desde MDM Server.
  • Soporte para autorización dirigida por política. DataPower puede hacer cumplir políticas de autorización escritas en lenguajes estándar como eXtensible Access Control Markup Language (XACML) o distribuidas por otras herramientas como IBM Tivoli Security Policy Manager.
  • Desplegar un firewall XML-aware delante de MDM Server, el que protege MDM Server de amenazas XML como XDos, XML flood y elementos recursivos XML.

El flujo general del escenario descrito en este artículo, es mostrado en la Figura 3:

Figura 3. Visión general del escenario de demostración utilizado en este artículo
Visión general del escenario de demostración utilizado en este artículo

La lista a continuación proporciona una descripción paso a paso del escenario:

  • Paso 1: Un MDM Client Application envía una solicitud de servicio web de MDM a la URL del componente de proxy configurado en el dispositivo de DataPower. Como una parte de la solicitud, la aplicación cliente envía una id de usuario y contraseña de usuario derivada en WS-Security Username Token.
  • Paso 2: El dispositivo DataPower recibe la solicitud, recupera credenciales de usuarios de la señal y autentica al solicitante en un servicio de directorio externo conformista con LDAP.
  • Paso 3: El dispositivo DataPower verifica si le es permitido al usuario llamar el servicio solicitado, al evaluar la política de control de acceso escrita en XACML.
  • Paso 4: El DataPower Appliance correlaciona la id del usuario para la identidad reconocida por MDM Server. Recuerde que actualmente MDM Server proporciona una forma simple de autorización, al utilizar un rol único de J2EE que se llama ServiceConsumer para todos sus servicios. Esto hace posible al adversario declarar cualquier identidad y ejecutar cualquier transacción una vez que es autenticado con el rol ServiceConsumer. Para eliminar esta debilidad, usted puede esconder la identidad actual de MDM desde un MDM Client Application y hacer la autorización del servicio fuera del MDM Server.
  • Paso 5: Si el usuario es autenticado y autorizado para llamar al servicio MDM, el DataPower Appliance desempeña el último paso. Crea una señal LTPA (Lightweight Third-Party Authentication) y la inserta en la solicitud original para autenticarse en MDM Server como un interlocutor válido de servicio. Para generar la señal, el DataPower Appliance utiliza la identidad creada en el paso 4 y claves de cifrado del WebSphere Application Server, donde se despliega el MDM Server destinado.
  • Paso 6: DataPower envía la solicitud MDM con señal inyectada LTPA al MDM Server del programa de fondo.
  • Paso 6: Si el usuario no está listado en el registro LDAP o no está autorizado para llamar al servicio MDM solicitado, luego se envía una respuesta de negación de acceso a MDM Client Application.
  • Paso 7: WebSphere Application Server autentifica la llamada del servicio web al verificar la señal LTPA.
  • Paso 8: MDM Server ejecuta la solicitud y devuelve la respuesta a DataPower Appliance.
  • Paso 9: DataPower Appliance envía la respuesta de vuelta a MDM Client Application.

Creando un proxy para servicios web de MDM Server

Para crear un proxy de servicio web en el WebSphere DataPower Integration Appliance XI50 utilizado en este artículo, son necesarios dos pasos. Primero, usted debe importar las descripciones de los servicios web de MDM; y segundo, debe configurar el proxy. Estos dos pasos están descritos en detalle en las próximas dos secciones.

Importando las descripciones de servicios web de MDM

Encontrando servidores MDM WSDLs y XSDs

WSDLs y XSDs para servicios MDM Party pueden encontrarse en el módulo PartyWSEJB de MDM Server. Si el MDM Server está instalado en WebSphere Application Server, usted puede utilizar WebSphere Integrated Console para encontrar las declaraciones del servicio web. Usted necesita iniciar sesión para la consola y luego seleccionar las siguientes opciones de menú: Aplicaciones > Aplicaciones Empresariales > MDMServer > Publicar archivos WSDL.

El principal componente de DataPower que usted necesita crear, es el Web Service Proxy, el que procesará las solicitudes de servicios web de MDM antes de enviarlas al MDM Server de programa de fondo. Pero, antes de crear un Web Service Proxy, primero necesita hacer disponibles las descripciones de los servicios para el DataPower Appliance. MDM Server entrega las descripciones de sus servicios web en varios archivos interrelacionados de WSDL y XSD. Este artículo describe un ejemplo de la utilización de un servicio a partir del dominio Party de MDM Server. Este artículo por lo tanto, utiliza descripciones de los servicios Party para compilar el Web Service Proxy. La Figura 4 muestra la lista de archivos requeridos WSDL y XSD subidos a DataPower Appliance:

  • AccessDateValue.xsd
  • Business.xsd
  • BusinessIntf.xsd
  • Common.wsdl
  • Common.xsd
  • CommonIntf.xsd
  • Extensions.xsd
  • Hierarchy.xsd
  • Party.xsd
  • PartyBinding.wsdl
  • PartyBusiness.xsd
  • PartyIntf.xsd
  • PartyPort.wsdl
  • PartyService.wsdl
Figura 4. WSDLs y XSDs desde MDM Server subido al DataPower Appliance
WSDLs y XSDs desde MDM Server subido al DataPower Appliance

Creando el proxy

Para crear un nuevo Web Service Proxy utilizando DataPower WebGUI, usted necesita hacer lo siguiente:

  1. Iniciar sesión en DataPower WebGUI como un usuario con nivel de acceso de un desarrollador para el dominio subyacente.
  2. Haga clic en el ícono Web Service Proxy y luego haga clic en el botón Agregar para adicionar un nuevo proxy de servicio web con el nombre que desee (MDM8_WSProxy en el ejemplo).
  3. Seleccione un archivo WSDL del servicio MDM que quiere proteger, utilizando el proxy. En el ejemplo, el archivo WSDL es local://PartyService.wsdl. Cuando agregue una declaración de servicio, cierre las Referencias de Política de uso de WS; de lo contrario, usted puede obtener un mensaje de aviso cuando es proxy está creado.
  4. Agregue uno nuevo o utilice un HTTP Front Side Handler existente, para definir cuál de los puertos de DataPower deberían utilizarse para solicitudes de MDM Service. En la mayoría de los casos, el servicio web será invocado utilizando HTTP. Por consiguiente, su manejador debe ser capaz de aceptar solicitudes HTTP1.1 enviadas utilizando el método POST.
  5. Especifique el nombre de host y el número de puerto del programa de fondo de MDM Server.

La ventana de resultado de la configuración inicial del Web Service Proxy, debería verse similar a la que se muestra en la Figura 5:

Figura 5. Configuración inicial de un nuevo Web Service Proxy
Configuración inicial de un nuevo Web Service Proxy

Compilando una política de seguridad para MDM Server

Para implementar los requisitos de seguridad destinados en este artículo, usted necesita crear una nueva Política de Autenticación, Autorización y Auditoría (AAA). La Política AAA es un mecanismo bastante poderoso y flexible para implementar los requisitos de seguridad. El ejemplo de artículo utiliza la Política AAA para lograr lo siguiente:

  • Autenticar las solicitudes entrantes de MDM utilizando el directorio externo LDAP
  • Autorizar las solicitudes basado en las credenciales del usuario desde la cabecera de la solicitud y servicio llamado MDM, donde una política expresada en XACML es utilizada como una base para la toma de decisión de la autorización
  • Correlacionar las credenciales de usuarios autorizados a las credenciales usadas por MDM Server
  • Reemplazar la señal de seguridad en la solicitud con la que puede ser autenticada por el MDM Server

Utilizando un proxy de Web Service configurado en DataPower, como muestra la Figura 6, las políticas, tales como las de autenticación o autorización, pueden ser implementadas por DataPower, estando entre una llamada de cliente de servicios MDM e InfoSphere MDM Server. De esta manera, cada vez que un servicio MDM es llamado, DataPower hace cumplir las políticas de seguridad apropiadas, antes de enrutar la llamada para MDM Server.

Figura 6. Componentes de la política utilizados en el escenario de demostración
Componentes de la política utilizados en el escenario de demostración

Para crear una Política AAA, diríjase a la lista de objetos de DataPower y encuentre Política AAA. Agregue una nueva política con un nombre de su elección (MDM8_AAAPolicy en el ejemplo del artículo).


Autenticación

El escenario en este artículo utiliza DataPower Appliance para autenticar solicitudes MDM al utilizar un servidor de directorio de conformidad con LDAP. Para implementar este requisito, usted debería configurar de manera correcta la identificación y la autenticación de la identidad de un usuario. Para la identificación, usted puede utilizar la señal WS-Security Username, que está incorporada en la cabecera del mensaje SOAP enviado por la aplicación del cliente. Es responsabilidad de la aplicación del cliente, compilar una señal correcta de WS-Security Username, e incluirla en la llamada del servicio web, el que está utilizando un canal de comunicación cifrado, así como SSL para proteger la contraseña. El listado 1 muestra un ejemplo de una señal WS-Security Username incorporada a la solicitud de servicio web de MDM:

Listado 1. Ejemplo de solicitud de servicios web de MDM con señal de nombre de usuario de WS-Security
 <soapenv:Envelope
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Header>
        <wsse:Security soapenv:mustUnderstand="1"
        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
        secext-1.0.xsd"> <wsse:UsernameToken>
        <wsse:Username>ivan</wsse:Username> <wsse:Password
        Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
        token-profile-1.0#PasswordText">secret</wsse:Password>
        </wsse:UsernameToken> </wsse:Security>
        </soapenv:Header> <soapenv:Body> <p388:SearchPerson
        xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
        <control> <requestId>1</requestId>
        <requesterName>ivan</requesterName>
        <requesterLanguage>100</requesterLanguage>
        </control> <personSearch>
        <givenNameOne>%</givenNameOne>
        <lastName>Carlos</lastName> </personSearch>
        </p388:SearchPerson> </soapenv:Body>
        </soapenv:Envelope>

Para estar seguro de que DataPower Appliance acepta este tipo de señal, usted debería seleccionar la caja de diálogo Password-carrying UsernameToken Element from WS-Security Header en la pestaña Identidad de la pantalla de configuración de la Política AAA. Para habilitar la autenticación basada en LDAP, usted debe seleccionar el método de autenticación Bind to Specified LDAP Server en la pestaña Authenticate de la pantalla de configuración de la Política AAA, como muestra la Figura 7. También necesita rellenar en otros parámetros LDAP (Host, Puerto, Prefijo LDAP DN, Sufijo LDAP DB, atributo de Búsqueda LDAP) específicos para el servidor LDAP particular.

Figura 7. Configurando una Política AAA para uso en un servidor de directorio LDAP para autenticación
Configurando una Política AAA para uso en un servidor de directorio LDAP para autenticación

Autorización transaccional

Esta sección describe cómo configurar un ejemplo de Política AAA para uso por DataPower para realizar la autenticación, basado en el nombre del servicio MDM. Esta funcionalidad es esencialmente equivalente a la autorización transaccional proporcionada por MDM Server y descrita en el artículo "Comprendiendo la seguridad de IBM InfoSphere MDM Server, Parte 3: Utilizando LDAP para implementar autorización de transacción" (developerWorks, Noviembre 2008). Pero hay una diferencia esencial. El mecanismo de autorización mostrado en este artículo, está basado en la política. Eso quiere decir que las reglas para la autorización pueden ser declaradas en una política, utilizando un lenguaje estándar como XACML, y luego distribuidas para DataPower Appliance para su ejecución. Las políticas pueden ser creadas manualmente como uno o varios documentos XML, o pueden ser autorizadas utilizando un software de gestión especializado en política, como IBM Tivoli® Security Policy Manager. De esta forma, tanto la gestión de política como su ejecución, pueden ser externalizadas desde MDM Server.

IBM Tivoli Security Policy Manager

IBM Tivoli Security Policy Manager es un producto relativamente nuevo de IBM para la gestión centralizada de políticas de seguridad. Tivoli Security Policy Manager permite a los autores de políticas crear políticas de control de acceso y adjuntarlas a servicios particulares. Luego el Tivoli Security Policy Manager distribuye las políticas para sus destinos para distribuciones, donde las políticas pueden ser ejecutadas. Tivoli Security Policy Manager soporta DataPower Appliances como uno de los destinos de distribución.

Política XACML para autorización transaccional MDM

Para implementar una autorización basada en XACML, usted primero necesita grabar una política. XACML es un estándar flexible y permite a los autores de políticas compilar políticas de control de acceso. Pero en este escenario, usted no necesita el poder completo de XACML y compilará una política bastante simple. Independientemente de la forma o formato que usted utilice para declarar la política de control de acceso, es necesario que siempre identifique dos cosas:

  • Asunto del control de acceso
  • Recurso gobernado por la política

Como es lógico, en el ejemplo de este artículo, el asunto para el control de acceso, es la llamada del usuario para un servicio MDM. El ejemplo define el servicio llamado MDM como un recurso (el término transacción MDM, es equivalente—por eso se llama de una autorización transaccional). En el ejemplo, definimos una política simple que brinda dos niveles diferentes de acceso a los usuarios dmitriy e ivan (ver MDM8-tx-policy.xml en el archivo resources.zip en la sección Descargar). De acuerdo con la política, se le permite al usuario ivan llamar a cualquier transacción, y el usuario dmitriy puede llamar sólo a una de las siguientes transacciones: SearchPerson, GetPerson, AddPerson y UpdatePerson. A fin de ejecutar esta política utilizando DataPower Appliance, usted necesita subir el archivo de la política al dispositivo, para luego crear un componente XACML Policy Decision Point (PDP), el que utilizará el archivo de la política para evaluar la toma de decisiones del control de acceso.

Creando un Punto de Decisión de Política XACML

Para crear un XACML PDP utilizando WebGUI de DataPower, usted necesita encontrar XACML Policy Decision Point en la lista de objetos de DataPower. Al configurar PDP, asegúrese de que tiene un único nombre (MDB8_TX_PDP en el ejemplo) y que utiliza el archivo de política que ya creó. La Figura 8 muestra un ejemplo de configuración XACML PDP:

Figura 8. Configurando un Punto de Decisión de Política XACML
Configurando un Punto de Decisión de Política XACML

Autorización en una Política AAA

Después de crear XACML PDP, usted necesita configurar una Política AAA para usarla para la autorización. A fin de lograr esto, es necesario que haga lo siguiente:

  1. Seleccione Nombre local del Elemento de Solicitud en la pestaña de Recurso de la pantalla de configuración de la Política AAA. De esta manera usted declara de DataPower Appliance debe usar el nombre del servicio MDM como un recurso para la autorización.
  2. Seleccione Usar decisión de XACML Authorization como un método de autorización en la pestaña Autorizar de la Política AAA. Usted también necesita seleccionar el XACML PDP recién creado en la lista de Puntos de Decisión de Política.

Transformación de SOAP-para-XACML

Finalmente, usted necesita definir cómo las solicitudes de servicios web deberían ser transformadas en solicitudes XACML. El estándar XACML (ver Recursospara más información) requiere que todas las solicitudes de autorización sean definidas de acuerdo con la solicitud XACML y con el esquema de respuesta. Por lo demás, el motor XACML, que está incorporado a DataPower en este caso, no sabe cómo evaluar las solicitudes. Por lo tanto, es necesario que usted defina la hoja de estilo XSLT que transforma paquetes entrantes de SOAP en solicitudes XACML. En el ejemplo, esta hoja de estilo está declarada en el archivo llamado MDM8-soap-to-xacml.xsl (ver MDM8-soap-to-xacml.xsl en el archivo resources.zip en la sección Descargar). Su implementación es bastante simple y puede ser reutilizada fácilmente. El detalle interesante sobre esta hoja de estilo, es que utiliza algunas variables proporcionadas por la extensión DataPower XSLT.

Listado 2. Fragmento XSLT para transformar paquetes SOAP en solicitudes XACML al utilizar variables de extensión de DataPower
 <Subject> <Attribute
        AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
        DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>
        <xsl:value-of select="dp:variable('var://context/WSM/identity/username')" />
        </AttributeValue> </Attribute> </Subject>
        <Resource> <Attribute
        AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
        DataType="http://www.w3.org/2001/XMLSchema#string"> <AttributeValue>
        <xsl:value-of select="dp:variable
        ('var://context/WSM/resource/extracted-resource')"/> </AttributeValue>
        </Attribute> </Resource>

Por ejemplo, el fragmento XSLT mostrado en el Listado 2, si aplicado a la solicitud MDM mostrada en el Listado 1 generará la solicitud XACML proporcionada en el Listado 3:

Listado 3. El fragmento de la solicitud XACML como un resultado de transformación XSLT proporcionada en el Listado 2
 <Subject> <Attribute
        AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
        DataType="http://www.w3.org/2001/XMLSchema#string">
        <AttributeValue>dmitriy</AttributeValue>
        </Attribute> </Subject> <Resource>
        <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
        DataType="http://www.w3.org/2001/XMLSchema#string">
        <AttributeValue>SearchPerson</AttributeValue>
        </Attribute> </Resource>

Cuando XACML PDP observa una solicitud como la del Listado 3, la aplica para la política subyacente y devuelve una respuesta, la que es básicamente una respuesta simple de si el acceso debería ser otorgado o denegado. Si el acceso es denegado, DataPower Appliance envía la respuesta de acceso denegado para MDM Client Application y deja el MDM Server sin tocar. Apuntar la Política AAA a la hoja de estilo de la transformación, es la última parte de la configuración que usted necesita hacer para implementar la autorización transaccional, como muestra la Figura 9. Seleccionar y configurar parámetros, tal como la versión XACML, así como también la ubicación del script de transformación.

Figura 9. Autorización transaccional configurada en una Política AAA
Autorización transaccional configurada en una Política AAA

Autenticación en el MDM Server del programa de fondo

El último escenario es la autenticación en el MDM Server del programa de fondo. Una de las metas de este artículo es demostrar que la seguridad de MDM server puede ser totalmente externalizada para un proveedor externo como DataPower. Nuestras configuraciones de DataPower cuidan la autenticación del usuario y la autorización basada en política de las solicitudes del usuario. Pero incluso en este escenario, usted necesita un cierto nivel de seguridad aparte del MDM Server. Necesita al menos estar seguro de que MDM Server le habla al proveedor de seguridad correcto. En otras palabras, usted necesita autenticar el DataPower Appliance en MDM Server. A fin de lograr esto, es necesario que haga lo siguiente:

  • Elegir el mecanismo de autenticación. Al ser una aplicación conformista de J2EE, el MDM Server puede apalancar las capacidades de autenticación de la infraestructura subyacente de J2EE Application Server. El escenario del artículo utiliza WebSphere Application Server y el mecanismo de IBM Lightweight Third-Party Authentication (LTPA).
  • Configurar requisitos de autenticación en MDM Server complementario. Ciertos cambios deben realizarse para el despliegue de MDM Server para estar seguro de que entiende la autenticación LTPA. (Ver el recuadro lateral LTPA.)
  • Correlacionar la identidad de las solicitudes entrando en DataPower Appliance para identidades esperadas por el MDM Server. La correlación de identidad no es un enfoque requerido, pero generalmente es recomendado en los casos cuando la autorización de usuario y servicio ocurre fuera del proveedor de servicio. Éste permite la separación de identidades utilizadas por el servidor del programa de fondo y las aplicaciones del cliente, las que se pueden considerar un nivel extra de seguridad.
  • Configurar un DataPower Appliance cumpliendo con el mecanismo de autenticación requerido por MDM Server. En el caso de LTPA y servicios web, usted necesita estar seguro de que DataPower Appliance genera señales correctas de LTPA y que las inserta en la solicitud del servicio antes de enviarlas al MDM Server del programa de fondo.

Autenticación basada en LTPA en MDM Server y WebSphere

Lightweight Third-Party Authentication

Lightweight Third-Party Authentication (LTPA) es un tipo de mecanismo de autenticación en la seguridad de WebSphere Application Server que define un formato particular de la señal. Cuando usted utiliza el método LTPA con Web Services, se genera la señal de seguridad <wise:BinarySecurityToken>.

A fin de estar seguro de que MDM Server acepta señales LTPA y que las puede autenticar, se requieren algunos cambios en el despliegue de MDM Server. Estos cambios pueden ser realizados antes o después que el MDM Server es desplegado. El artículo "Seguridad de servicios web con WebSphere Application Server V6, Parte 4" (developerWorks, Julio 2006) describe cómo configurar un servicio web desplegado en WebSphere Application Service para consumir señales LTPA. En el caso de MDM Server, las configuraciones con absolutamente las mismas. En el ejemplo del artículo, cambiamos los descriptores de despliegue sólo para MDM PartyServices (ver los archivos de enlace de WebSphere ibm-webservices.ext.xmi e ibm-webservices-bnd.xmi en el archivo resources.zip en la sección Descargar).

Otro aspecto de la autenticación LTPA es la compartición de claves de cifrado. El ejemplo del artículo quiere que DataPower Appliance genere señales correctas de LTPA, y esto sólo es posible si el dispositivo y WebSphere Application Server comparten el conjunto de claves de cifrado. Aseguramos esto al exportar las claves desde el servidor de aplicación y al subirlas al DataPower Appliance. Para exportar las claves LTPA a partir de WebSphere Application Server 6.1, usted puede seguir las instrucciones proporcionadas en la sección "Exportando claves Lightweight Third Party Authentication" de WebSphere Application Server Information Center (ver Recursos). Cuando las claves son exportadas, pueden ser subidas al DataPower Appliance como cualquier otro archivo.

Correlación de identidad

Como antes mencionado, la correlación de identidad agrega una capa adicional de seguridad al escenario. Cuando las aplicaciones del cliente y los servidores del programa de fondo utilizan diferentes conjuntos de identidades y sólo el componente intermediario de seguridad o ESB sabe correlacionar una a otra, se hace más problemático para los usuarios maliciosos en un lado del cliente sortear el intermediario y comprometer el servidor del programa de fondo.

Una posibilidad para implementar la correlación de identidad en DataPower Appliance es crear un nuevo archivo de información de AAA y adjuntarlo a la Política AAA. El archivo de información AAA es un documento XML que incluye diferentes aspectos de la configuración de la política AAA. Los desarrolladores no necesitan conocer el formato del archivo porque todos los cambios pueden realizarse al utilizar DataPower WebGUI. El ejemplo del artículo utiliza el archivo de información AAA para definir las reglas de correlación de identidad. A fin de crear un archivo de información AAA, vaya a la pestaña MapCredentials de la pantalla de configuración de la política AAA y seleccione Archivo de Información de AAA como un método para la correlación. Luego haga clic en el botón + (más/agregar) y pase por una serie de pantallas definiendo diferentes aspectos de la política AAA. El archivo de información de AAA puede ser utilizado no sólo para la correlación de identidad, pero también para autenticación y autorización. Este ejemplo del artículo no requiere eso. La única configuración necesaria, es declarar las identidades entrantes (ver Figura 10) y cómo deberían ser correlacionadas (ver Figura 11). Note que así como un destino de correlación, utilizamos la identidad usada por IBM WebSphere Application Server, y que será cifrada en la señal LTPA. Usted puede encontrar un ejemplo de AAA Info File utilizado en este escenario incluido con el artículo descargar (ver MDM8_AAAInfoFile.xml en el archivo resources.zip).

Figura 10. Declaración de identidad en un archivo de información de AAA
Declaración de identidad en un archivo de información de AAA
Figura 11. Declaración de identidad en un archivo de información de AAA
Declaración de identidad en un archivo de información de AAA

Generación de señal LTPA

Después que la correlación de identidad es configurada y MDM Server está listo para consumir señales LTPA, hay un último paso que hacer, que es configurar DataPower Appliance para generar señales LTPA e insertarlas en todas las llamadas entrantes de servicio web de MDM. Esto se puede hacer en la pestaña PostProcessing de la pantalla de configuración de la Política AAA, como muestra la Figura 12. A fin de lograr esto, es necesario que siga los siguientes pasos:

  1. Seleccione on para Generar señal LTPA.
  2. Para la versión LTPA Token, seleccione WebSphere versión 2 para IBM WebSphere Application Server 6.1 y superior.
  3. Especifique el archivo clave LTPA, exportando anteriormente desde WebSphere Application Server.
  4. Ingrese la contraseña de LTPA, que debe ser la misma utilizada para exportar claves desde WebSphere Application Server.
  5. Seleccione on para Recortar Señal en una Cabecera de Seguridad WS-Security. Si esta opción es on, DataPower recortará la señal LTPA en WS-Security BinarySecurity Token y la insertará en una solicitud de servicio web. Esta opción es crítica en este escenario. Debido a los cambios en las configuraciones de MDM server, sólo aceptará solicitudes con señales LTPA incorporadas.
Figura 12. Configurando la generación de señal LTPA en una Política AAA
Configurando la generación de señal LTPA en una Política AAA

Adjuntando la política de seguridad al componente de proxy

Política AAA

La Política AAA también puede ser agregada al Web Service Proxy utilizando una lista de selección en la pestaña de proxy Settings en la pantalla de configuración de Web Service Proxy. Pero al momento de escribir este artículo, esta opción de configuración no estaba funcionando completamente. Debería ser fijada en los próximos releases de DataPower firmware.

Después que se crea una Política AAA, se puede adjuntar a uno o varios de los componentes de Web Service Proxy. Para hacerlo, diríjase a la pantalla de configuración de Web Service Proxy y arrastre y suelte una nueva Acción AAA a la regla de la solicitud de su proxy. La configuración de regla de solicitud puede encontrarse en la pestaña de Política de la pantalla de configuración de proxy, como muestra la Figura 13. Según esta configuración, DataPower Appliance ejecutará la Política AAA para cada y todas las solicitudes entrantes de servicio web.

Figura 13. Política AAA adjuntada a Web Service Proxy
Política AAA adjuntada a Web Service Proxy

Realizar prueba

Para demostrar las capacidades de seguridad de la solución demo, ejecutemos varias llamadas de servicio web MDM y analicemos los resultados. Primero echemos un vistazo a la solicitud mostrada en el Listado 1. Como puede ver, esta solicitud contiene credenciales de usuario de un usuario nombrado ivan. El Listado 4 muestra el paquete SOAP temporal, el que es construido por DataPower después de ejecutar las políticas de seguridad y antes de enviarlo al MDM Server del programa de fondo. Usted puede observar que eso contiene la señal LTPA incorporada, en vez de la señal original de nombre de usuario.

Listado 4. Paquete SOAP modificado por DataPower Appliance y enviado al MDM Server
        <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
        <soapenv:Header> <wsse:Security soapenv:mustUnderstand="1" 
		xmlns:wsse=
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
	   >
        <wsse:BinarySecurityToken 
		wsu:Id=
		"SecurityToken-ff960367-3c49-4913-b0a7-9f8358943297"
        EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-
        message-security-1.0#Base64Binary" ValueType="wsst:LTPA"
        xmlns:wsst="http://www.ibm.com/websphere/appserver/tokentype/5.0.2"
        xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
        wssecurity-utility-1.0.xsd">
        Ac1aDJ17IJSJ5aaaG390MM6Ys9eOzxiVmaXDVA5pe3qV89602u3Ssmraa3oykgNzHhvEOZa2GHbRMj2
        K3RJWLuD8KB3eH1s8uMLfvNo9hS4Yj9hFKzC8oi1vzTdEwhwMcde6VXXXH+SsZJ4p0YpEKClg7rcukb
        feJ+/cOjfZNkcWwCNtj9TginFPWx5iwDBRZ8fmX+8LHd3ZEepS8U1+WZ2CpYqNDYZr+6h19lINyDvBj
        hiOStn6bKbAf+u/mHJ7Yd2ISoZHfXnyQ2Nr60FcWuv7uvbc+g5JJ9ZjQhFqLtWcyd4/5ehRoOIXA3tT
        x1Vc/7ajy11SKwwaNrOzsNtyEl2qoOglAeTDYR8LZgjW7WSln+kwdM+ZN3jrfgC0FClw
        </wsse:BinarySecurityToken> </wsse:Security>
        </soapenv:Header> <soapenv:Body> <p388:SearchPerson
        xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
        <control> <requestId>1</requestId>
        <requesterName>ivan</requesterName>
        <requesterLanguage>100</requesterLanguage>
        </control> <personSearch>
        <givenNameOne>%</givenNameOne>
        <lastName>Carlos</lastName> </personSearch>
        </p388:SearchPerson> </soapenv:Body>
        </soapenv:Envelope>

Listado 5 muestra el resultado final de la ejecución de esta solicitud de MDM:

Listado 5. Respuesta del servicio web de MDM para la transacción ejecutada exitosamente de MDM
        < <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header
        /> <soapenv:Body> <p388:SearchPersonResponse
        xmlns:p388="http://www.ibm.com/xmlns/prod/websphere/wcc/party/port">
        <result> <control>
        <requestId>1</requestId>
        <requesterName>ivan</requesterName>
        <requesterLanguage>100</requesterLanguage>
        <requesterLocale>en</requesterLocale> </control>
        <serviceTime>P0Y0M0DT0H0M7.203S</serviceTime>
        <status> <processingStatus
        code="0">SUCCESS</processingStatus> </status>
        <searchResult>...</searchResult>
        <searchResult>...</searchResult> </result>
        </p388:SearchPersonResponse> </soapenv:Body>
        </soapenv:Envelope>

Cambiemos, por el bien del experimento, la señal del nombre del usuario en la solicitud inicial a la mostrada en el Listado 6 (el usuario miguel no está autorizado a llamar a cualquier transacción a través de nuestra política XACML):

Listado 6. Señal del nombre de usuario con una nueva identidad
 <wsse:UsernameToken>
        <wsse:Username>miguel</wsse:Username> <wsse:Password
        Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
        token-profile-1.0#PasswordText">secret</wsse:Password>
        </wsse:UsernameToken>

Obtendrá una respuesta de anomalía, como muestra el Listado 7, lo que quiere decir que la política de autorización se ejecutó exitosamente:

Listado 7. Respuesta de anomalía a partir de DataPower Appliance como resultado de una política de control de acceso ejecutada
 <?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>Rejected by policy. (from client)</faultstring>
        </env:Fault> </env:Body> </env:Envelope>

Conclusión

Este artículo le mostró cómo DataPower Appliance puede ser utilizado y configurado para proteger el MDM Server, al gestionar las principales entidades empresariales—los datos maestros en un ambiente de SOA. Con el límite principal DataPower SOA Appliance, es fácil proteger su despliegue de MDM Server y aplicar la autenticación, autorización y políticas de auditoría de manera correcta para una ejecución consistente.

Aceptación

Nos gustaría agradecerle a nuestro colega y tutor Ivan Milman por sus sugerencias y retroalimentación en este artículo.


Descargar

DescripciónNombretamaño
Sample files used in articleresources.zip4KB

Recursos

Aprender

Obtener los productos y tecnologías

  • Compile su próximo proyecto de desarrollo con el software de prueba de IBM, disponible para descarga directa desde developerWorks.

Comentar

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=Information mgmt, WebSphere
ArticleID=458654
ArticleTitle=Potenciar DataPower SOA Appliances para extender las capacidades de seguridad de InfoSphere Master Data Management Server
publish-date=07262011