Problèmes connus liés à la sécurité de services Web et solutions palliatives
Les points ci-dessous sont des problèmes liés à l'implémentation de la sécurité de services Web dans l'infrastructure de services à code source ouvert Apache CXF.
- Si votre SupportingToken est chiffré lorsque vous ne souhaitiez rien chiffrer, essayez de supprimer les assertions de jeton liées au chiffrement pour résoudre le problème. S'il n'existe pas d'élément EncryptedParts et EncryptedElements dans l'élément AsymmetricBinding avec une assertion SupportingToken, le jeton SupportingToken est chiffré de manière inattendue.
- La signature XML avec transformation de signature enveloppée ne fonctionne pas. Il n'existe pas de solution palliative.
- Bien que l'élément PolicyReference dans <wsdl:output> soit honoré, l'élément PolicyReference dans <wsdl:input> est ignoré. Si vous devez distinguer PolicyReference dans l'entrée et la sortie, la solution palliative consiste à joindre PolicyReference au niveau de la liaison, puis à remplacer l'élément PolicyReference dans <wsdl:output>.
- L'assertion de règle sp:requireEmbeddedTokenReference n'est pas prise en charge.
- Lorsque les propriétés org.apache.ws.security.crypto.merlin.truststore.* existent dans l'élément signatureProperties et que les propriétés org.apache.ws.security.crypto.merlin.keystore.* existent dans l'élément encrytpionProperties de la section wsSecurityProvider ou wsSecurityClient du fichier server.xml, les valeurs org.apache.ws.security.crypto.merlin.keystore.* dans l'élément encrytpionProperties remplacent les propriétés org.apache.ws.security.crypto.merlin.truststore.* dans l'élément signatureProperties. Ce comportement signifie que votre fichier de clés de chiffrement est utilisé comme fichier de clés certifiées de signature. La solution palliative consiste à utiliser le même fichier de clés pour les fichiers de clés certifiés de chiffrement et de signature au lieu d'utiliser des fichiers de clés distincts.
- Les types de jeton X509PKIPathv1 et PKCS#7 ne sont pas pris en charge.
- Dans la règle de sécurité de services Web, les assertions Require* qui se trouvent dans l'assertion X509Token ne sont utilisées que lors de la génération d'un jeton X509. Elles ne sont pas appliquées lors de la consommation d'un jeton X509. Ces assertions incluent entre autres RequireKeyIdentifierReference, RequireIssuerSerialReference et RequireThumbprintReference.
- Dans l'assertion SymmetricBinding, les assertions SignatureToken et EncryptionToken ne peuvent pas être spécifiées. La seule assertion prise en charge qui peut être utilisée dans une assertion SymmetricBinding est ProtectionToken. L'assertion ProtectionToken spécifiée est utilisée pour la signature et pour le chiffrement.
- L'assertion ProtectTokens de la règle de sécurité de services Web n'est pas prise en charge et est ignorée.
- L'assertion KeyValueToken de la règle de sécurité de services Web n'est pas prise en charge.
- L'assertion X509Token dans EndorsingEncryptedSupportingTokens ou SignedEndorsingEncryptedSupportingTokens n'est pas prise en charge.
- La sécurité de services Web dans Liberty prend en charge la spécification de version 1.1 qui est compatible avec la spécification de version 1.0. Cela signifie que les URI et les éléments de schéma qui sont définis dans la version 1.0 ne sont pas changés, alors que de nouveaux éléments de schéma et de nouvelles constantes sont définis avec les espaces de nom et les URI de la version 1.1.
Les options et les propriétés de sécurité de services Web dans la règle de sécurité de services Web sont définies avec l'assertion wss10 ou wss11. Si vous devez configurer une règle pour la prise en charge des propriétés de la version 1.1 de la sécurité de services Web, vous ne devez configurer que l'assertion de règle wss11 qui inclut déjà l'assertion wss10 ; ne configurez pas les deux assertions de règle simultanément (wss11 et wss10).
Exemples d'assertions de règle wss11 contenant l'assertion wss10 incluant entre autres RequireSignatureConfirmation, MustSupportRefKeyIdentifier et MustSupportRefIssuerSerial.
- La sécurité de services Web et MTOM ne peuvent pas être configurés simultanément pour le même service à ce stade. Si MTOM est utilisé et que la sécurité de services Web est également configurée, le message SOAP n'est pas envoyé correctement. L'utilisateur doit choisir d'utiliser MTOM ou de configurer la sécurité de services Web. Si MTOM est requis, vous devez supprimer la règle de sécurité de services Web du fichier WSDL afin de désactiver la sécurité de services Web.
- Si vous utilisez un client Liberty et un fournisseur WebSphere Application Server traditional et recevez du fournisseur une réponse CWWSS6001E: Key object was not obtained., le problème peut avoir été résolu par l'APAR PM88011 pour WebSphere Application Server traditional. Ce problème est spécifiquement associé aux configurations incluant le chiffrement et la signature numérique asymétrique du corps.