Descargue tareas de seguridad de servicios web WebSphere a IBM WebSphere DataPower de SOA Appliance: Parte 4: ¿Está listo para una conversación segura?

Ejemplos de conversación WS-Secure

En este artículo desarrollaremos el escenario previamente mencionado, implementando el WebSphere DataPower SOA Appliance en un escenario de conversación WS-Secure. WebSphere DataPower SOA Appliance procesará la parte de WS-Security para el servidor de la aplicación después de establecer un contexto seguro según la Especificación WS-Security.

ShiuFun Poon, Software Engineer, Lotus

Shiu Fun Poon es Ingeniera y Technical Lead del grupo IBM WebSphere DataPower Security. Se interesa en todos los aspectos de SOA, y trabaja sobre las características que proveen soporte de Web Services Security de acuerdo con OASIS, W3C, Especificación WS-Security y otros aspectos adicionales relacionados con la seguridad en el Dispositivo IBM WebSphere DataPower. También contribuye a mejorar la Reliable Availability Serviceability [RAS] del dispositivo. Antes de formar parte de DataPower, fue Tech Lead del Domino Security Team.



Maryann Hondo, Senior Technical Staff Member, IBM

Maryann Hondo es Senior Technical Staff Member del WebSphere Technical Institute de IBM, donde trabaja con dispositivos WebSphere DataPower, arquitecturas SOA, directivas SOA y seguridad SOA. Maryann trabajó previamente en la organización de servicios empresariales de IBM con activación SOA, enfocándose en servicios de seguridad. Es coautora de las especificaciones WS Security, WS-Trust, WS-SecureConversation, WS-Policy y WS-Federation, producidas por IBM y otras empresas colaboradoras en el contexto del Web Services Security Roadmap.



03-08-2011

Introducción

En 2002, un pequeño grupo de colegas de IBM se reunió con un equipo de Microsoft para redactar un documento que describiera una implementación por fases de especificaciones de tecnología de seguridad XML con el objetivo de soportar una variedad de escenarios de seguridad para servicios web. Hoy en día, la mayor parte de las personas coincide en que la base de la construcción es sólida. SOAP y WS-Security son estándares reconocidos e implementados. WS-Policy y WS-Trust también se han vuelto estándares en W3C y OASIS, respectivamente, y son características comunes en los entornos de seguridad de servicios web. WS-Privacy, WS-Federation y WS-Authorization han encontrado competencia en el mercado. El modelo de servicios web fue concebido para dar a los desarrolladores de aplicaciones SOA un conjunto común de servicios de seguridad que puedan utilizar de manera independiente o en una aplicación compuesta, en lugar de que cada código de aplicación/servicio tenga su propia seguridad. Recientemente se estandarizaron otras dos piezas del mapa de ruta: Las Especificaciones WS-SecureConversation y WS-Security. WS-SecureConversation describe cómo establecer claves de sesión, claves derivadas y claves por mensaje, de manera que dos partes puedan comunicarse de una manera segura a lo largo de una transacción o conversación de larga ejecución como una optimización, en lugar de negociar la seguridad para cada mensaje. Secure Conversation se concibió para permitir la implementación de un intercambio de larga ejecución sobre WS-Security y WS-Trust. El mapa de ruta del documento definió un conjunto de escenarios que son habilitados por Secure Conversation (Enabling Federation , Supporting Validation Services, Delegation, Access Control), y el trabajo descripto aquí por las organizaciones de desarrollo y de campo de WebSphere DataPower es evidencia de su realidad.

