Как угадать порядок элементов в валу с ответом WS-Security? - PullRequest
1 голос
/ 10 декабря 2010

Мой клиент 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 был не в порядке. Все, что мне нужно было сделать, это объединить эти предметы. Они выглядят так:

<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. Как я могу угадать, какие элементы мне нужно добавить в конфигурацию InflowSecurity, если все, что у меня было, подписано и зашифровано? Есть ли способ узнать, какой порядок я должен использовать?

1 Ответ

1 голос
/ 02 апреля 2013

Это довольно старый вопрос, но когда я только что закончил свое путешествие по этой стране боли, я поделюсь ответами.

a) Порядок элементов обеспечивается базовой библиотекой wss4j, а не rampart. Проблемным методом является checkReceiverResults () из org.apache.ws.security.handler.WSHandler. Возможно, вы столкнулись с проблемами при использовании rampart WSDoAllReceiver, расширяющего WSHandler.

б) Хорошая новость заключается в том, что метод checkReceiverResults () защищен. Таким образом, вы можете расширить WSDoAllReceiver и переопределить метод, чтобы сделать его более разрешающим. Я предлагаю посмотреть на реализацию checkReceiverResultsAnyOrder (), добавленную в WSHandler в wss4j-1.5.8.

Итак, чтобы ответить на ваши вопросы:

Вы можете отладить метод checkReceiverResults (), чтобы узнать и «исправить» порядок элементов в вашем файле axis2.xml. Но это не очень хороший способ, так как порядок заголовков всегда может меняться (нет требований к порядку элементов в заголовке SOAP). Поэтому я предлагаю вызывать checkReceiverResultsAnyOrder (), а не checkReceiverResults ().

...