签名和加密政策

Question

我需要实现一个jax-ws客户端。

以下是供应商文档中关于安全性的说明

目前，我们使用SOAP消息安全性规范版本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的方式。对于加密，我们也建议这样做，但也支持以keyIdentifier、X509IssuerSerial或keyName为优先顺序进行引用。

加密和签名块必须是“body”标签。

我们建议使用：“rsa-sha1”进行签名，“rsa-1_5”进行加密密钥，“tripledes-cbc”进行加密体。

因此，我想到了以下策略（从NetBeans生成）。但是… 它看起来对我来说不正确。WebService尚未可达，但我不确定规范版本是否匹配。我阅读了很多相关资料，但仍有点困惑。这个策略看起来可以吗？

<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>

编辑： 我无法使用wsit-yet发送预期的消息。例如，使用Netbeans向导，我无法在不使用寻址的情况下获得加密标头。这应该是可能的吗？

我用旧的axis 1类和wss4j做了一些hack，它可以工作但很丑陋，我宁愿使用更为未来化的东西。

- ymajoros

---

我无法使用wsit-yet发送预期的消息。例如，使用Netbeans向导，我无法在不使用寻址的情况下获得加密标头。这是否应该是可能的？我使用旧的axis 1类和wss4j进行了一些修改，它可以工作，但很丑陋，我宁愿使用更具未来性的东西。 - ymajoros

这更像是一个代码审查问题，应该在代码审查网站上发布。 - user1378730

Answer 1

您似乎确实感到困惑。通常情况下，您应该只有一个策略。在您的情况下，由于您只定义了一种传输绑定（https），而另一种没有定义，因此您可能会冒险接受不安全的Web服务调用。

此外，由于您有传输绑定，这意味着整个正文将被传输协议（https）加密。您不需要明确指定正文加密。事实上，此绑定将加密除HTTP标头之外的所有内容。

传输绑定确实是获得安全Web服务的最简单方法。如果您想要完全控制，则必须根据需要编写自己的对称或非对称绑定。非对称绑定更复杂，因为它需要两侧都有证书，而对称绑定仅需要服务器证书（接受匿名客户端）。对称和非对称绑定需要注意。它们旨在具有高度灵活性，并将让您设计任何策略，即使容易受到某些攻击。

当不使用传输绑定时，您必须指定正文必须加密。如规范所述：

sp:EncryptedParts/sp:Body

或者翻译成xml格式：

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

同样地，如果您想签署正文：

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

有更多选项来指定签名/加密顺序，是否加密签名等。

顾名思义，像sp:EndorsingSupportingToken这样的策略适用于支持令牌。我熟悉的类型是您可以在Web服务请求中包含的用户名令牌。

WS-SecurityPolicy规范是我阅读以了解策略的最有用的文档。您应该花时间彻底阅读此文档。它详细说明了一些事情，并包含有用的示例。阅读不同版本的文档很好，因为某些方面在较新版本中将得到更好的记录。请注意，我链接了v1.3。

设置Web服务客户端和服务器并编写简单测试。特别是如果您是新手。

一个可以帮助您快速制定策略的工具是SoapUI。它没有完全支持我所需的内容，但它帮助我学习了一些东西。它有一个很棒的用户界面，而且使用起来不是很难。

获取一些示例或构建一些示例，然后在规范的帮助下进行解构。

我发现策略非常复杂。准备吸收很多概念！

- Philippe A.

---

好吧，我没有选择。作为客户端，我对其他客户端使用的服务器没有发言权（无论我对它有何看法）。我拥有一个没有安全限制的WSDL文档。这是不可协商的。 - ymajoros

你的合作伙伴们不太合作。也许他们并不是很感兴趣你调用他们的服务？如果他们进行客户端身份验证，你将永远无法在没有适当客户端证书的情况下调用该服务。如果他们要求用户名+密码令牌，你也永远无法调用该服务。也许他们接受匿名客户端通过https连接？试一试吧。编写一个使用https安全性的简单web服务（即：一个单独的Hello World函数）。然后编写相应的客户端。一旦它工作了，交叉你的手指，尝试使用“真正”的服务。 - Philippe A.

“我的合作伙伴”实际上是我的客户的合作伙伴，而且他们已经垄断了市场，所以我们必须调用他们的Web服务，因为我们别无选择，而且我们已经深陷于现状，这种情况不会很快改变。他们掌控着世界，你会惊讶于他们所做的事情（指的是他们的业务，而不是技术）。无论如何，我有一个丑陋的黑客方法，如上所述，它在生产中运行了几个月。 - ymajoros

Answer 2

也许你可以尝试使用CXF而不是WSIT？http://cxf.apache.org/docs/ws-security.html

- adosaiguas

---

我做到了。我用一个丑陋的hack解决了我的问题。供应商表示将使用安全约束条件制作一个体面的wsdl，可能在明年左右。当他们这样做时，我将使用wsit，它应该可以工作。与此同时，我的丑陋hack也能够工作。 - ymajoros

你是用CXF实现了你的丑陋黑科技吗？ - adosaiguas

不，我调整了一些wss4j和metro 1类以与metro配合使用，因为我在metro / wss4j中有一个可工作的配置。我基本上复制并更改了metro类，因此没有依赖于metro。我仍然相信metro是正确的选择。由于我不得不深入研究wss4j，所以我向您保证它非常混乱。 - ymajoros