Я обновляю предыдущий клиент 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.
Мысли об этом?