Hoy en día, la mayor parte de las personas coincide en que la base de la construcción es sólida. SOAP y WS-Security son estándares reconocidos e implementados. WS-Policy y WS-Trust también se han vuelto estándares en W3C y OASIS respectivamente, y son características comunes en los entornos de seguridad de servicios web. WS-Privacy, WS-Federation y WS-Authorization han encontrado competencia en el mercado por parte de una variedad de iniciativas relacionas con soluciones para Single Sign On y de modelos de programación centrada en la identidad, como Liberty o SAML. Asimismo, la evolución continua de las aplicaciones Web, desde páginas Web estáticas a patrones de acceso basado en REST y AJAX con contenido dinámico, estimularon a los desarrolladores Web/de nubes a explorar estrategias alternativas de seguridad como OAuth, OpenID. El modelo de servicios web se concibió para ofrecar a los desarrolladores de aplicaciones SOA un conjunto común de servicios de seguridad que puedan utilizar de manera independiente o en una aplicación combinada, en lugar de hacer que cada código de aplicación/servicio tenga su propia seguridad a través de interfaces de programación de aplicaciones (API). Sin embargo, todavía hay muchas API y estrategias para desarrolladores y, con la demanda continua de aplicaciones Web de redes sociales, continúa la elección del paradigma de “aplicación Web” frente al paradigma de “servicio web”.

Recientemente se estandarizaron otras dos piezas del mapa de ruta, las Especificaciones WS-SecureConversation y WS-Security. WS-SecureConversation describe cómo establecer claves de sesión, claves derivadas y claves por mensaje, de manera que dos partes puedan comunicarse de una manera segura a lo largo de una transacción o conversación de larga ejecución como una optimización en lugar de negociar la seguridad por cada mensaje. Secure Conversation se concibió para permitir que los servicios web describan cómo puede un servicio intercambiar contexto de manera segura (una recopilación de notificaciones sobre atributos de seguridad y datos relacionados) en base a los conceptos de emisión de un token de seguridad y a mecanismos definidos en las especificaciones básicas de WS-Security y WS-Trust. Usando estos mecanismos, un servicio web puede habilitar un intercambio de larga ejecución y podría nivelar esta “conversación” sobre un protocolo http de nivel de transporte existente. Esto permitiría que un intercambio de larga ejecución use operaciones criptográficas simétricas que permitan proteger los mensajes durante una sesión establecida. Las operaciones criptográficas simétricas son más eficientes que las operaciones criptográficas asimétricas estándar.

Hay muchos escenarios que requieren las capacidades de seguridad de Secure Conversation. El mapa de ruta del documento define un conjunto de las que son habilitadas por Secure Conversation:

  • Habilitar Federación
  • Soportar Servicios de Validación
  • Delegación
  • Control de Acceso

Caso de uso para una conversación segura

El siguiente caso de uso se basa en datos técnicos y de negocios de Rene Kiessling, Manuel Rohmann, Matt McLarty y Gari Singh. En este artículo exploramos un escenario en el cual se establece confianza entre el STS de WebSphere DataPower [que actúa como un proxy a un Proveedor de Servicios] y el Microsoft Identify Provider, IdP, para facilitar una Conversación Federada Segura. En el caso de WebSphere DataPower, ésta es una ilustración de cómo implementar un escenario de cliente que usa los marcos de directiva de WebSphere DataPower con un cliente Microsoft que usa wsFederationHttpBinding de Microsoft. El dispositivo SOA WebSphere DataPower se utiliza también para aplicar la directiva de seguridad de servicio web que la conversación segura requiere. El escenario se implementa sobre:

  • Framework Microsoft WCF .Net 3.5
  • Firmware WebSphere DataPower, versión 3.7.3.3 o superior
  • Cualquier Servidor de Aplicación para el back-end; en esta instancia, usaremos WebSphere Application Server como servidor de aplicación de back-end

La Aplicación expresa un requisito para una Conversación Segura (esto puede implementarse adjuntando una directiva de seguridad a la aplicación WSDL) entre el proveedor de la aplicación y el cliente. A fin de establecer una Conversación Segura, el dispositivo WebSphere DataPower de SOA debe tener:

  1. Capacidad para autenticar el cliente validando una firma SAML 1.1, en el caso de este ejemplo. Un procesamiento personalizado adicional puede ser necesario para gestionar un escenario especial; ver las [Otras Consideraciones] al final del artículo.
  2. Capacidad para confiar en el IdP que emite el token SAML (el IdP de Microsoft).
  3. Capacidad para generar un token de conversación segura que WebSphere DataPower y el cliente WCF de Microsoft puedan usar para asegurar los mensajes intercambiados.

