Ответ 1
Возможно, вы хотите попробовать CXF вместо WSIT? http://cxf.apache.org/docs/ws-security.html
Мне нужно реализовать 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/)Для подписи "SecurityTokenReference" с использованием прямого "ссылка", указывающая "URI" и "valueType" X509, является обязательной. Для шифрование, мы также рекомендуем его, но также поддерживаем в порядке Предпочитаете ссылку на ключевой идентификатор, X509IssuerSerial или KEYNAME.
Зашифрованный и подписанный блок должен быть тегом body.
Мы рекомендуем использовать: "rsa-sha1" для подписи "rsa-1_5" для ключ шифрования и "tripledes-cbc" для шифрования тела.
Итак, я придумал следующую политику (созданную из netbeans). Но... он не подходит ко мне. Веб-сервис пока недоступен, но я не уверен, что версии спецификаций совпадают. Я много читал по этому вопросу, но я все еще несколько смущен. Эта политика выглядит нормально?
<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-yet. В качестве примера, используя мастер Netbeans, я не смог получить зашифрованный заголовок без использования адресации. Предполагается ли это, что это возможно?
Я взломал что-то со старой осью 1 класс и wss4j, он работает, но это уродливо, и я предпочел бы использовать что-то более перспективное.
Возможно, вы хотите попробовать CXF вместо WSIT? http://cxf.apache.org/docs/ws-security.html
Вы, похоже, смущены. В общем, у вас должна быть единая политика. В вашем случае вы рискуете принять необеспеченные вызовы веб-сервисов, потому что у вас есть одна политика, определяющая транспортную привязку (https), а другая - нет.
Кроме того, поскольку у вас есть привязка к транспорту, это означает, что весь объект будет зашифрован транспортным протоколом (https). Вам не нужно явно указывать шифрование тела. Фактически, это связывание будет шифровать все, кроме http-заголовка.
Транспортное связывание действительно самый простой способ получить защищенные веб-сервисы. Если вам нужен полный контроль, вы должны написать собственное симметричное или асимметричное привязку в зависимости от ваших потребностей. Asymetric сложнее, потому что для этого требуется сертификат с обеих сторон, в то время как для асимметричного требуется только сертификат сервера (принимает анонимных клиентов). Асимметричные и симметричные привязки требуют осторожности. Они разработаны, чтобы быть очень гибкими и позволят вам разрабатывать любую политику, даже если она уязвима для определенных атак.
Если вы не используете транспортную привязку, вы должны указать, что тело должно быть зашифровано. Как указано в спецификациях:
sp:EncryptedParts/sp:Body
Или переведен в xml:
<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>
Аналогично, если вы хотите, чтобы тело было подписано:
<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>
Есть больше опций для указания порядка подписи/шифрования, для шифрования подписи или нет и т.д.
Как следует из названия, для поддержки токенов применяются политики, такие как sp: EndorsingSupportingToken. Тип, с которым я знаком, - это токен имени пользователя, который вы можете включить в запросы веб-сервисов.
Спецификация WS-SecurityPolicy - это самый полезный документ, который я прочитал для понимания политик. Вы должны потратить время, чтобы прочитать это полностью. Он подробно описывает все и содержит полезные примеры. Хорошо читать разные версии документов, поскольку некоторые аспекты будут лучше документированы в более поздних версиях. Примечание. Я связан с v1.3.
Настройте клиент и сервер веб-службы и напишите простые тесты. Особенно, если вы новичок в веб-сервисах.
Один инструмент, который поможет вам быстро формулировать политики, SoapUI. Он не поддерживал точно то, что мне нужно, но это помогло мне узнать пару вещей. У этого есть большой пользовательский интерфейс, и это не очень сложно использовать.
Получите несколько примеров или создайте их, а затем деконструируйте их с помощью спецификации.
Я нашел политики довольно сложными. Будьте готовы поглотить много концепций!