Автор: gosha207778 Всем привет!
Недавно столкнулся с проблемой подписи и трансформации сообщений для отправки их в СМЭВ3.
Для интеграции со смэв было принято решение использовать официальный адаптер смэв3 на java. В будущем мы планировали написать свою имплементацию этого адаптера.
Однако в процессе его настройки выяснилось что он работает не стабильно и с ним возникли трудности. Совершенно непонятно как он работает и какие сообщения отправляет. В результате чего я начал рассматривать варианты написание собственного модуля для интеграции со смэв.
Для меня остается не ясным как необходимо трансформировать сообщения для отправки в смэв и как их подписывать.
Было бы здорово получить такую функцию
string Smev3Request = TransformXmlToSmev3Message(inputXmlString, Sertificate ...)
где в качестве входных данных можно было бы подать сообщение вида:
https://smev3.gosuslugi....p;page=1&dTest=falseнапример отсюда. ну или то сообщение которое подается на вход в адаптер к смэв3. Но я не нашел тут таких ответов (или я что то не понимаю).
Привет! Не совсем понял что и во что собираетесь трансформировать. В паспортах сервисов как правило лежит часть сообщения, содержащая "бизнес-данные", отличающиеся для разных видов сведений. Предположу, что под транформацией Вы понимаете обертку "бизнес-данных" в общий для всех "конверт" СМЭВ 3?
Еще есть smev-transform для ЭП, не хотелось бы спутать терминологии.
Автор: gosha207778 Почему бы не собраться всем и не запилить open source проект на эту тему?
Идея здравая, я целиком "за". Собственно именно это и хочу сделать. При реализации правда начинаются проблемы разного плана: 1) полной реализации пока я не встречал ни в одном опубликованном коде ПО, все городят "костыли", которые работают только с конкретным сервисом. У меня тоже не реализованы множество пунктов стандарта, но сервис для которого пишу это устраивает, потому что в xml для этого конкретного сервиса эти пункты срабатывают впустую и ничего не меняют в сообщении. Соответственно общий проект должен будет учитывать все сервисы (а их протестировать ВСЕ немного проблематично). Иначе всё сведется к тому что все взяли сырой проект и приделали свои костыли (как сейчас с адаптером); 2) программисты крайне неохотно переходят на другой язык (другую среду) программирования, поэтому Важно чтобы проект имел порты под все популярные среды программирования; 3) если проект будет включать подписание ЭП, то к сожалению open source проекты не подходят, так как подписание должно быть выполнено сертифицированным средством криптографической защиты (СКЗИ) или должен быть проведен контроль встраивания сертифицированного СКЗИ.
Поэтому подписывать через openssl возможно только если эта конкретная сборка бинарников openssl сертифицирована как отдельный криптопровайдер. Стоят такие сборки не особо меньше чем КриптоПро. При этом у абсолютного большинства российских организаций есть хотя бы одна лицензия КриптоПро (бюджетным организациям выдают одну лицензию "напрокат" в Федеральном казначействе бесплатно), поэтому идея уйти в openssl не очень перспективная. Кроме того, есть бесплатный конкурент КриптоПро, openssl имеет шансы только под *nix, но не под Windows.
Более того, если одна организация предоставляет такое ПО своего авторства для другой организации то у первой организации должна быть лицензия на такой вид услуг, утвержден регламент, проводится проверки ФСБ. В то же время если ПО пишется организацией для собственных нужд, то лицензия и проверки отпадают. Поэтому все будут скачивать проект, компилировать и выдавать за свою наработку.
Автор: gosha207778 Также мне удалось подписывать документы XML с помощью OpenSSL. То есть преобразовать PFX сертификат КриптоПро в сертификаты OpenSSL что позволит избавиться от КриптоПро и перейти на OpenSSL, а следовательно и на .NET Core/python и докерезировать сервис ну или использовать крипто про...
С сертификатом никаких проблем нет, проблема с ключами.
Насколько мне известно OpenSSL не понимает кодировку ключа, экспортируемую из КриптоПро. Если у Вас получилось Вы наверно или пробовали на контейнере с ключои гост-2001 старой версии КриптоПро или сняли пин-код с контейнера или взяли модифицированную версию openssl (из коробки базовая openssl гост-2012 не умеет). В любом случае, несертифицированная версия openssl и хранение ключа в открытом виде противоречат требованиям законодательства. Сами использовать на свой страх и риск можете, но заказчику лучше и не пытайтесь предложить. Поэтому непонятно стремление перейти на openssl. Для себя я тоже сначала думал как круто иметь альтернативу криптоядра в виде openssl. Но потом openssl выкинули поддержку гост во внешний модуль и это уже совсем другая ситуация, мой приоритет поддержки openssl упал почти до нуля. Для .NET Core также работа ведется, через пару лет думаю и там можно будет без костылей с openssl и нарушений законодательства. Под python аналогично - уже вроде что-то работает.
Автор: gosha207778 Конечно извиняюсь, не смотрел по ссылке, но что там еще нужно кроме адаптера? Бизнес-данные все равно придется формировать у каждой организации отдельно, так как у всех есть некое свое ПО работающее с зоопарком различных баз данных различных версий. Хотите пересадить всех на такой продукт? Заставить перебивать данные в новую базу данных. Увы, но это слишком оптимистично, большинство организаций мелкие, у них может даже не быть не то что программиста, но системный администратор приходит по 2 часа в неделю. Многие не станут брать open source продукт просто потому что не техподдержки, а имеющаяся техподдержка организации в таком продукте не разбирается. Максимум на что мы можем надеяться с проектом - заинтересовать неким "конструктором" множество junior/middle программистов, которые не хотят вникать в детали технологии ЭП или СМЭВ, но хотят прикрутить обмен со СМЭВ к своей не особо пряменькой программе. Выйдет тот же адаптер СМЭВ только другого авторства и "заваливающийся на другой бок".
Отредактировано пользователем 14 ноября 2019 г. 10:46:03(UTC)
| Причина: Не указана