Richtlinie zum Signieren und Verschlüsseln

Question

Ich muss einen Jax-WS-Client implementieren. Hier

ist, was die Anbieter docs sagen über Sicherheit

Derzeit nutzen wir die SOAP Message Security Version 1.0-Spezifikation bei http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Dieser Standard verwendet zwei anderen von W3C Norm:
XMLENC (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
und XMLDSIG (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/)

Für die Unterschrift, Eine "SecurityTokenReference" mit einer direkten "Referenz", die "URI" und "valueType" von X509 angibt, ist obligatorisch. Für die Verschlüsselung, empfehlen wir es auch, aber wir unterstützen auch in der Reihenfolge Präferenz eine Referenz zu einem keyIdentifier, einem X509IssuerSerial oder keyName.

Der verschlüsselte und signierte Block muss das "body" -Tag sein.

Wir empfehlen zu verwenden: "rsa-sha1" für die Signatur, "rsa-1_5" für Verschlüsselungsschlüssel und "tripledes-cbc" für die Verschlüsselung des Körpers.

So kam ich mit folgenden Politik (aus Netbeans generiert). Aber ... es sieht nicht richtig für mich aus. Der Webservice ist noch nicht erreichbar, aber ich bin nicht sicher, ob die Spezifikationsversionen übereinstimmen. Ich lese viel zu diesem Thema, aber ich bin immer noch etwas verwirrt. Sieht diese Richtlinie in Ordnung aus?

<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: ich es nicht die erwartete Nachricht mit WSIT-noch schicken konnte. Als Beispiel konnte ich mithilfe des Netbeans-Assistenten keine verschlüsselte Kopfzeile abrufen, ohne die Adressierung zu verwenden. Soll es möglich sein?

Ich hackte etwas mit einer alten Achse 1 Klasse und wss4j, es funktioniert, aber es ist hässlich und ich würde eher etwas zukunftssicherer verwenden.

Answer 1

Vielleicht möchten Sie mit CXF anstelle von WSIT versuchen? http://cxf.apache.org/docs/ws-security.html

Answer 2

Sie scheinen tatsächlich verwirrt. Im Allgemeinen sollten Sie eine einzige Richtlinie haben. In Ihrem Fall riskieren Sie, ungesicherte Web-Service-Aufrufe anzunehmen, da Sie eine Richtlinie haben, die die Transportbindung (https) definiert, während die andere nicht.

Da Sie eine Transportbindung haben, bedeutet dies auch, dass der gesamte Körper durch das Transportprotokoll (https) verschlüsselt wird. Sie müssen die Körperverschlüsselung nicht explizit angeben. In der Tat wird diese Bindung alles außer dem HTTP-Header verschlüsseln.

Die Transportbindung ist wirklich der einfachste Weg, sichere Webdienste zu erhalten. Wenn Sie die totale Kontrolle wollen, müssen Sie Ihre eigene symmetrische oder asymetrische Bindung schreiben, abhängig von Ihren Bedürfnissen. Asymetrisch ist komplexer, da es ein Zertifikat auf beiden Seiten erfordert, während asymetrisch nur ein Serverzertifikat benötigt (akzeptiert anonyme Clients). Asymmetrische und symmetrische Bindungen erfordern Sorgfalt. Sie sind so konzipiert, dass sie äußerst flexibel sind und Ihnen das Design jeder Richtlinie ermöglichen, selbst wenn sie für bestimmte Angriffe anfällig sind.

Wenn keine Transportbindung verwendet wird, müssen Sie angeben, dass der Textkörper verschlüsselt sein muss.Wie in den Spezifikationen angegeben:

sp:EncryptedParts/sp:Body 

Oder in xml übersetzt:

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

Und falls Sie den Körper wollen unterzeichnet werden: mehr Optionen

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

Es gibt angeben Unterschrift/Verschlüsselungsreihenfolge, ob die Signatur zu verschlüsseln ist oder nicht, usw.

Wie der Name andeutet, policie s wie sp: EndorsingSupportToken gelten für unterstützende Token. Der Typ, mit dem ich vertraut bin, ist das Benutzername-Token, das Sie in Web-Service-Anfragen einfügen können.

Die WS-SecurityPolicy specification ist das einzige nützliche Dokument, das ich gelesen habe, um Richtlinien zu verstehen. Sie sollten sich Zeit nehmen, dies gründlich zu lesen. Es beschreibt die Dinge ziemlich gut und enthält nützliche Beispiele. Es ist gut, verschiedene Versionen der Dokumente zu lesen, da einige Aspekte in neueren Versionen besser dokumentiert sind. Hinweis Ich habe v1.3 verlinkt.

Richten Sie einen Web-Service-Client und -Server ein und schreiben Sie einfache Tests. Vor allem, wenn Sie neu bei Web Services sind.

Ein Tool, mit dem Sie Richtlinien schnell formulieren können, lautet SoapUI. Es unterstützte nicht genau das, was ich brauchte, aber es half mir, ein paar Dinge zu lernen. Es hat eine großartige Benutzeroberfläche und es ist nicht sehr schwer zu benutzen.

Besorgen Sie sich einige Beispiele oder bauen Sie sie auf, dann dekonstruieren Sie sie mit Hilfe der Spezifikation.

Ich habe festgestellt, dass Richtlinien ziemlich komplex sind. Sei bereit, viele Konzepte aufzunehmen!