Политика для подписания и шифрования

Question

Мне нужно реализовать jax-ws-клиент.

Вот что документы провайдера говорят о безопасности

В настоящее время мы используем версию SOAP Message Security 1.0 спецификации на http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Этот стандарт использует два других от W3C нормы:
XMLENC (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
и XMLDSIG (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/)

Для подписи, a «SecurityTokenReference» с использованием прямого «ссылка», определяющая «URI» и «valueType» X509, является обязательной. Для шифрование мы также рекомендуем, но также поддерживаем в порядке ссылку на ключIdentifier, X509IssuerSerial или keyName.

Заблокированный и подписанный блок должен быть тегом «тело».

Мы рекомендуем использовать: «rsa-sha1» для подписи «rsa-1_5» для ключа шифрования и «tripledes-cbc» для шифрования тела.

Итак, я придумал следующую политику (созданную из небанковских). Но ... он не подходит ко мне. Веб-сервис пока недоступен, но я не уверен, что версии спецификаций совпадают. Я много читал по этому вопросу, но я все еще несколько смущен. Эта политика выглядит нормально?

<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: Я не мог заставить его отправить ожидаемое сообщение с WSIT пока. В качестве примера, используя мастер Netbeans, я не смог получить зашифрованный заголовок без использования адресации. Предполагается ли это, что это возможно?

Я взломал что-то со старой осью 1 класс и wss4j, это работает, но это уродливо, и я предпочел бы использовать что-то более перспективное.

Answer 1

Возможно, вы хотите попробовать CXF вместо WSIT? http://cxf.apache.org/docs/ws-security.html

Answer 2

Вы действительно смущены. В общем, у вас должна быть единая политика. В вашем случае вы рискуете принять необеспеченные вызовы веб-сервисов, потому что у вас есть одна политика, определяющая транспортную привязку (https), а другая - нет.

Кроме того, поскольку у вас есть привязка к транспорту, это означает, что все тело будет зашифровано транспортным протоколом (https). Вам не нужно явно указывать шифрование тела. Фактически, эта привязка будет шифровать все, кроме заголовка http.

Транспортное переплетение - самый простой способ получить безопасные веб-сервисы. Если вам нужен полный контроль, вы должны написать собственное симметричное или асимметричное привязку в зависимости от ваших потребностей. Asymetric сложнее, потому что для этого требуется сертификат с обеих сторон, в то время как для асимметричного требуется только сертификат сервера (принимает анонимных клиентов). Асимметричные и симметричные привязки требуют осторожности. Они разработаны, чтобы быть очень гибкими и позволят вам разрабатывать любую политику, даже если она уязвима для определенных атак.

Если вы не используете транспортную привязку, то вы должны указать, что тело должно быть зашифровано.Как указано в спецификации:

sp:EncryptedParts/sp:Body 

Или переводится в XML:

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

Точно так же, если вы хотите, чтобы тело было подписано:

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

Есть несколько вариантов, чтобы указать подпись/шифрование, следует ли шифровать подпись или нет и т. д.

Как следует из названия, s, такие как sp: EndorsingSupportingToken применяются к поддерживающим маркерам. Тип, с которым я знаком, - это токен имени пользователя, который вы можете включить в запросы веб-сервисов.

WS-SecurityPolicy specification - это самый полезный документ, который я прочитал, чтобы понять политику. Вы должны потратить время, чтобы прочитать это полностью. Он подробно описывает все и содержит полезные примеры. Хорошо читать разные версии документов, поскольку некоторые аспекты будут лучше документированы в более поздних версиях. Примечание. Я связан с v1.3.

Установите клиент и сервер веб-службы и напишите простые тесты. Особенно, если вы новичок в веб-сервисах.

Одним из инструментов, который поможет вам быстро разработать политику, является SoapUI. Он не поддерживал точно то, что мне нужно, но это помогло мне узнать пару вещей. У этого есть большой пользовательский интерфейс, и это не очень сложно использовать.

Приведите примеры или создайте их, а затем деконструируйте их с помощью спецификации.

Я нашел политики довольно сложными. Будьте готовы поглотить много понятий!