2017-07-28 4 views
0

Je me demandais comment une partie de cette politique devrait être interprétée. Tout d'abord, cette partie de la politique est-elle valide? Que se passe-t-il si j'envoie un token10, cela fonctionnera-t-il? avec un token11?Comment gérer deux assertions en même temps

Je demande cela parce que si j'utilise la politique avec apache cxf 2.7.x ou 3.x je reçois "exception de politique invalide" MAIS si j'utilise cxf 2.x.xxx.redhat-1 Il semble être travailler, mon doute est que c'est normal, ou que les bibliothèques à chapeau rouge vont à l'encontre de la norme.

<wsp:Policy xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" wsu:Id="SecurityServiceSignThenEncryptPolicy"> 
<wsp:ExactlyOne> 
    <wsp:All> 
     <sp:AsymmetricBinding> 
      <wsp:Policy> 
       <sp:InitiatorToken> 
        <wsp:Policy> 
         <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> 
          <wsp:Policy> 
           <sp:WssX509V3Token10/> 
           <sp:WssX509V3Token11/> 
          </wsp:Policy> 
         </sp:X509Token> 
        </wsp:Policy> 
       </sp:InitiatorToken> 
       <sp:RecipientToken> 
        <wsp:Policy> 
         <sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always"> 
          <wsp:Policy> 
           <sp:WssX509V3Token10/> 
           <sp:WssX509V3Token11/> 
          </wsp:Policy> 
         </sp:X509Token> 
        </wsp:Policy> 
       </sp:RecipientToken> 
       <sp:AlgorithmSuite> 
        <wsp:Policy> 
         <sp:Basic128Rsa15/> 
         <sp:Basic256Rsa15/> 
         <sp:Basic128Sha256Rsa15/> 
         <sp:Basic256Sha256Rsa15/> 
        </wsp:Policy> 
       </sp:AlgorithmSuite> 
       <sp:Layout> 
        <wsp:Policy> 
         <sp:Lax/> 
        </wsp:Policy> 
       </sp:Layout> 
       <sp:IncludeTimestamp/> 
       <sp:ProtectTokens/> 
       <sp:OnlySignEntireHeadersAndBody/> 
      </wsp:Policy> 
     </sp:AsymmetricBinding> 
     <sp:Wss10> 
      <wsp:Policy> 
       <sp:MustSupportRefKeyIdentifier/> 
       <sp:MustSupportRefIssuerSerial/> 
       <sp:MustSupportRefThumbprint/> 
       <sp:MustSupportRefEncryptedKey/> 
      </wsp:Policy> 
     </sp:Wss10> 
     <sp:Wss11> 
      <wsp:Policy> 
       <sp:MustSupportRefKeyIdentifier/> 
       <sp:MustSupportRefIssuerSerial/> 
       <sp:MustSupportRefThumbprint/> 
       <sp:MustSupportRefEncryptedKey/> 
       <sp:RequireSignatureConfirmation/> 
      </wsp:Policy> 
     </sp:Wss11> 
    </wsp:All> 
</wsp:ExactlyOne> 
<wsp:Policy wsu:Id="InputBindingPolicy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sp:EncryptedParts> 
       <sp:Body/> 
      </sp:EncryptedParts> 
      <sp:SignedParts> 
       <sp:Body/> 
      </sp:SignedParts> 
     </wsp:All> 
    </wsp:ExactlyOne> 
</wsp:Policy> 
<wsp:Policy wsu:Id="OutputBindingPolicy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sp:EncryptedParts> 
       <sp:Body/> 
      </sp:EncryptedParts> 
      <sp:SignedParts> 
       <sp:Body/> 
      </sp:SignedParts> 
     </wsp:All> 
    </wsp:ExactlyOne> 
</wsp:Policy> 

Répondre

0

Cette politique est WOKING mais ne fonctionne que (je peux obtenir le wsdl) avec CxF bibliothèques 2.7-redhat. Mais j'ai trouvé un bogue, cette bibliothèque est pas vraiment parce que lorsqu'elle scanne la politique, elle détecte le premier jeton et ignore l'assertion du jeton 11. J'ai signalé cela au fournisseur avec qui je travaillais. Et nous changeons la politique pour ne prendre en charge que le jeton 11.

0

Il est pas valable, que la politique est interprétée comme "tous". Si vous souhaitez prendre en charge le fait qu'un jeton reçu peut être l'une ou l'autre de ces deux stratégies, vous devez écrire une alternative de stratégie pour les deux jetons.

+0

Vous avez raison. Je l'ai changé – UserMan