Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.01.2015(UTC) Сообщений: 67
Сказал(а) «Спасибо»: 5 раз Поблагодарили: 2 раз в 2 постах
|
Автор: khomenko  Некоторые ссылки по СМЭВ 3.* можно посмотреть в этой ветке форума. Примет сервиса, настраиваемого через файл конфигурации, скоро добавим. У вас получилось сделать для СМЭВ 3 ? О, какой великий день ! Когда Вы добавите примерчик ? :) Отредактировано пользователем 25 мая 2015 г. 15:03:23(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2013(UTC) Сообщений: 67  Откуда: Новосибирск Сказал(а) «Спасибо»: 2 раз Поблагодарили: 2 раз в 2 постах
|
Автор: ESofter  Автор: khomenko  Некоторые ссылки по СМЭВ 3.* можно посмотреть в этой ветке форума. Примет сервиса, настраиваемого через файл конфигурации, скоро добавим. У вас получилось сделать для СМЭВ 3 ? О, какой великий день ! Когда Вы добавите примерчик ? :) Для СМЭВ 3.х всё делается аналогично. Я сейчас подобное делаю. Только не хватает реальных сервисов 3й версии, на которых это можно протестировать :(
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2013(UTC) Сообщений: 67  Откуда: Новосибирск Сказал(а) «Спасибо»: 2 раз Поблагодарили: 2 раз в 2 постах
|
У меня вот другая проблема по версии 2.0 Когда мы опрашиваем сервисы, то проблем не испытываем. А тут понадобилось интегрироваться с МинТруда. К сожалению, вышло так, что ответы мы от них получаем только путём отправки их запроса нам. Т.е. мы должны поднять что-то похожее на EventService как на ЕПГУ. Вроде что-то похожее написали с помощью WCF, но начались странные проблемы. Есть контракт: Код:
[ServiceContract(Namespace = "http://idecs.atc.ru/orderprocessing/ws/eventservice/v25/", Name = "EventService", ProtectionLevel = ProtectionLevel.Sign)]
public interface IEventService
{
[OperationContract(Action = "pushEvent")]
[XmlSerializerFormat]
RequestResponse PushEvent(Request request);
}
От клиента приходит сообщение, которое содержит подпись. Код:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:smev="http://smev.gosuslugi.ru/rev120315" xmlns:v25="http://idecs.atc.ru/orderprocessing/ws/eventservice/v25/" xmlns:inc="http://www.w3.org/2004/08/xop/include" xmlns:soc="http://socit.ru" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<soap:Header>
<wsse:Security soap:actor="http://smev.gosuslugi.ru/actors/smev">
<ds:Signature><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411" /><ds:Reference URI="#body"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411" /><ds:DigestValue>cf4UQotV02TI4bGbWoyRPg7yb/wzfUEfI2bLFfOfRmg=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J65C8/O/f5zhqlZWpek39IMGI49gtQj5JdXVG060iYs3TXtq9j6IJvZSdeGkUkBGDiFhnKZVtqwuXgfJu47XsQ==</ds:SignatureValue><ds:KeyInfo><wsse:SecurityTokenReference><wsse:Reference URI="#SenderCertificate" /></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="SenderCertificate">MIIIHzCCB86gAwIBAgIKP/dhFgABAAAG8TAIBgYqhQMCAgMwggEBMRowGAYIKoUDA4EDAQESDDAwNzEwNzA2NTA4MTEYMBYGBSqFA2QBEg0xMDI3MTAwOTcxMTgyMSYwJAYDVQQJDB3Qv9GALdC60YIg0JvQtdC90LjQvdCwINC0LiA0NjEpMCcGA1UECgwg0J7QntCeICLQk9Cy0LDRgNC0LdCY0L3RhNC+0YDQvCIxETAPBgNVBAcMCNCi0YPQu9CwMSswKQYDVQQIDCI3MSDQotGD0LvRjNGB0LrQsNGPINC+0LHQu9Cw0YHRgtGMMQswCQYDVQQGEwJSVTEpMCcGA1UEAwwg0J7QntCeICLQk9Cy0LDRgNC0LdCY0L3RhNC+0YDQvCIwHhcNMTQwODE0MDc0OTAwWhcNMTUwODE0MDc1OTAwWjCCAa8xFjAUBgUqhQNkAxILMDM0MDk1MjU2MzgxGDAWBgUqhQNkARINMTA0NzEwMTEyNTUzMjEaMBgGCCqFAwOBAwEBEgwwMDcxMDcwODE0ODUxCzAJBgNVBAYTAlJVMS8wLQYDVQQIHiYANwAxACAEIgRDBDsETARBBDoEMARPACAEPgQxBDsEMARBBEIETDERMA8GA1UEBx4IBCIEQwQ7BDAxLTArBgNVBAoeJAQeBB4EHgAgACIEIQQeBCYEGAQdBCQEHgQgBBwEIgQVBCUAIjEtMCsGA1UEAx4kBB4EHgQeACAAIgQhBB4EJgQYBB0EJAQeBCAEHAQiBBUEJQAiMTEwLwYDVQQJHigEQwQ7AC4AIAQkAC4EIQQ8BDgEQAQ9BD4EMgQwACAENAAuACAAMgA4MTEwLwYDVQQMHigEEwQ1BD0ENQRABDAEOwRMBD0ESwQ5ACAENAQ4BEAENQQ6BEIEPgRAMS0wKwYDVQQqHiQEIgQwBEIETARPBD0EMAAgBBIEOAQ6BEIEPgRABD4EMgQ9BDAxGzAZBgNVBAQeEgQdBDUEOgRABDAEQQQ+BDIEMDBjMBwGBiqFAwICEzASBgcqhQMCAiQABgcqhQMCAh4BA0MABEDpwCRbun1+7+wyEbRRUfJCd6SAIF1aT70lPEaaF8LIOTAIYNd4/63E59q8BX+z3gcNDRWE9/2tMhiUSscPLBFYo4IEcjCCBG4wDgYDVR0PAQH/BAQDAgTwMCYGA1UdJQQfMB0GCCsGAQUFBwMEBgcqhQMCAiIGBggrBgEFBQcDAjAdBgNVHQ4EFgQUpYuTVmiVocyz5HtZTgcyM2SMozEwggFCBgNVHSMEggE5MIIBNYAU8VKRPyZDN4xcQHwiTjYXgz2iczmhggEJpIIBBTCCAQExGjAYBggqhQMDgQMBARIMMDA3MTA3MDY1MDgxMRgwFgYFKoUDZAESDTEwMjcxMDA5NzExODIxJjAkBgNVBAkMHdC/0YAt0LrRgiDQm9C10L3QuNC90LAg0LQuIDQ2MSkwJwYDVQQKDCDQntCe0J4gItCT0LLQsNGA0LQt0JjQvdGE0L7RgNC8IjERMA8GA1UEBwwI0KLRg9C70LAxKzApBgNVBAgMIjcxINCi0YPQu9GM0YHQutCw0Y8g0L7QsdC70LDRgdGC0YwxCzAJBgNVBAYTAlJVMSkwJwYDVQQDDCDQntCe0J4gItCT0LLQsNGA0LQt0JjQvdGE0L7RgNC8IoIQIbMoTYas9YdI7rX6F0aXmzCBoQYDVR0fBIGZMIGWMEmgR6BFhkNodHRwOi8vcWNhLmdpbmYucnUvY2RwL2YxNTI5MTNmMjY0MzM3OGM1YzQwN2MyMjRlMzYxNzgzM2RhMjczMzkuY3JsMEmgR6BFhkNodHRwOi8vZ2luZi1xY2EucnUvY2RwL2YxNTI5MTNmMjY0MzM3OGM1YzQwN2MyMjRlMzYxNzgzM2RhMjczMzkuY3JsMIG4BggrBgEFBQcBAQSBqzCBqDBSBggrBgEFBQcwAoZGaHR0cDovL3FjYS5naW5mLnJ1L2NhY2VydC9mMTUyOTEzZjI2NDMzNzhjNWM0MDdjMjI0ZTM2MTc4MzNkYTI3MzM5LmNlcjBSBggrBgEFBQcwAoZGaHR0cDovL2dpbmYtcWNhLnJ1L2NhY2VydC9mMTUyOTEzZjI2NDMzNzhjNWM0MDdjMjI0ZTM2MTc4MzNkYTI3MzM5LmNlcjArBgNVHRAEJDAigA8yMDE0MDgxNDA3NDkwMFqBDzIwMTUwODE0MDc0OTAwWjAdBgNVHSAEFjAUMAgGBiqFA2RxATAIBgYqhQNkcQIwNgYFKoUDZG8ELQwrItCa0YDQuNC/0YLQvtCf0YDQviBDU1AiICjQstC10YDRgdC40Y8gMy42KTCB6wYFKoUDZHAEgeEwgd4MKyLQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIiAo0LLQtdGA0YHQuNGPIDMuNikMUyLQo9C00L7RgdGC0L7QstC10YDRj9GO0YnQuNC5INGG0LXQvdGC0YAgItCa0YDQuNC/0YLQvtCf0YDQviDQo9CmIiDQstC10YDRgdC40LggMS41DC3QodCkLzExNC0yMjM4INC+0YIgMDQg0L7QutGC0Y/QsdGA0Y8gMjAxMyDQsy4MK9Ch0KQvMTI4LTIzNTEg0L7RgiAxNSDQsNC/0YDQtdC70Y8gMjAxNCDQsy4wCAYGKoUDAgIDA0EAfkY9xtbGWdttIfxLVXaJsI1N8/VKEynoOAj52lgsSxU95cYD0KmfAVqhgP2KhdHTXwkNcs7YWBkkAspn0sKQ5A==</wsse:BinarySecurityToken>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="body">
<v25:pushEventRequest>
<smev:Message>
<smev:Sender>
<smev:Code>SOCP01711</smev:Code>
<smev:Name>СОЦИНФОРМТЕХ</smev:Name>
</smev:Sender>
<smev:Recipient>
<smev:Code>01TV01141</smev:Code>
<smev:Name>МФЦ РС(Я)</smev:Name>
</smev:Recipient>
<smev:Originator>
<smev:Code>01TV01141</smev:Code>
<smev:Name>МФЦ РС(Я)</smev:Name>
</smev:Originator>
<smev:TypeCode>GSRV</smev:TypeCode>
<smev:Status>RESULT</smev:Status>
<smev:Date>2015-05-25T14:26:23.669+03:00</smev:Date>
<smev:ExchangeType>1</smev:ExchangeType>
<smev:RequestIdRef>MyID_0df6723e-8a8c-440d-bcec-73f8f94edc95</smev:RequestIdRef>
<smev:OriginRequestIdRef>MyID_0df6723e-8a8c-440d-bcec-73f8f94edc95</smev:OriginRequestIdRef>
<smev:ServiceCode>123456789</smev:ServiceCode>
<smev:CaseNumber>1030</smev:CaseNumber>
</smev:Message>
<smev:MessageData>
<smev:AppData>
<orderId>1030</orderId>
<eventComment>Уважаемый заявитель! Ваше заявление было рассмотрено, в назначении выплаты Вам отказано, т.к. Вы не приложили свидельство о рождении ребенка. Зарегистрируйте новое заявление на РПГУ и приложите документы: ...., .....
</eventComment>
<eventAuthor></eventAuthor>
<event>
<orderStatusEvent>
<statusCode>
<techCode>4</techCode>
</statusCode>
</orderStatusEvent>
</event>
</smev:AppData>
</smev:MessageData>
</v25:pushEventRequest>
</soap:Body>
</soap:Envelope>
При проверке сервисом http://smev.gosuslugi.ru/portal/services-tools.jsp - всё ОК. При проверке подписи с помощью инфраструктуры WCF, получаем ошибку: Код:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<s:Fault>
<faultcode xmlns:a="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">a:InvalidSecurity</faultcode>
<faultstring xml:lang="ru-RU">An error occurred when verifying security for the message.</faultstring>
</s:Fault>
</s:Body>
</s:Envelope>
Посмотрел исключение глубже: Код:
Cannot resolve KeyInfo for verifying signature: KeyInfo 'SecurityKeyIdentifier
(
IsReadOnly = False,
Count = 1,
Clause[0] = LocalIdKeyIdentifierClause(LocalId = 'SenderCertificate', Owner = '')
)
', available tokens 'SecurityTokenResolver
(
TokenCount = 0,
)
'.
Конечно же лучше решить эту проблему. Но я понять не могу, что не так. Я написал код, проверяющий подпись, и вроде подпись нормальная. Как проверяет подпись инфраструктура WCF я так и не понял, хотя рассмотрел много расширений. Как вариант - временно отключить проверку подписи. Но как я опять не понял :(
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.04.2015(UTC) Сообщений: 6  Сказал(а) «Спасибо»: 2 раз
|
Всем добрый день! Сейчас пишу уже второй смэв-сервис и столкнулся со следующей проблемой: Сервис должен принимать от клиента изображение размером около 400-600 килобайт в формате base64 string. При тестировании, с очень маленькими изображениями (около 2-3 кб) сервис работает, а на 15 кб+ выдает исключение: Закодированный ASN.1 массив байтов содержит неизвестную структуру GostR3410_KeyTransport. ASN.1 Decode error @ offset 0: Tag match failed: expected [UNIVERSAL 16], parsed [2]Также иногда выдает что-то типа ASN.1 Length value exception. Сам exception вылезает в CryptoPro.Sharpei.Base т.е. как я понимаю, он просто не может осилить такой объем информации и закодировать его. P.S. Я пробовал увеличивать максимальный размер сообщения следующий образом: Код:basicBinding.MaxReceivedMessageSize = 1048576;
basicBinding.MaxBufferSize = 1048576;
basicBinding.MaxBufferPoolSize = 1048576;
Но это не помогло.
|
|
|
|
|
|
Статус: Активный участник
Группы: Администраторы, Участники Зарегистрирован: 28.04.2010(UTC) Сообщений: 140  Откуда: Крипто-Про Поблагодарили: 15 раз в 14 постах
|
Здравствуйте, Попробуйте также изменить ограничения ридера сообщения: Ex.: Цитата: var quotas = bnd.ReaderQuotas; quotas.MaxArrayLength = quotas.MaxBytesPerRead = quotas.MaxStringContentLength = quotas.MaxNameTableCharCount = quotas.MaxDepth = (int)Constants.MaxFileSize;
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.04.2015(UTC) Сообщений: 6  Сказал(а) «Спасибо»: 2 раз
|
Автор: khomenko  Здравствуйте, Попробуйте также изменить ограничения ридера сообщения: Ex.: Цитата: var quotas = bnd.ReaderQuotas; quotas.MaxArrayLength = quotas.MaxBytesPerRead = quotas.MaxStringContentLength = quotas.MaxNameTableCharCount = quotas.MaxDepth = (int)Constants.MaxFileSize;
Добрый день, я пробовал так делать Код:basicBinding.ReaderQuotas.MaxArrayLength = 2147483647;
basicBinding.ReaderQuotas.MaxStringContentLength = 2147483647;
basicBinding.ReaderQuotas.MaxDepth = 2147483647;
basicBinding.ReaderQuotas.MaxNameTableCharCount = 2147483647;
basicBinding.ReaderQuotas.MaxBytesPerRead = 2147483647;
Но мне это не помогло (выставлял в коде сервиса и клиента, там где создается Binding для Factory), возможно я что-то не так делаю.
|
|
|
|
|
|
Статус: Активный участник
Группы: Администраторы, Участники Зарегистрирован: 28.04.2010(UTC) Сообщений: 140  Откуда: Крипто-Про Поблагодарили: 15 раз в 14 постах
|
Квоты не совсем там задаются :) Вы же заменяете оригинальный Encoder на SmevEncoder. Поэтому не хватает строчки (выделено жирным): Цитата: System.Xml.XmlDictionaryReaderQuotas quotas = basicBinding.ReaderQuotas; quotas.MaxArrayLength = quotas.MaxBytesPerRead = quotas.MaxStringContentLength = quotas.MaxNameTableCharCount = quotas.MaxDepth = (int)int.MaxValue;
/// Настраиваем привязку. Подменяем кодировщик на собственный, /// настраиваем SecurityBindingElement CustomBinding binding = new CustomBinding(basicBinding); SMEVMessageEncodingBindingElement textBindingElement = new SMEVMessageEncodingBindingElement() { MessageVersion = MessageVersion.CreateVersion(EnvelopeVersion.Soap11, AddressingVersion.None), };
(textBindingElement.InnerMessageEncodingBindingElement as TextMessageEncodingBindingElement).ReaderQuotas = quotas;
binding.Elements.Remove<TextMessageEncodingBindingElement>(); binding.Elements.Insert(0, textBindingElement); /// Не включаем метку времени в заголовок Security binding.Elements.Find<AsymmetricSecurityBindingElement>().IncludeTimestamp = false; /// Говорим WCF, что в сообщении от СМЭВ не нужно искать метку времени и nonce. binding.Elements.Find<AsymmetricSecurityBindingElement>().LocalClientSettings.DetectReplays = false;
return binding;
|
 1 пользователь поблагодарил Михаил Хоменко за этот пост.
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.04.2015(UTC) Сообщений: 6  Сказал(а) «Спасибо»: 2 раз
|
Автор: khomenko  Квоты не совсем там задаются :)
Вы же заменяете оригинальный Encoder на SmevEncoder.
Поэтому не хватает строчки (выделено жирным):
Странно, я думал что при наследовании от basicBinding значения этих свойств передаются и даже проверял деббагером, так и было. Спасибо большое! Данная ошибка исчезла, появилась другая - The request failed with HTTP status 413которая исправляется просто следующей строчкой (выделено жирным): Цитата:/// Создаём болванку привязки BasicHttpBinding basicBinding = new BasicHttpBinding(); basicBinding.Security.Mode = BasicHttpSecurityMode.Message; basicBinding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate; basicBinding.Security.Message.AlgorithmSuite = GostAlgorithmSuite.BasicGostObsolete; basicBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None; basicBinding.MaxReceivedMessageSize = int.MaxValue; В этом случае значение свойства MaxReceivedMessageSize успешно наследуется от basicBinding. После чего "большие" запросы успешно проходят. Единственное, что меня смущает - безопасность. Как я понимаю, выставления этих параметров за стандартные рамки приводят к опасности DoS атаки на сервис? Если да, то есть ли в WCF какие-то другие инструменты/способы обезопасить себя? P.S. Хотя насчет DoS я погорячился, учитывая что сервис публикуется в СМЭВ :) Отредактировано пользователем 4 августа 2015 г. 8:02:46(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Администраторы, Участники Зарегистрирован: 28.04.2010(UTC) Сообщений: 140  Откуда: Крипто-Про Поблагодарили: 15 раз в 14 постах
|
Ограничения естественно не нужно откручивать в максимальные значения. Подобрать лимиты под ваши сообщения - в этом нет ничего страшного.
Ограничения по умолчанию достаточно скромные и не предназначены для передачи бинарных данных или xml документов со страшным уровнем вложенности.
|
|
|
|
|
|
Статус:: Участник
Группы: Участники
Зарегистрирован: 13.11.2015(UTC) Сообщений: 20  Сказал(а) «Спасибо»: 14 раз
|
Здравствуйте. Разрабатываю ПО для администрации города. В администрации есть служащий, у которого есть ЭП. Необходимо посылать запрос через СМЭВ к Росреестру на получение кадастровой выписки объекта недвижимости. Смотрел xml-файл запроса к росреестру, там необходимы паспортные данные. Вопрос зачем, если есть ЭП? Чьи паспотрные данные необходимо вписать, служащего чьей ЭП подписываем документ?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close