Problemas conocidos de WS-Security y soluciones temporales
Los elementos siguientes son problemas con la implementación de WS-Security en la infraestructura de servicios de código abierto de Apache CXF.
- Si SupportingToken se cifra cuando no deseaba realizar ningún cifrado, elimine las aserciones de señal relacionadas con el cifrado para solucionar el problema. Si no hay EncryptedParts ni EncryptedElements en AsymmetricBinding con una aserción SupportingToken, SupportingToken se cifra de forma inesperada.
- No funciona la firma XML con la transformación de enveloped signature. No hay ninguna solución temporal.
- Aunque se respeta PolicyReference en <wsdl:output>, se pasa por alto PolicyReference en <wsdl:input>. Si debe distinguir PolicyReference entre entrada y salida, la solución temporal es conectar PolicyReference a nivel de enlace y luego alterar temporalmente PolicyReference en <wsdl:output>.
- No se admite la política de aserción sp:requireEmbeddedTokenReference.
- Cuando existen las propiedades org.apache.ws.security.crypto.merlin.truststore.* en el elemento signatureProperties y existen las propiedades org.apache.ws.security.crypto.merlin.keystore.* en el elemento encrytpionProperties de la sección wsSecurityProvider o wsSecurityClient del archivo server.xml, los valores org.apache.ws.security.crypto.merlin.keystore.* del elemento encrytpionProperties alteran temporalmente las propiedades org.apache.ws.security.crypto.merlin.truststore.* del elemento signatureProperties. Este comportamiento significa que se utiliza el almacén de claves de cifrado para el almacén de confianza de firmas. La solución temporal es utilizar el mismo almacén de claves para los almacenes de confianza de cifrado y de firmas; no se pueden utilizar almacenes de claves independientes.
- No se admiten los tipos de señales X509PKIPathv1 y PKCS#7.
- En la política WS-Security, las aserciones Require* dentro de la aserción X509Token solo se utilizan al generar señales X509. No se imponen al consumir una señal X509. Estas aserciones incluyen, pero no se limitan a, RequireKeyIdentifierReference, RequireIssuerSerialReference y RequireThumbprintReference.
- En la aserción SymmetricBinding, no se pueden especificar las aserciones SignatureToken ni EncryptionToken. La única aserción admitida que se puede utilizar dentro de una aserción SymmetricBinding es la aserción ProtectionToken. El ProtectionToken especificado se utiliza para firma y cifrado.
- No se admite la aserción ProtectTokens de la política WS-Security y se pasa por alto.
- No se admite la aserción KeyValueToken de la política WS-Security.
- No se admite X509Token en EndorsingEncryptedSupportingTokens o SignedEndorsingEncryptedSupportingTokens.
- WS-Security en Liberty admite la especificación de la versión 1.1, que es compatible con una versión anterior con la especificación de la versión 1.0. Esto significa que los URI y los elementos de esquema definidos en 1.0 permanecen
sin cambiar, mientras que los nuevos elementos de esquema y las constantes se definen
con los espacios de nombres 1.1 y los URI.
Las propiedades y las opciones de WS-Security de la política WS-Security se definen cono la aserción wss10 o con la aserción wss11. Si debe configurar una política para admitir las propiedades de WS-Security 1.1, debe configurar solo la aserción de política wss11 que ya incluye la aserción wss10 y no debe configurar las aserciones de política wss11 y wss10.
Ejemplos de aserciones de política wss11 que contienen la aserción wss10 incluyen, pero no se limitan a, RequireSignatureConfirmation, MustSupportRefKeyIdentifier y MustSupportRefIssuerSerial.
- WS-Security y MTOM no se pueden configurar juntos para el mismo servicio en este momento. Cuando se utiliza MTOM y se configura también WS-Security, no se envía correctamente el mensaje SOAP. El usuario debe determinar si va a utilizar MTOM o va a configurar WS-Security. Si se requiere MTOM, debe eliminar la política WS-Security del archivo WSDL para inhabilitar WS-Security.
- Si está utilizando un cliente de Liberty y un proveedor de WebSphere Application Server tradicional y recibe una respuesta CWWSS6001E: objeto clave no obtenido. del proveedor, el problema se podría resolver con el APAR PM88011 del WebSphere Application Server tradicional. Este problema se refiere específicamente a las configuraciones que incluyen firma digital asimétrica y cifrado del cuerpo.