Comment deviner l'ordre des articles dans le rempart ayant une réponse WS-Security?

Question

Mon client rampart axis2 + a travaillé avec un serveur WS-Secured. Il a cessé de fonctionner après la mise à niveau du serveur (mise à niveau de JBoss, changements dans WSDL, mais pas dans la fonction de test). Les propriétaires de serveur affirment que leur configuration WS-Security n'a pas été modifié, mais maintenant mes rapports clients:

org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security 

Plus tôt je suis arrivé cette exception lorsque l'ordre des « articles » dans axis2.xml n'a pas été bonne. Tout ce que je devais faire était de combiner ces éléments. Ils ressemblent à:

<parameter name="InflowSecurity"> 
    <action> 
    <items>Signature Encrypt Timestamp</items> 
... 

Maintenant, ce problème a réapparu. Je vois que, en réponse, il n'y a pas de 'Timestamp'. J'ai enlevé cela des articles mais rien n'a changé.

Répondre ressemble:

<soap:Envelope xmlns:soap="..." 
    xmlns:xenc="..."> 
    <soap:Header> 
     <wsse:Security 
      xmlns:wsse="..." 
      soap:mustUnderstand="1"> 
      <xenc:EncryptedKey xmlns:xenc="..." 
       Id="EncKeyId-B8B3555394366F3F0112919826983351032"> 
       <xenc:EncryptionMethod Algorithm="..." /> 
       <ds:KeyInfo xmlns:ds="..."> 
        <wsse:SecurityTokenReference 
         xmlns:wsse="..."> 
         <wsse:KeyIdentifier 
          ... 
         </wsse:KeyIdentifier> 
        </wsse:SecurityTokenReference> 
       </ds:KeyInfo> 
       <xenc:CipherData> 
        <xenc:CipherValue> 
         ... 
        </xenc:CipherValue> 
       </xenc:CipherData> 
       <xenc:ReferenceList> 
        <xenc:DataReference URI="#EncDataId-624" /> 
       </xenc:ReferenceList> 
      </xenc:EncryptedKey> 
      <ds:Signature xmlns:ds="..." 
       Id="Signature-622"> 
       <ds:SignedInfo> 
        <ds:CanonicalizationMethod 
         Algorithm="..." /> 
        <ds:SignatureMethod Algorithm="..." /> 
        <ds:Reference URI="#id-623"> 
         <ds:Transforms> 
          <ds:Transform Algorithm="..." /> 
         </ds:Transforms> 
         <ds:DigestMethod Algorithm="..." /> 
         <ds:DigestValue> 
          ... 
         </ds:DigestValue> 
        </ds:Reference> 
       </ds:SignedInfo> 
       <ds:SignatureValue> 
        ... 
       </ds:SignatureValue> 
       <ds:KeyInfo Id="KeyId-B8B3555394366F3F0112919826983181029"> 
        <wsse:SecurityTokenReference 
         xmlns:wsse="..." 
         xmlns:wsu="..." 
         wsu:Id="STRId-B8B3555394366F3F0112919826983181030"> 
         <wsse:KeyIdentifier 
          EncodingType="..." 
          ValueType="..."> 
          ... 
         </wsse:KeyIdentifier> 
        </wsse:SecurityTokenReference> 
       </ds:KeyInfo> 
      </ds:Signature> 
     </wsse:Security> 
    </soap:Header> 
    <soap:Body xmlns:ns1="..." 
     xmlns:wsu="..." 
     wsu:Id="id-623"> 
     <xenc:EncryptedData xmlns:xenc="..." 
      Id="EncDataId-624" Type="..."> 
      <xenc:EncryptionMethod Algorithm="..." /> 
      <ds:KeyInfo xmlns:ds="..."> 
       <wsse:SecurityTokenReference 
        xmlns:wsse="..."> 
        <wsse:Reference 
         xmlns:wsse="..." 
         URI="#EncKeyId-B8B3555394366F3F0112919826983351032" /> 
       </wsse:SecurityTokenReference> 
      </ds:KeyInfo> 
      <xenc:CipherData> 
       <xenc:CipherValue> 
        ... 
       </xenc:CipherValue> 
      </xenc:CipherData> 
     </xenc:EncryptedData> 
    </soap:Body> 
</soap:Envelope> 

Mes questions:

1. Comment puis-je savoir quelle partie de la sécurité vraiment échoué? Est-ce un mauvais ordre, un manque d'élément, un élément supplémentaire ou une erreur similaire?
2. Comment puis-je deviner quels éléments devrais-je ajouter à la configuration d'InflowSecurity de rampart si tout ce que j'avais était signé et crypté? Est-il possible de savoir quel ordre d'articles devrais-je utiliser?

Answer 1

C'est une question assez ancienne, mais comme je viens de terminer mon voyage à travers cette terre de douleur, je vais partager les réponses.

a) L'ordre des éléments est appliqué par la bibliothèque wss4j sous-jacente, et non par le rempart. La méthode problématique est checkReceiverResults() de org.apache.ws.security.handler.WSHandler. Vous avez probablement rencontré des problèmes en utilisant WSDAllReceiver de rempart qui étend WSHandler. B) La bonne nouvelle est que la méthode checkReceiverResults() est protégée. Vous pouvez donc étendre WSDoAllReceiver et remplacer la méthode pour la rendre plus permissive. Je suggère de regarder l'implémentation de checkReceiverResultsAnyOrder() ajoutée à WSHandler dans wss4j-1.5.8.

Donc, pour répondre à vos questions:

Vous pouvez déboguer méthode checkReceiverResults() pour savoir et l'ordre des éléments « fixer » dans votre fichier axis2.xml. Mais ce n'est pas une bonne solution, car l'ordre des en-têtes peut toujours changer (il n'y a pas d'exigence pour l'ordre des éléments dans l'entête SOAP). Donc, ma suggestion appelle checkReceiverResultsAnyOrder() plutôt que checkReceiverResults().