Diferencias de comportamiento de WS-Security entre tradicional y Liberty

Las restricciones de WS-Security que se pueden añadir a una aplicación de servicio web en Liberty se pueden comportan de forma diferente con respecto a las mismas restricciones que se aplican a un servicio en la versión tradicional.

Configuración y habilitación de WS-Security

WS-Security en Liberty se configura utilizando WS-SecurityPolicy dentro del archivo WSDL de una aplicación de servicio web y se habilita añadiendo la característica wsSecurity-1.1 en el archivo server.xml. WS-Security en tradicional se configura utilizando un conjunto de políticas y se habilita adjuntando un conjunto de políticas. Si despliega una aplicación de servicio web Liberty con WS-Security habilitado en una versión tradicional, debe crear y adjuntar un conjunto de políticas y enlaces equivalentes para obtener el mismo nivel de seguridad de servicio web.

Política WS-Security

  • Espacios de nombres
    • Liberty CXF WS-Security soporta los espacios de nombres de política WS-Security siguientes:
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802
    • Se admite también el espacio de nombres siguiente, con limitaciones:
      http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
    • WS-Security de tradicional soporta los siguientes espacios de nombres de WS-Security Policy:
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
  • Aserciones
    Liberty soporta más aserciones en WS-Security Policy 1.2 que en la versión tradicional. Algunas aserciones de política en WS-Security tradicional se implementan mediante XPath o enlaces. La lista siguiente muestra algunas diferencias importantes:
    • Señales de soporte

      Para firmar o cifrar un elemento SupportingToken, como UsernameToken en Liberty, certifique la señal como SignedSupportingTokens, SignedEncryptedSupportingTokens o EncryptedSupportingTokens. En la versión tradicional, debe utilizar una expresión XPath para firmar o cifrar una SupportingToken.

      En la versión tradicional no se soportan todas las señales de validación, incluyendo EndorsingSupportingTokens, SignedEndorsingSupportingTokens, EndorsingEncryptedSupportingTokens y SignedEndorsingEncryptedSupportingTokens.

    • Aserción de enlace de seguridad

      Liberty soporta las aserciones SymmetricBinding, AsymmetricBinding y TransportBinding. El servidor tradicional no soporta la aserción TransportBinding.

    • Aserción IncludeToken

      La aserción IncludeToken se impone en Liberty, pero se ignora en el entorno de ejecución de WS-Security de la versión tradicional.

    • Aserción UsernameToken

      Liberty soporta PasswordDigest y la derivación de claves en la aserción UsernameToken. WebSphere Application Server tradicional solo soporta PasswordText en un UsernameToken.

Elementos no reconocidos en la cabeceras Security

  • La versión tradicional rechaza un elemento no reconocido en la cabecera de seguridad, mientras que Liberty lo acepta.

Cabecera cifrada

  • La especificación WS-Security 1.1 recomienda utilizar el elemento <wsse11:EncryptedHeader> para cifrar bloques SOAP de cabecera.
    • CXF WS-Security que se utiliza en Liberty no garantiza un elemento EncryptedHeader. En su lugar, CXF WS-Security genera un elemento <xenc:EncryptedData>. Sin embargo, CXF WS-Security que se utiliza en Liberty puede procesar y consumir un elemento <wsse11:EncryptedHeader> de entrada, si mustUnderstand en la cabecera <security> está establecido en 0.
    • WebSphere Application Server tradicional siempre establece mustUnderstand en 1 en la cabecera <security>. Para que Liberty pueda procesar el elemento EncryptedHeader correctamente, debe establecer explícitamente mustUnderstand en 0 estableciendo la propiedad siguiente en la configuración de enlaces de salida.
      <properties name="com.ibm.wsspi.wssecurity.config.request.setMustUnderstand" value="false"/>

Certificados intermedios no de confianza

  • No hay modo de especificar certificados intermedios no de confianza para permitir que un validador de vías de acceso de certificado cree una vía de acceso de certificado desde un certificado de entrada a un certificado de confianza en un almacén de confianza. El certificado de entrada o su emisor inmediato deben estar en el almacén de confianza para que el certificado sea de confianza.

Problemas conocidos

Características no probadas y no admitidas

  • Liberty WS-Security incluye todo el código de entorno de tiempo de ejecución de WS-Security del proyecto CXF. Sin embargo, no todas las funciones y características de la WS-Security CXF se han probado o verificado. Para ver una lista de las especificaciones que no se han verificado, consulte Especificaciones de WS-Security no probadas.

Icono que indica el tipo de tema Tema de concepto

Nombre de archivo: cwlp_wssec_cxf_diff.html