Différences de comportement de la sécurité de services Web entre Traditional et Liberty

Des contraintes de sécurité de services Web pouvant être ajoutées à une application de service Web dans Liberty peuvent se comporter de manière différente lorsqu'elles sont appliquées à un service dans Traditional.

Configuration et activation de la sécurité de services Web

Dans Liberty, la sécurité de services Web est configurée avec la règle de sécurité de services Web dans le fichier WSDL d'une application de service Web, et est activée via l'ajout de la fonction wsSecurity-1.1 dans le fichier server.xml. Dans Traditional, elle est configurée avec un ensemble de règles et activée via l'association d'un ensemble de règles. Si vous déployez une application de service Web Liberty pour laquelle la sécurité de services Web est activée dans Traditional, vous devez créer et associer un ensemble de règles équivalent ainsi que des liaisons afin d'obtenir le même niveau de sécurité de services Web.

Règle de sécurité de services Web

  • Espaces de nom
    • La sécurité de services Web CFX Liberty prend en charge les espaces de nom de règle de sécurité de services Web suivants :
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802
    • L'espace de nom suivant est également pris en charge, avec des restrictions :
      http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
    • La sécurité de services Web de Traditional prend en charge les espaces de nom de règle de sécurité de services Web suivants :
      http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
  • Assertions
    Liberty prend en charge un nombre d'assertions plus élevé dans WS-Security Policy 1.2 que Traditional. Certaines assertions de règle dans la sécurité de services Web de Traditional sont implémentées via une expression XPath ou des liaisons. La liste suivante répertorie certaines différences essentielles :
    • Prise en charge des jetons

      Pour signer ou chiffrer une assertion SupportingToken telle que UsernameToken dans Liberty, vous confirmez que le jeton est un jeton SignedSupportingTokens, SignedEncryptedSupportingTokens ou EncryptedSupportingTokens. Dans Traditional, vous devez utiliser une expression XPath pour signer ou chiffrer une assertion SupportingToken.

      Tous les jetons de validation ne sont pas pris en charge dans Traditional, notamment EndorsingSupportingTokens, SignedEndorsingSupportingTokens, EndorsingEncryptedSupportingTokens et SignedEndorsingEncryptedSupportingTokens.

    • Assertion de liaison de sécurité

      Liberty prend en charge les assertions SymmetricBinding, AsymmetricBinding et TransportBinding. Le serveur Traditional ne prend pas en charge l'assertion TransportBinding.

    • Assertion IncludeToken

      L'assertion IncludeToken est appliquée dans Liberty, mais est ignorée dans l'environnement d'exécution de sécurité de services Web de Traditional.

    • Assertion UsernameToken

      Liberty prennent en charge PasswordDigest et la dérivation de clé dans l'assertion UsernameToken. WebSphere Application Server traditional ne prend en charge que PasswordText dans une assertion UsernameToken.

Eléments non reconnus dans les en-têtes de sécurité

  • Un élément non reconnu dans un en-tête de sécurité est rejeté par Traditional alors qu'il est accepté par Liberty.

En-tête chiffré

  • La spécification WS-Security 1.1 recommande l'utilisation de l'élément <wsse11:EncryptedHeader> pour le chiffrage des blocs d'en-tête SOAP.
    • La sécurité de services Web CXF utilisée dans Liberty ne génère pas d'élément EncryptedHeader. A la place, CXF WS-Security génère un élément <xenc:EncryptedData>. Toutefois, la sécurité de services Web CXF utilisée dans Liberty peut traiter et consommer un élément <wsse11:EncryptedHeader> entrant si mustUnderstand dans l'en-tête <security> reçoit la valeur 0.
    • WebSphere Application Server traditional attribue toujours à mustUnderstand la valeur 1 dans l'en-tête <security>. Pour que Liberty traite l'élément EncryptedHeader correctement, vous devez associer explicitement l'élément mustUnderstand à la valeur 0 en définissant la propriété suivante dans la configuration des liaisons sortantes :
      <properties name="com.ibm.wsspi.wssecurity.config.request.setMustUnderstand" value="false"/>

Certificats non sécurisés intermédiaires

  • Il n'est pas possible de spécifier des certificats non sécurisés intermédiaires pour permettre au valideur de chemin de certificat de générer un chemin de certificat à partir d'un certificat entrant vers un certificat sécurisé dans un fichier de clés certifiées. Le certificat entrant ou son émetteur immédiat doit se trouver dans le fichier de clés certifiées pour que le certificat soit considéré comme sécurisé.

Problèmes connus

Fonctions non testées et non prises en charge

  • La sécurité de services Web de Liberty inclut l'intégralité du code de l'environnement d'exécution de la sécurité de services Web du projet CXF. Toutefois, les fonctionnalités et les fonctions de la sécurité de services Web CXF n'ont pas toutes été testées ou vérifiées. Pour prendre connaissance de la liste des spécifications qui n'ont pas été vérifiées, voir Spécifications de sécurité de services Web non testées.

Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_wssec_cxf_diff.html