El intercambio entre las partes incluye las siguientes interacciones:

  1. Un cliente Microsoft WCF .Net 3.5 contactará un Proveedor de Identidad, IdP, para adquirir un token SAML 1.1 [ésta es una implementación de un escenario de “Federación”].
  2. El IdP emite un token SAML1.1 al cliente Microsoft WCF .Net 3.5
    - El token emitido es firmado por el IdP de Microsoft.
  3. Un cliente Microsoft WCF .Net 3.5 accederá a un servicio web a través de WebSphere DataPower.
  4. En el flujo del mensaje de aplicación propiamente dicho, WebSphere DataPower, actuando como un STS, emitirá un Token de Conversación Segura para el cliente WCF .Net 3.5 de Microsoft.
  5. El tráfico se protege con el Token de Conversación Segura obtenido en el paso 4.
  6. Una vez que el Cliente ha completado el intercambio del mensaje de aplicación durante una sesión de conversación segura, el cliente emitirá una operación de Cancelación a WebSphere DataPower para indicar la terminación de la sesión de conversación segura.
Figura 1. Intercambio de mensajes durante una sesión de conversación segura
Intercambio de mensajes durante una sesión de conversación segura

Paso1. Configuración del cliente

En el caso del cliente [WCF], es necesario el app.config correspondiente:

Listing 1. app.config for configuring client
                <bindings>
                <wsFederationHttpBinding>
                <binding name="EchoUserWithoutTlsNego" closeTimeout="00:05:00"
                openTimeout="00:05:00" receiveTimeout="00:30:00"                
                sendTimeout="00:05:00">
                <security mode="Message">
                <message issuedTokenType=
                "http://docs.oasis-open.org/wss/
                oasis-wss-saml-token-profile-1.1#SAMLV1.1"
                negotiateServiceCredential="false" >
                <issuer address="http://localhost:6000/SimpleActiveSTS"              
                binding="wsHttpBinding" bindingConfiguration=
                "http://localhost:6000/SimpleActiveSTS">
                <identity>
                <userPrincipalName value="DEMOSERVER\Administrator" />
                </identity>
                </issuer>
                <issuerMetadata address="http://localhost:6000/SimpleActiveSTS/mex" />
                <claimTypeRequirements>
                <add claimType="http://schemas.xmlsoap.org/ws/
                2005/05/identity/claims/name"  />
                <add claimType="http://schemas.datapower.com/E8/
                2008/09/Identities/RZUserId" />
                </claimTypeRequirements>
                </message>
                </security>
                </binding>
                </wsFederationHttpBinding>
                
                <wsHttpBinding>
                <!-- communctaion to local STS service -->
                <binding name="http://localhost:6000/SimpleActiveSTS" 
                closeTimeout="00:05:00"
                openTimeout="00:05:00" receiveTimeout="00:30:00" 
                sendTimeout="00:05:00"
                bypassProxyOnLocal="false" transactionFlow="false" 
                hostNameComparisonMode="StrongWildcard"
                maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                allowCookies="false">
                <readerQuotas maxDepth="32" maxStringContentLength="8192"
                maxArrayLength="16384"
                maxBytesPerRead="4096" maxNameTableCharCount="16384" />
                <reliableSession ordered="true" inactivityTimeout="00:30:00"
                enabled="false" />
                <security mode="Message">
                <transport clientCredentialType="Windows" proxyCredentialType="None"
                realm="" />
                <message clientCredentialType="Windows" negotiateServiceCredential="true"
                algorithmSuite="Default" establishSecurityContext="true" />
                </security>
                </binding>
                </wsHttpBinding>
                </bindings>
                
                <client>
                <!-- endpoint DNS name "datapower" 
                configured within local hosts file [8000] -->
                <endpoint name="EchoUser.DataPower"
                address="http://datapower:8000/EchoService"
                binding="wsFederationHttpBinding"
                bindingConfiguration="EchoUserWithoutTlsNego"
                contract="DataPower.CC.DCWebService.Common.EchoUser">
                <identity>
                <certificateReference storeName="TrustedPeople"
                storeLocation="CurrentUser"
                x509FindType="FindBySubjectName"
                findValue="datapower" />
                </identity>
                </endpoint>
                </client>

