如何猜测具有 WS-Security 响应的城墙中的项目顺序?

发布于 2024-10-06 21:15:21 字数 4419 浏览 3 评论 0原文

我的 axis2+rampart 客户端与一些 WS-Secured 服务器一起使用。服务器升级后(JBoss 升级,WSDL 进行了一些更改,但测试功能中没有更改),它停止工作。服务器所有者声称他们的 WS-Security 配置没有更改,但现在我的客户报告:

org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security

早些时候,当 axis2.xml 中的“items”顺序不好时,我遇到了此异常。 我所要做的就是将这些项目组合起来。他们看起来像:

<parameter name="InflowSecurity">
  <action>
    <items>Signature Encrypt Timestamp</items>
...

现在这个问题又出现了。我看到回复中没有“时间戳”。我从项目中删除了它,但没有任何改变。

回复如下:

<soap:Envelope xmlns:soap="..."
    xmlns:xenc="...">
    <soap:Header>
        <wsse:Security
            xmlns:wsse="..."
            soap:mustUnderstand="1">
            <xenc:EncryptedKey xmlns:xenc="..."
                Id="EncKeyId-B8B3555394366F3F0112919826983351032">
                <xenc:EncryptionMethod Algorithm="..." />
                <ds:KeyInfo xmlns:ds="...">
                    <wsse:SecurityTokenReference
                        xmlns:wsse="...">
                        <wsse:KeyIdentifier
                            ...
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
                <xenc:CipherData>
                    <xenc:CipherValue>
                        ...
                    </xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                    <xenc:DataReference URI="#EncDataId-624" />
                </xenc:ReferenceList>
            </xenc:EncryptedKey>
            <ds:Signature xmlns:ds="..."
                Id="Signature-622">
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod
                        Algorithm="..." />
                    <ds:SignatureMethod Algorithm="..." />
                    <ds:Reference URI="#id-623">
                        <ds:Transforms>
                            <ds:Transform Algorithm="..." />
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="..." />
                        <ds:DigestValue>
                            ...
                        </ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>
                    ...
                </ds:SignatureValue>
                <ds:KeyInfo Id="KeyId-B8B3555394366F3F0112919826983181029">
                    <wsse:SecurityTokenReference
                        xmlns:wsse="..."
                        xmlns:wsu="..."
                        wsu:Id="STRId-B8B3555394366F3F0112919826983181030">
                        <wsse:KeyIdentifier
                            EncodingType="..."
                            ValueType="...">
                            ...
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
        </wsse:Security>
    </soap:Header>
    <soap:Body xmlns:ns1="..."
        xmlns:wsu="..."
        wsu:Id="id-623">
        <xenc:EncryptedData xmlns:xenc="..."
            Id="EncDataId-624" Type="...">
            <xenc:EncryptionMethod Algorithm="..." />
            <ds:KeyInfo xmlns:ds="...">
                <wsse:SecurityTokenReference
                    xmlns:wsse="...">
                    <wsse:Reference
                        xmlns:wsse="..."
                        URI="#EncKeyId-B8B3555394366F3F0112919826983351032" />
                </wsse:SecurityTokenReference>
            </ds:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>
                    ...
                </xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </soap:Body>
</soap:Envelope>

我的问题:

  1. 我如何知道安全的哪一部分真正失败了?是否是顺序错误、缺少某些元素、某些元素多余或类似错误?
  2. 如果我拥有的只是签名和加密的回复,我如何猜测应该将哪些项目添加到 Rampart InflowSecurity 配置中?有没有办法知道我应该使用什么顺序的项目?

My axis2+rampart client worked with some WS-Secured server. It stopped working after server was upgraded (JBoss upgrade, some changes in WSDL, but not in test function). Server owners claim that their WS-Security configuration was not changed, but now my client reports:

org.apache.axis2.AxisFault: Must Understand check failed for header http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security

Earlier I got this exception when order of "items" in axis2.xml was not good.
All I had to do was to combine those items. They look like:

<parameter name="InflowSecurity">
  <action>
    <items>Signature Encrypt Timestamp</items>
...

Now this problem reappeared. I see that in reply there is no 'Timestamp'. I removed that from items but nothing changed.

Reply looks like:

