Я подписываю запрос мыла WS-Security с помощью SignedXML, но у меня возникают проблемы при сопоставлении значения подписи SOAPUI - PullRequest
0 голосов
/ 22 октября 2019

Я обновляю предыдущий клиент WCF, который реализует WS-Security. Сервису ранее требовался только действительный сертификат вместе с UsernameToken. Поставщик изменил свое требование, и теперь, в дополнение к предыдущим элементам WS-Security, теперь требуется элемент Timestamp, и только для этого элемента должна быть цифровая подпись.

Я действительно считаю, что улучшения реализованы разумноЧто ж. Запрос «хорошо выглядит», включая подпись. Но служба не принимает запрос. Это не указывает на то, почему. Но я определил, что это подпись.

Я могу успешно отправить запрос с помощью SOAP-UI. Я считаю, что поскольку я подписываю только элемент timestamp, я должен иметь возможность (для целей тестирования) предоставлять те же значения wsu: Id, wsu: Created и wsu: Expires, которые использовались в SOAP-UIзапросить (зная, что эти значения устарели) и быть в состоянии создать то же значение подписи и значение справочного дайджеста, что и сгенерированный SOAP-UI.

Является ли это допустимым предположением?

Один вызов этомуПредполагается, что если я импортирую весь конверт SOAP в объект SignedXML, я получу другое значение двух хешей, чем при импорте только элемента wsse: Security. Это удивляет меня, так как процесс подписания в каждом случае правильно идентифицирует элемент wsu: Timestamp.

Правильно идентифицируя wsu: Timestamp, я имею в виду, что перегрузка метода GetElementId () находит wsu: Timestamp при вызове.

Я включу реальный код, который я реализовал, если эти основные вопросы указывают на то, что я на правильном пути:

Я переопределил GetIdElement, чтобы убедиться, что wsu: Id распознан.

Я использую Framework 4.7.1 и GetRSAPrivateKey () (из импорта сертификата, разрешающего экспорт закрытого ключа), чтобы получить ключ подписи.

Я создал ссылку на wsu:Элемент отметки времени:

<Reference URI="#TS-62B6909D4542C911A415716590862947">
    <Transforms>
      <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
         <InclusiveNamespaces PrefixList="wsse wsu cmaw s soapenv xsd"
                xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
      </Transform>
    </Transforms>
    <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
            <DigestValue>TtV9lso1WsMvwhiiKPADpYshmJcb95NZOj6BkuV5UmI=</DigestValue>
</Reference>

Я использовал:

CryptoConfig.AddAlgorithm(typeof   (RSAPKCS1SHA256SignatureDescription), "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256");

signedXML.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;

У меня есть «#» в начале URL ссылки (и нет «#» в фактической ссылке.

В любом случае, мой первый вопрос: стоит ли ожидать совпадения рабочей подписи SOAP в контролируемом тесте (устаревшие значения) и разумно ли этоПри использовании всего мыльного конверта должна создаваться подпись, отличная от импорта только элемента wsse: Security (я использую Инспектор сообщений для генерации элемента wsse: Security и, не находя другого пути, у меня нет доступа ко всемуконверт для передачи в SignedXML.

Примечание: я просмотрел здесь много хороших статей, в которых объясняется, как подписывать сообщения. Но моя текущая задача - получить подпись, которая работает - что, я надеюсь, означает соответствие SOAP-UI.

Мысли об этом?

1 Ответ

0 голосов
/ 25 октября 2019

В итоге я определил, что значение подписи, рассчитанное, когда SignedXml работает со всем конвертом SOAP, отличается от значения подписи, рассчитанного, когда SignedXml работает только с подмножеством. Я не понимаю, почему это так, так как я подписывал только элемент Timestamp, который присутствовал в обоих случаях и должным образом находился в SignedXml. Но не обязательно, чтобы я знал это конкретное «почему».

Клиент теперь работает после этого рефакторинга для подписи на основе всего мыльного конверта.

...