【问题标题】:Policy for signing and encrypting签名和加密策略
【发布时间】:2012-05-14 11:14:49
【问题描述】:

我需要实现一个 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” 指定 X509 的“URI”和“valueType”的“reference”是强制性的。为了 加密,我们也推荐它,但我们也支持按顺序 首选对 keyIdentifier、X509IssuerSerial 或 键名。

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

我们建议使用:“rsa-sha1”作为签名,“rsa-1_5”作为签名 加密密钥和用于加密正文的“tripledes-cbc”。

所以我想出了以下策略(从 netbeans 生成)。但是……我觉得不合适。尚无法访问 Web 服务,但我不确定规范版本是否匹配。我读了很多关于这个主题的书,但我仍然有些困惑。这个政策看起来好吗?

<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 发送预期的消息。例如,使用 Netbeans 向导,如果不使用寻址,我无法获得加密的标头。它应该是可能的吗?

我用旧的轴 1 类和 wss4j 破解了一些东西,它可以工作,但它很难看,我宁愿使用更面向未来的东西。

【问题讨论】:

  • 我无法使用 wsit 发送预期的消息。例如,使用 Netbeans 向导,如果不使用寻址,我无法获得加密的标头。它应该是可能的吗?我用旧的轴 1 类和 wss4j 破解了一些东西,它可以工作,但它很丑陋,我宁愿使用更面向未来的东西。
  • 这更像是一个代码审查问题,属于代码审查网站。

标签: java web-services jax-ws ws-security java-metro-framework


【解决方案1】:

你看起来确实很困惑。一般来说,您应该有一个单一的策略。在您的情况下,您可能会接受不安全的 Web 服务调用,因为您有一个定义传输绑定 (https) 的策略,而另一个则没有。

此外,由于您有传输绑定,这意味着整个正文将由传输协议 (https) 加密。您不需要明确指定正文加密。事实上,这个绑定会加密除 http 头之外的所有内容。

传输绑定确实是获得安全 Web 服务的最简单方法。如果您想要完全控制,您必须根据您的需要编写自己的对称或不对称绑定。 Asymetric 比较复杂,因为它需要双方都有证书,而 asymetric 只需要服务器证书(接受匿名客户端)。不对称和对称绑定需要小心。它们被设计为高度灵活,可以让您设计任何策略,即使容易受到某些攻击。

当不使用传输绑定时,您必须指定必须加密的正文。如规格所述:

sp:EncryptedParts/sp:Body

或者翻译成xml:

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

同样,如果您希望对正文进行签名:

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

有更多选项可以指定签名/加密顺序,是否加密签名等

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

WS-SecurityPolicy specification 是我读过的用于理解政策的最有用的文档。你应该花时间彻底阅读这篇文章。它很好地详细说明了事情并包含有用的示例。最好阅读不同版本的文档,因为某些方面将在更新的版本中得到更好的记录。注意我链接了 v1.3。

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

SoapUI 是一个可以帮助您快速制定政策的工具。它不完全支持我需要的东西,但它帮助我学到了一些东西。它有一个很棒的用户界面,而且使用起来并不难。

获取一些示例或构建一些示例,然后在规范的帮助下解构它们。

我发现政策相当复杂。准备好吸收很多概念!

【讨论】:

  • 好吧,我别无选择。我是客户,对其他客户使用的服务器无话可说(无论我怎么想)。我有一个没有安全限制的 wsdl。这是没有商量余地的。
  • 你们合作伙伴不太合作。也许他们对你称之为他们的服务并不感兴趣?如果他们进行客户端身份验证,您将永远无法在没有正确客户端证书的情况下调用该服务。如果他们需要用户名+密码令牌,您也将永远无法调用该服务。也许他们通过 https 接受匿名客户?测试一下。使用 https 安全性编写一个简单的 Web 服务(即:单个 hello world 函数)。然后对对应的客户端进行编码。一旦它起作用,交叉手指并尝试使用“真正的”服务。
  • “我的合作伙伴”实际上是我客户的合作伙伴,无论如何他们都拥有垄断地位,所以我们需要调用他们的网络服务,因为我们别无选择,而且我们如此沉迷于现状它不会很快改变。他们统治着世界,你会对他们的所作所为感到惊讶(他们的业务,而不是技术)。无论如何,我有一个上面提到的丑陋的黑客,几个月以来它在生产中有效。
【解决方案2】:

也许您想尝试使用 CXF 而不是 WSIT? http://cxf.apache.org/docs/ws-security.html

【讨论】:

  • 我可以。我用一个丑陋的黑客解决了我的问题。该提供商表示,它可能会在明年左右制作出具有安全约束的体面的 wsdl。如果他们愿意,我将使用 wsit,它应该可以工作。与此同时,我丑陋的 hack 奏效了。
  • 那你有没有用 CXF 来做你丑陋的 hack?
  • 不,我调整了一些 wss4j 和 Metro 1 类来使用 Metro,因为我在 Metro / wss4j 中有一个工作配置。我基本上复制和更改了metro类,所以对metro没有依赖。我仍然相信地铁是正确的选择。因为我必须深入了解 wss4j,所以我向你保证它非常脏。
猜你喜欢
  • 1970-01-01
  • 2022-06-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-13
  • 2011-04-07
相关资源
最近更新 更多