<soap:Envelope xmlns:soap="..."
    xmlns:xenc="...">
    <soap:Header>
        <wsse:Security
            xmlns:wsse="..."
            soap:mustUnderstand="1">
            <xenc:EncryptedKey xmlns:xenc="..."
                Id="EncKeyId-B8B3555394366F3F0112919826983351032">
                <xenc:EncryptionMethod Algorithm="..." />
                <ds:KeyInfo xmlns:ds="...">
                    <wsse:SecurityTokenReference
                        xmlns:wsse="...">
                        <wsse:KeyIdentifier
                            ...
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
                <xenc:CipherData>
                    <xenc:CipherValue>
                        ...
                    </xenc:CipherValue>
                </xenc:CipherData>
                <xenc:ReferenceList>
                    <xenc:DataReference URI="#EncDataId-624" />
                </xenc:ReferenceList>
            </xenc:EncryptedKey>
            <ds:Signature xmlns:ds="..."
                Id="Signature-622">
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod
                        Algorithm="..." />
                    <ds:SignatureMethod Algorithm="..." />
                    <ds:Reference URI="#id-623">
                        <ds:Transforms>
                            <ds:Transform Algorithm="..." />
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="..." />
                        <ds:DigestValue>
                            ...
                        </ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>
                    ...
                </ds:SignatureValue>
                <ds:KeyInfo Id="KeyId-B8B3555394366F3F0112919826983181029">
                    <wsse:SecurityTokenReference
                        xmlns:wsse="..."
                        xmlns:wsu="..."
                        wsu:Id="STRId-B8B3555394366F3F0112919826983181030">
                        <wsse:KeyIdentifier
                            EncodingType="..."
                            ValueType="...">
                            ...
                        </wsse:KeyIdentifier>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
        </wsse:Security>
    </soap:Header>
    <soap:Body xmlns:ns1="..."
        xmlns:wsu="..."
        wsu:Id="id-623">
        <xenc:EncryptedData xmlns:xenc="..."
            Id="EncDataId-624" Type="...">
            <xenc:EncryptionMethod Algorithm="..." />
            <ds:KeyInfo xmlns:ds="...">
                <wsse:SecurityTokenReference
                    xmlns:wsse="...">
                    <wsse:Reference
                        xmlns:wsse="..."
                        URI="#EncKeyId-B8B3555394366F3F0112919826983351032" />
                </wsse:SecurityTokenReference>
            </ds:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>
                    ...
                </xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </soap:Body>
</soap:Envelope>

My questions:

  1. How can I know what part of security really failed? Is it wrong order, lack of some element, some element extra or similar error?
  2. How can I guess what items should I add to rampart InflowSecurity configuration if all I had is signed and encrypted reply? Is there way to know what order of items should I use?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

紅太極 2024-10-13 21:15:21

这是一个相当老的问题,但当我刚刚结束那段痛苦之地的旅程时,我将分享答案。

a) 项目的顺序由底层 wss4j 库强制执行,而不是由 Rampart 强制执行。有问题的方法是 org.apache.ws.security.handler.WSHandler 中的 checkReceiverResults()。您可能在使用扩展 WSHandler 的 Rampart WSDoAllReceiver 时遇到了问题。

b) 好消息是 checkReceiverResults() 方法受到保护。因此,您可以扩展 WSDoAllReceiver 并重写该方法以使其更加宽松。我建议查看在 wss4j-1.5.8 中添加到 WSHandler 的 checkReceiverResultsAnyOrder() 实现。

因此,回答您的问题:

您可以调试 checkReceiverResults() 方法来查找并“修复” axis2.xml 文件中的项目顺序。但这不是一个好方法,因为标头的顺序可能总是会改变(SOAP 标头中的元素顺序没有要求)。所以我的建议是调用 checkReceiverResultsAnyOrder() 而不是 checkReceiverResults()。

That's rather old question, but as I just finished my journey through that land of pain, I'll share the answers.

a) The order of items is enforced by underlying wss4j library, not by rampart. The problematic method is checkReceiverResults() from org.apache.ws.security.handler.WSHandler. You probably ran into problems by using rampart WSDoAllReceiver which is extending WSHandler.

b) Good news is that checkReceiverResults() method is protected. So you can extend WSDoAllReceiver and override the method to make it more permissive. I suggest looking at checkReceiverResultsAnyOrder() implementation added to WSHandler in wss4j-1.5.8.

So to answer your questions:

You can debug checkReceiverResults() method to find out and "fix" order of items in your axis2.xml file. But that's not a good way to go, as the order of headers may always change (there is no requirement for order of elements in SOAP header). So my suggestion is calling checkReceiverResultsAnyOrder() rather than checkReceiverResults().

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文