Paso 2. Configuración del dispositivo SOA

Las especificaciones de Conversación WS-Secure estipulan que hay tres maneras de establecer un contexto de seguridad entre dos partes. En este escenario, la confianza establecida entre el dispositivo SOA sigue el primero de estos patrones. El IdP de Microsoft ha emitido un token de autenticación, y WebSphere DataPower reconoce este IdP como una entidad de confianza. En consecuencia, el dispositivo actúa como un STS para un SP, y crea un token de seguridad para el intercambio entre el iniciador autenticado y la aplicación.

Antecedentes

MMC es la herramienta de Microsoft para administrar materiales clave, y puede usarse para exportar el material clave desde Microsoft. Una vez que todos los materiales clave son exportados desde Microsoft, deben importarse a WebSphere DataPower de manera tal que puedan usarse para descifrar y verificar los mensajes durante el tráfico RST/RSTR inicial entre el cliente Microsoft .Net y WebSphere DataPower.

Para establecer relaciones de confianza, WebSphere DataPower soporta la importación de certificados [o claves públicas] dentro del dispositivo con formato DER, PEM, PKCS#7 o PKCS#12. A fin de importar la clave primaria al dispositivo, el formato del archivo debe ser DER, PEM, PKCS#8 o PKCS#12. Microsoft exporta la clave en formato pfx y, para convertir el format pfx, se puede usar openssl. Por ejemplo, openssl pkcs12 –in cert.pfx –out cert.pem -nodes.

Para configurar una conversación segura sobre el dispositivo WebSphere DataPower de SOA para un servicio WSDL, se debe agregar una nueva operación para manipular la operación RequestSecurityToken. Este WSDL define un wsdl:operation para “RequestSecurityToken” con espacio de nombre soap12. El espacio de nombre debe coincidir con el espacio de nombre SOAP de wsdl:operation.


Nuevas características en WebSphere DataPower 3.7.3

También hay algunas características nuevas en la versión 3.7.3 que nos permiten configurar WebSphere DataPower para participar en este escenario.Nota: Soporte de Conversación Segura con WS-Security Policy en WebSphere DataPower.

  • Sólo se soporta el modo “enforce”
  • No se soporta la “renovación” del token
  1. Se han agregado dos campos al Proxy de servicios web para proporcionar un mayor soporte para EncryptedKeySHA1 KeyIdentifier y para preservar el material de clave descifrada.

WSProxy > Proxy Settings > “EncryptedKeySHA1 Cache Lifetime” y “Preserve EncryptedKey Chain”. La GUI se ilustra más abajo en laFigura 2.

Figura 2. 3.7.3 Actualizaciones de GUI
3.7.3 Actualizaciones de GUI

Caché de EncryptedKeySHA1:Duración de caché en segundos respecto de cuánto tiempo almacenar en caché el material “EncryptedKey” descifrado. Esto es necesario para generar una respuesta con Identificador de Clave EncyrptedKeySHA1, o descifrar el tráfico futuro que está protegido por el Identificador de Clave EncryptedKeySHA1.

