Politica per la firma e la crittografia

Question

Devo implementare un client jax-ws.

Ecco ciò che la documentazione del provider dicono di sicurezza

Attualmente, usiamo la versione specifica di SOAP Message Security 1.0 a http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Questo standard utilizza altri due dalla norma W3C:
XMLENC (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
e XMLDSIG (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/)

Per la firma, un "SecurityTokenReference" che utilizza un riferimento diretto " " che specifica "URI" e "valueType" di X509 è obbligatorio. Per la codifica , lo consigliamo anche noi, ma supportiamo anche in ordine di preferenza un riferimento a keyIdentifier, a X509IssuerSerial oa keyName.

Il blocco cifrato e firmato deve essere il tag "corpo".

Si consiglia di utilizzare: "rsa-sha1" per firma, "rsa-1_5" per chiave di crittografia e "tripledes-cbc" per la crittografia del corpo.

Quindi mi è venuta in mente la seguente politica (generata da netbeans). Ma ... non sembra giusto per me. Il servizio web non è ancora raggiungibile, ma non sono sicuro che le versioni specifiche corrispondano. Leggo molto sull'argomento, ma sono ancora un po 'confuso. Questa politica sembra ok?

<wsp1:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoapPolicy"> 
    <wsp1:ExactlyOne> 
     <wsp1:All> 
      <sp:TransportBinding> 
       <wsp1:Policy> 
        <sp:TransportToken> 
         <wsp1:Policy> 
          <sp:HttpsToken RequireClientCertificate="false"/> 
         </wsp1:Policy> 
        </sp:TransportToken> 
        <sp:Layout> 
         <wsp1:Policy> 
          <sp:Lax/> 
         </wsp1:Policy> 
        </sp:Layout> 
        <sp:AlgorithmSuite> 
         <wsp1:Policy> 
          <sp:TripleDesRsa15/> 
         </wsp1:Policy> 
        </sp:AlgorithmSuite> 
       </wsp1:Policy> 
      </sp:TransportBinding> 
      <sp:Wss10/> 
      <sp:EndorsingSupportingTokens> 
       <wsp1:Policy> 
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> 
         <wsp1:Policy> 
          <sp:WssX509V3Token10/> 
         </wsp1:Policy> 
        </sp:X509Token> 
       </wsp1:Policy> 
      </sp:EndorsingSupportingTokens> 

     </wsp1:All> 
    </wsp1:ExactlyOne> 
</wsp1:Policy> 
<wsp:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoap_perform_Input_Policy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sp1:SignedEncryptedSupportingTokens> 
       <wsp:Policy> 
        <sp1:X509Token sp1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> 
         <wsp:Policy> 
          <sp1:WssX509V3Token10/> 
         </wsp:Policy> 
        </sp1:X509Token> 
       </wsp:Policy> 
      </sp1:SignedEncryptedSupportingTokens> 
     </wsp:All> 
    </wsp:ExactlyOne> 

</wsp:Policy> 

EDIT: non ho potuto farlo per inviare il messaggio previsto con WSIT-ancora. Ad esempio, utilizzando la procedura guidata Netbeans, non sono riuscito a ottenere un'intestazione crittografata senza utilizzare l'indirizzamento. Dovrebbe essere possibile?

Ho hackerato qualcosa con una vecchia classe axis 1 e wss4j, funziona ma è brutto e preferirei usare qualcosa di più a prova di futuro.

Answer 1

Forse vuoi provare con CXF invece di WSIT? http://cxf.apache.org/docs/ws-security.html

Answer 2

Sembri davvero confuso. In generale dovresti avere un'unica politica. Nel tuo caso, rischi di accettare chiamate al servizio web non sicure perché hai una politica che definisce il trasporto vincolante (https), mentre l'altra no.

Inoltre, poiché si dispone di un'associazione di trasporto, ciò significa che l'intero corpo verrà crittografato dal protocollo di trasporto (https). Non è necessario specificare la crittografia del corpo in modo esplicito. In effetti, questa associazione crittografa tutto tranne l'intestazione http.

Il binding di trasporto è davvero il modo più semplice per ottenere servizi Web protetti. Se vuoi il controllo totale, devi scrivere il tuo legame simmetrico o asimmetrico a seconda delle tue esigenze. Asimmetrico è più complesso perché richiede un certificato su entrambi i lati, mentre l'asimmetria richiede solo un certificato server (accetta client anonimi). I collegamenti asimmetrici e simmetrici richiedono attenzione. Sono progettati per essere altamente flessibili e ti consentono di progettare qualsiasi politica, anche se vulnerabile a determinati attacchi.

Quando non si utilizza il trasporto bind, è necessario specificare che il corpo deve essere crittografato.Come indicato nelle specifiche:

sp:EncryptedParts/sp:Body 

o tradotta in xml:

<sp:EncryptedParts> 
    <sp:Body/> 
</sp:EncryptedParts> 

Allo stesso modo, se si desidera che il corpo per essere firmato:

<sp:SignedParts> 
    <sp:Body/> 
</sp:SignedParts> 

ci sono più opzioni per specificare la firma/ordine di crittografia, se crittografare la firma o meno, ecc.

Come suggerisce il nome, policie s come sp: EndorsingSupportingToken si applica ai token di supporto. Il tipo che conosco è il token nome utente che è possibile includere nelle richieste di servizi Web.

Il WS-SecurityPolicy specification è il singolo documento più utile che ho letto per comprendere le politiche. Dovresti prendere tempo per leggerlo attentamente. Descrive abbastanza bene le cose e contiene esempi utili. È bene leggere diverse versioni dei documenti poiché alcuni aspetti saranno meglio documentati nelle versioni più recenti. Nota Ho collegato v1.3.

Impostare un client e un server di servizi Web e scrivere test semplici. Soprattutto se sei nuovo ai servizi web.

Uno strumento che consente di formulare rapidamente le politiche è SoapUI. Non supportava esattamente quello di cui avevo bisogno, ma mi ha aiutato a imparare un paio di cose. Ha un'ottima interfaccia utente e non è molto difficile da usare.

Prendi alcuni esempi o costruisci alcuni, quindi decostruiscili con l'aiuto delle specifiche.

Ho trovato che le politiche sono piuttosto complesse. Preparati ad assorbire molti concetti!