Получение заголовка безопасности WS в сообщении недопустимо. при вызове ACAGetTransmitterBulkRequestStatus

Мне удалось совершить успешный вызов первой веб-службы ACA, и я подумал, что получить статус будет проще простого. Бо-о-ой, как я ошибался!

Я использовал те же настройки для службы состояния, что и для службы отправки ... и получил "Недопустимая ошибка заголовка WS Security!" Что дает?!?! Код генерации подписи тот же, что я использовал для отправки! Я был бы признателен, если бы кто-нибудь смог пролить свет на то, что, возможно, здесь не так? Я знаю, что следующие теги должны быть подписаны цифровой подписью (и я подписал их):

  1. ACABusinessHeader
  2. ACABulkRequestTransmitterStatusDetailRequest
  3. Отметка времени безопасности

Вот моя просьба:

POST https://la.www4.irs.gov/airp/aca/a2a/1095BC_Status_Request_AATS2016 HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "RequestSubmissionStatusDetail"
Host: la.www4.irs.gov
Content-Length: 5217
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<s:Envelope xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments" />
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                <Reference URI="#_1">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>KBLc15A=</DigestValue>
                </Reference>
                <Reference URI="#_2">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>dhkLQhzfkc=</DigestValue>
                </Reference>
                <Reference URI="#TS-ccf5abbbd36940f693d56b21ab489674">
                    <Transforms>
                        <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>O179zVlJnyo=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>REDUCTED</SignatureValue>
            <KeyInfo>
                <wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">-- Base64ed cert ---</wsse:KeyIdentifier>
                </wsse:SecurityTokenReference>
            </KeyInfo>
        </Signature>
        <u:Timestamp u:Id="TS-ccf5abbbd36940f693d56b21ab489674">
            <u:Created>2016-04-01T15:02:00.505Z</u:Created>
            <u:Expires>2016-04-01T15:12:00.506Z</u:Expires>
        </u:Timestamp>
    </wsse:Security>
    <abh:ACABusinessHeader u:Id="_1" xmlns:abh="urn:us:gov:treasury:irs:msg:acabusinessheader">
        <UniqueTransmissionId xmlns="urn:us:gov:treasury:irs:ext:aca:air:7.0">REDUCTED</UniqueTransmissionId>
        <Timestamp xmlns="urn:us:gov:treasury:irs:common">2016-04-01T11:02:58Z</Timestamp>
    </abh:ACABusinessHeader>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <ACABulkRequestTransmitterStatusDetailRequest u:Id="_2" version="1.0" xmlns="urn:us:gov:treasury:irs:msg:irstransmitterstatusrequest">
        <ACABulkReqTrnsmtStsReqGrpDtl xmlns="urn:us:gov:treasury:irs:ext:aca:air:7.0">
            <ReceiptId xmlns="urn:us:gov:treasury:irs:common">Receit Id</ReceiptId>
        </ACABulkReqTrnsmtStsReqGrpDtl>
    </ACABulkRequestTransmitterStatusDetailRequest>
</s:Body>

UPDATE1: I am more and more convinced, that something is up on their end with our certificate and status service. It looks like they unable to map receipt id to the proper certificate. At least they conformed, that structurally there is nothing wrong with the XML, that I've been sending them. But they unable to identify the actual problem. IRS asked me to resent them my request in the email again for farther investigation, which I did. Now will wait and c what will happen.


person fatherOfWine    schedule 01.04.2016    source источник
comment
Как вы генерируете xml? Мне удалось заставить мое решение работать с IRS, только вручную создав мой конверт и заголовки SOAP, за исключением элемента Security, который в значительной степени генерируется классом SignedXml.   -  person Bon    schedule 04.04.2016
comment
@Bon Спасибо за ответ! Я вручную генерирую подпись с помощью класса SignedXml. Так что я думаю, что в этом отделе мы находимся в одной лодке. Чего я не понимаю, почему то, что работает для службы отправки, не работает для первого статуса? Я видел, как вы заставили работать обе службы. В чем разница, которая заставила работать статусную службу?   -  person fatherOfWine    schedule 04.04.2016
comment
Я думаю, что единственная разница для меня заключалась в том, что я подписывал разные элементы, как указано в их pdf.   -  person Bon    schedule 05.04.2016
comment
@Bon Спасибо за повтор. Я понимаю. Я подумал, что сервис ожидает разные алгоритмы генерации подписи. Очевидно, что это не так. Как соломинка: не могли бы вы поделиться, как выглядит успешный запрос?   -  person fatherOfWine    schedule 05.04.2016
comment
@Bon Вы передаете сертификат поля KeyIdentifier, который был загружен на сайт IRS, верно?   -  person fatherOfWine    schedule 05.04.2016
comment
Да, я этим и занимаюсь.   -  person Bon    schedule 06.04.2016


Ответы (2)


Ну короче говоря. Статусная служба сейчас работает. В конце концов, команда разработчиков back'n'forthing IRS удалила клиентские конфигурации, которые помечались как удаленные, и после этого, похоже, статусный сервис получил настрой на работу. Я немного устала от того, как разрешилась ситуация, но если в итоге все заработало - пусть будет!

person fatherOfWine    schedule 02.06.2016

(У меня недостаточно репутации, чтобы добавить комментарий)

@fatherOfWine, я заметил, что в ваших элементах Transform отсутствует элемент InclusiveNamespaces. Извините за то, что вы, возможно, уже знаете, включенные пространства имен учитываются при канонизации XML и, в конечном итоге, при вычислении дайджестов SHA1.

Отправьте электронное письмо в службу технической поддержки ACA IRS и попросите их просмотреть свои журналы, соответствуют ли три присланных вами значения дайджеста их расчетам. Они смогут по крайней мере определить, какие из ваших значений дайджеста проходят и не проходят проверки. Сообщите им TCC и местное время, по которому вы отправили запрос.

person rjp    schedule 20.04.2016
comment
Спасибо за ответ. Но включающие пространства имен AFAIK необходимы только в том случае, если их определения являются внешними по отношению к подписываемому документу. Помимо этого, моя служба отправки работает довольно хорошо и использует тот же код подписи, который создал подпись для запроса, который я разместил в этом вопросе. Что хорошо для гуся, должно быть хорошо для гусака, n'es pas? :)) - person fatherOfWine; 21.04.2016