Preservar la Cadena EncryptedKey:De manera predeterminada, DataPower quitará el material clave después del descifrado. El hecho de establecer esta opción como “activada” preservará el material clave para operaciones futuras [por ejemplo: cuando el mensaje de solicitud es firmado y cifrado por el mismo material clave, una vez que el mensaje es descifrado, el mismo material clave es necesario para verificar la firma del mensaje].

  1. Un nuevo parámetro de directivas.Una Acción de Transformación Adicional durante BootstrapPolicyse agrega para permitir la transformación personalizada durante el proceso de Bootstrap. Cualquier hoja de estilo especificada en este parámetro se ejecutará al final de las acciones STS RST, y antes de que se lleve a cabo cualquier acción para RSTR. Esto se ilustra en laFigura 2.
Figura 3. 3.7.3 Parámetro de directivas
3.7.3 Parámetro de directivas
  1. Un nuevo contexto misceláneo de transacciones varias se agrega a dp:aaa-set-context-info y a dp:aaa-get-context-info para almacenar asociaciones de información miscelánea con un contexto. Hay un límite de 512 bytes sobre el tamaño de los datos que puede contener este contexto.
  2. Cambio en el comportamiento sobre a qué se debería juntar la directiva wsdl:operation, Token RequestSecurity en 3.7.3.
  • Antes de 3.7.3, wsdl:operation name="RequestSecurityToken" usaba el enlace bootstrap, el que se encuentra asociado con sp:BootstrapPolicy en el elemento PolicyReference, como en el ejemplo siguiente:
                <wsdl:operation name="RequestSecurityToken">
                <wsp:PolicyReference URI="local:///policy.xml#bootstrap-binding" />
                <wsdl:input message="tns:RequestSecurityToken" />
                <wsdl:output message="tns:RequestSecurityTokenResponse" />
                </wsdl:operation>
  • Con 3.7.3.x, wsdl:operation name="RequestSecurityToken" debe usar un enlace de aplicación en el elemento PolicyReference, como ocurre en el ejemplo siguiente:
                <wsdl:operation name="RequestSecurityToken">
                <wsp:PolicyReference URI="local:///policy.xml#application-binding" />
                <wsdl:input message="tns:RequestSecurityToken" />
                <wsdl:output message="tns:RequestSecurityTokenResponse" />
                </wsdl:operation>
  • Antes de 3.7.3, la ubicación del elemento PolicyReference en el archivo WSDL era flexible. En 3.7.3, debe seguir inmediatamente el elemento de operación cuyo atributo de nombre es RequestSecurityToken, como ocurre en el ejemplo anterior.

En la versión 3.7.3 de WebSphere DataPower se incluye una nueva plantilla para manejar este caso de uso. La plantilla puede encontrarse en: store:///policies/templates/dotnet/wsp-sp-1-2-wsFederationHttpBinding.xml, y el proceso de configuración del servicio para usar este enlace se explica más abajo.


Configure el dispositivo SOA para controlar wsFederationHttpBinding

  1. Cargue los materiales clave exportados desde Microsoft al Panel de control de dispositivo SOA WebSphere DataPower > Keys and Certicates Management > [[Keys][Certificates][Crypto Profile > Identification Credentials][Crypto Profile > Credenciales de Validación] Keys : datapower[desde el material clave especificado en app.config -> "<client/> section"]Certificados: datapower[from the key material specified in app.config -> "<client/> section"]Credenciales de identificación: datapower[created with the key and certificate above][opcional] Credenciales de validación: sts[from the key material that the Identifier Provider used to sign the SAML 1.1]
  • En el caso del WS-Proxy, si el soap:Body del mensaje de entrada está cifrado, WSProxy descifrará automáticamente el soap:Body antes de que WSProxy haga el envío a la wsdl:operation apropiada. Hay dos maneras de especificar una clave para el descifrado:
    1. WSProxy > Proxy Settings > Decrypt Key
    2. Crear una “Credencial de Identificación” para relacionar la clave pública con la privada [éste es el método preferido, y usaremos este método para este caso de uso]
Figura 4. Lista de certificado de cifrado
Lista de certificado de cifrado
Figura 5. Lista de claves de cifrado
Lista de claves de cifrado
Figura 6. Credenciales de identificación
Credenciales de identificación
Figura 7. Credenciales de validación
Credenciales de validación
  1. Recupere el WSDL desde el servidor de aplicación. En este caso, con http://<server>:<port>?wsdl.
  2. Modifique el WSDL directamente para adjuntar la directiva del mensaje de entrada y de salida al wsdl:Input y al wsdl:Output.
                <wsdl:binding name="EchoUser" type="i0:EchoUser">
                <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
                <wsdl:operation name="getCurrentUser">
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy”/>  
                <soap12:operation soapAction=
                "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT" 
                style="document"/>
                <wsdl:input name="getCurrentUserRequest">
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#InputPolicy"/> 
                <soap12:body use="literal"/>
                </wsdl:input>
                <wsdl:output name="getCurrentUserResponse">
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#OutputPolicy"/> 
                <soap12:body use="literal"/>
                </wsdl:output>
                </wsdl:operation>
                </wsdl:binding>
  1. Cree un WSProxy con el WSDL del paso 3.
  • Cree un Conjunto de Parámetros de WS-Policy, secpol-param
    - wsFederationHttpBinding de Microsoft usa WS-Security Policy 1.1,http://schemas.xmlsoap.org/ws/2005/07/securitypolicy, mientras que ws2007FederationHttpBinding usahttp://docs.oasis-open.org/ws-sz-ws-securitypolicy/200702. La nomenclatura implica que el espacio de nombres de la directiva de seguridad es versión 1.2; sin embargo, está usando espacios de nombres de la versión 1.1 y tiene impacto sobre cómo el Parámetro de la Directiva de Seguridad está asociado con la Directiva de WS-Security. Por consiguiente, los dos juegos de Parámetros de Directivas están definidos para los dos espacios de nombres siguientes: Directiva de Seguridad 1.1 y Directiva de Seguridad 1.2.
    - Tres parámetros están establecidos, “Interoperable with”, “WS-SecureConversation Version” y “Verificación Valcred”.
  • Seleccione “Enforce” como “WS-Policy Enforcement Mode”
  • Haga clic en “Siguiente”
Figura 8. Parámetros de la Directiva
Parámetros de la Directiva
Figura 9. WSDL del Proxy de servicio web
WSDL del Proxy de servicio web
  1. Agregue “Controlador Anterior de HTTP”
    - Nombre: http8000
    - Número de puerto: 8000
Figura 10. Controlador Anterior de HTTP
Controlador Anterior de HTTP
Figura 11. Configuración del Controlador Anterior de HTTP
Configuración del Controlador Anterior de HTTP
Figura 12. Ubicación de la fuente de WSDL
Ubicación de la fuente de WSDL
  1. Especifique la dirección IP del servidor remoto, el puerto y el identificador URI del servicio de aplicación. Para este ejemplo, la dirección IP del host es 9.33.82.25, 8000 es el puerto y /EchoService el identificador URI.
  2. Agregue el WSDL, ws-wssecconv.wsdl, para controlar el RequestSecurityToken de STS
    - Asegúrese de que la directiva de seguridad correcta se adjunte al Policy Subject adecuado en ws-wssecconv.wsdl
                . . . . . . 
                <wsdl:portType name="Test">
                <wsdl:operation name="RequestSecurityToken">
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy"/> 
                <wsdl:input message="tns:RequestSecurityToken"/>
                <wsdl:output message="tns:RequestSecurityTokenResponse"/>
                </wsdl:operation>
                </wsdl:portType>
                . . . . . .
                <wsdl:input>
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#InputPolicy"/> 
                <soap12:body use="literal"/>
                </wsdl:input>
                <wsdl:output>
                <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#OutputPolicy"/> 
                <soap12:body use="literal"/>
                </wsdl:output>
  • Use el mismo “Controlador del Punto Final Local” que en el Paso 5.
  • Use el mismo “Identificador URI” que en el Paso 5.
  1. Habilite WSProxy para soportar “EncryptedKeySHA1” y preserve el material clave editando la configuración en “Proxy Settings”
    - Duración de caché de EncryptedKeySHA1: 100 [cualquier valor > 0 segundos]
    Preservar Cadena EncryptedKey: activado [para preservar el material clave necesario para verificar la firma dentro del mensaje]
Figura 13. Configuración de Proxy de servicio web
Configuración de Proxy de servicio web
  1. [opcional] Adjuntar la directiva a la operación de aplicación. En este ejemplo, adjuntamos la directiva directamente al WSDL. Otra opción es utilizar WebGUI para adjuntar la directiva
    - Seleccione “Sí” sobre “Show portType and binding nodes:” (Mostrar portType y nodos de enlace)”
Figura 14. Mostrar portType y nodos de enlace
Mostrar portType y nodos de enlace

- Seleccione “WS-Policy” de portType para adjuntar la directiva a ese Policy Subject determinado

- Adjunte store:///policies/templates/dotnet/wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy

Figura 15. Fuente de Directivas Adicionales
Fuente de Directivas Adicionales
  1. La respuesta de salida está firmada y cifrada. Una vez que el mensaje está cifrado, fallará el esquema de validación si se habilita la misma.
  2. STS > RequestSecurityToken
    - Desactive la opción “Schema validate request messages” y “Schema validate response messages”
  3. Application > EchoServices
    - Desactive la opción “Schema validate response messages”
Figura 16. Desactive la opción “Schema validate response messages”
Desactive la opción “Schema validate response messages”
  1. Agregue dos reglas de usuario, solicitud y respuesta, a EchoUserServiceWCF.wsdl para controlar WS-Addressing a través de “Add Rule”.
  • Solicitud [Cliente > Servidor]: agrega una transformación para getMessage.xsl; ver adjunto.
    - Esto permitirá guardar la información wsa:xxxx adicional en una variable de contexto
    - Dirección: de Cliente a Servidor
    - Entrada: INPUT
    - Salida: NULL
  • Respuesta [Servidor > Cliente]: agrega una transformación para setMessage,xsl; ver adjunto.
    - Esto creará un elemento <soap:Header/> con la información de WS-Addressing necesaria del Paso 10 anteriormente citado
    - Dirección: de Servidor a Cliente
    - Entrada: INPUT
    - Salida: PIPE

    ** setMessage.xsl supone que la respuesta desde el servidor no contiene un soap:Header. Por lo tanto, agregará un soap:Header con la información necesaria. Sin embargo, si el back-end envía una respuesta que contiene un soap:Header, se deberá usar en su lugar setMessageIdWithoutAddingSoapHeader.xsl.
Figura 17. Acción: Transformación
Acción: Transformación
  1. Haga clic en “Apply” para aplicar todos los cambios y guardar la configuración para el WSProxy.

Verificación de la conexión

En este punto, usted debería modificar el cliente Microsoft .Net WCF 3.5 para acceder al dispositivo de SOA WebSphere DataPower.

Figura 18. Conversación segura establecida
Conversación segura establecida

Ha establecido con éxito una conversación segura con Microsoft WCF 3.5 usando wsFederationHttpBinding.

Para asegurar que el intercambio con el dispositivo WebSphere DataPower de SOA sea correcto, encienda la sonda y monitoree el tráfico. Si la sonda está encendida, usted observará tres conjuntos de tráficos de red. El siguiente es un ejemplo de esto:

Tran # 41121:STS RequestSecurityToken. Éste ha establecido el SecurityContextToken. Observe la URL de salida, el dispositivo actúa como un STS y ha emitido el Token de Conversación Segura para el tráfico de aplicación, razón por la cual el tráfico no tiene una URL de salida válida.

Tran # 41409:Tráfico de la Aplicación. Algo que se debe tener en cuenta sobre el tráfico de aplicación de la respuesta: la primera ronda de verificación es para soap:Fault y, si todo marcha bien, usted advertirá una falla en esa verificación, seguida de otro(s) conjunto(s) de tráfico de la aplicación. Éste es el comportamiento esperado. * soap:Fault puede tener su propia Directiva de Seguridad adjunta a él y no seguir la Directiva de Seguridad adjunta al tráfico de la aplicación, razón por la cual, si la aplicación funciona exitosamente sin devolver un soap:Fault, usted advertirá una falla como primera verificación.

Tran # 45170:Operación de cancelación del RequestSecurityToken de STS: ésta cierra la sesión de conversación segura. Observe la URL de salida; el dispositivo actúa como STS para cancelar el Token de Conversación Segura que emitió en Tran #41121 y, por lo tanto, el tráfico no tiene una URL de salida válida.

Figura 19. Lista de transacciones para EchoService
Lista de transacciones para EchoService

Otras consideraciones

Con wsFederationHttpBinding de Microsoft, el RST/RSTR inicial contiene un token de identidad, el token SAML1.1 en este caso. Este token SAML se usa para el intercambio inicial, y no será enviado en el tráfico de aplicación subsiguiente. El siguiente es un ejemplo que ilustra cómo es posible preservar esta información para el tráfico futuro. El mismo cumple sólo fines de demostración.

Dado que SAML 1.1 sólo se envía una vez, debe preservarse para la transacción futura de la aplicación. Por ello, se agrega un nuevo parámetro de directiva de seguridad, Acción de Transformación Adicional, durante BootstrapPolicy. Con este parámetro, puede ejecutarse una hoja de estilo una vez que se ha procesado el RST, pero antes de que el Dispositivo DataPower de SOA genere un RSTR. Esta hoja de estilo mantendrá la información de esta información SAML1.1 en un caché para tráfico futuro.

Figura 20. Acción de transformación adicional durante BootstrapPolicy
Acción de transformación adicional durante BootstrapPolicy

Tres hojas de estilo se incluyen en este artículo para dar un ejemplo sobre cómo usar ‘Acción de Transformación Adicional durante BootstrapPolicy’ en conjunto con ‘dp:aaa-set-context-info’. De manera conjunta, éstas asociarán el token SAML con una transacción de conversación segura determinada.

  1. Cree los parámetros de directivas anteriormente citados para el tráfico RST/RSTR de Bootstrap [ver StoreSAMLFromRST.xsl]
    - La hoja de estilo guarda un subconjunto de información SAML en una variable de contexto
  2. En la regla de usuario del RST/RSTR de Bootstrap, llame a dp:aaa-set-context-info para asociar la información SAML con el contexto de Conversación Segura. Por favor, observe que la información miscelánea se limita a una longitud de 512 bytes [ver AddSAMLToSecureContext.xsl]
    - Asegúrese de que la entrada de esta transformación sea INPUT
    - Asegúrese de que la salida de esta transformación sea NULL
    - La Acción de Resultado que sigue esta transformación debería tener ‘INPUT’ como entrada
  3. Sobre el tráfico de solicitud de la regla del usuario sobre el tráfico de la aplicación:
    - Use una acción de transformación con dp:aaa-get-context-info para acceder a la información SAML almacenada en 1 [ver GetSAMLFromRST.xsl]
    - Asegúrese de que la entrada de esta transformación sea INPUT
    - Asegúrese de que la salida de esta transformación sea NULL
    - La Acción de Resultado que sigue esta transformación debe establecerse de manera conveniente; lo más probable es que sea INPUT

Descargar

DescripciónNombretamaño
Stylesheet examplesstylesheets.zip10KB

Recursos

Comentarios

developerWorks: Ingrese

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


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


¿Olvidó su Password?
Cambie su Password

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

 


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

Toda la información enviada es segura.

Elija su nombre para mostrar



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

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

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

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

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

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=428582
ArticleTitle=Descargue tareas de seguridad de servicios web WebSphere a IBM WebSphere DataPower de SOA Appliance: Parte 4: ¿Está listo para una conversación segura?
publish-date=08032011