что такое смэв и как к ней подключиться
Вопросы
Часто задаваемые вопросы
Как пользоваться новой версией Портала СЦ?
Инструкция пользователя по работе в личном кабинете Портала ФГИС СЦ доступно в разделе «Документы» по ссылке.
Инструкция по обеспечению доступа в личный кабинет Портала ФГИС СЦ доступна в разделе «Документы» по ссылке.
Как подключиться к СМЭВ?
В соответствии с Регламентом СМЭВ 2.х и Регламентом СМЭВ 3.х к СМЭВ могут быть подключены только следующие категории Участников: ОИВ, ОМСУ, УЦ, ЗАГС, МФЦ, БКИ, Кредитные организации, Брокеры, Управляющие, Депозитарии, Управляющие компаний специализированных обществ, ПА, БПА. С критериями определения Участников можно ознакомиться в документе, опубликованном на Технологическом портале СМЭВ: http://smev.gosuslugi.ru/portal/api/files/get/194774.
Для подключения к СМЭВ необходимо направить заявку на присоединение к Регламенту СМЭВ. Оригинал заявки направляется в Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации (125375, г. Москва, ул. Тверская, д. 7) с сопроводительным письмом на бланке организации. Дополнительно посредством личного кабинета Ситуационного центра необходимо создать запрос на подключение к СМЭВ приложив скан-копию направленной заявки на присоединение.
Территориальные органы/структурные подразделения не являются Участниками взаимодействия. Взаимодействие со СМЭВ структурных подразделений осуществляется через головную организацию. Взаимодействие внутри организации производится по внутренним каналам Участника взаимодействия.
В соответствии с п. 5.1 Регламента СМЭВ 2.х и п. 9.1 Регламента СМЭВ 3.х:
Дополнительно напоминаем о том, что основным способом направления обращения является личный кабинет ситуационного центра. Для входа необходимо перейти на сайт: https://sc.minsvyaz.ru и нажать «Войти». На открывшейся форме авторизации в ЕСИА, ввести свой телефон (СНИЛС, e-mail) и пароль и, войдя в личный кабинет ЕСИА, на странице «Выбор роли» нажать на строку с названием Вашей организации.
Электронная почта является резервным способом направления обращения, который используется в случае недоступности https://sc.minsvyaz.ru.
Как правильно оформить заявку на доступ к электронному сервису?
Один из этапов получения доступа к электронному сервису Поставщика в СМЭВ является оформление заявки на предоставление доступа к электронному сервису (Актуальную форму заявки можно найти на http://smev.gosuslugi.ru/portal/). Заявка должна включать сведения:
3. Наименование Поставщика информации в СМЭВ – Поставщика электронного сервиса, к сервису которого запрашивается доступ;
4. Реквизиты нормативных правовых актов, с указанием конкретных пунктов (частей, статей), подтверждающих основание получения доступа к электронному сервису (федеральные законы, постановления Правительства Российской Федерации, приказы Участника информационного взаимодействия об утверждении административных регламентов, соглашения об информационном обмене, иные правовые акты, предусматривающие информационное взаимодействие);
5. Наименование электронного сервиса с указанием идентификатора сервиса в СМЭВ (SID….);
6. Таблицу с указанным уровнем доступа к электронному сервису (полный уровень доступа ко всем операциям электронного сервиса или доступ к конкретным операциям электронного сервиса, перечисленным в таблице);
7. Подпись уполномоченного лица Потребителя, заверенную соответствующей гербовой печатью.
Как подключить к СМЭВ информационную систему?
Для подключения к СМЭВ информационной системы, участвующей в предоставлении государственных услуг или исполнении государственных функций, Участнику информационного взаимодействия необходимо:
1. Получить средства технологической электронной подписи для каждой информационной системы, обратившись в любой удостоверяющий центр, входящий в Единое пространство доверия. Перечень удостоверяющих центров доступен по адресу http://e-trust.gosuslugi.ru/CA;
2. Направить Оператору СМЭВ запрос на подключение информационных систем с приложением Формы предоставления информации об информационной системе и сертификата ключа электронной подписи информационной системы в формате BASE 64;
3. После получения уведомления от Оператора СМЭВ о подключении информационной системы к СМЭВ, протестировать успешность подключения совместно с Оператором СМЭВ;
— проверить наличие сетевой связности между площадками Участника взаимодействия и ядром СМЭВ;
— проверить взаимодействие каждой информационной системы с помощью cервисов проверки взаимодействия;
4. При отрицательных результатах тестирования провести мероприятия по устранению выявленных недостатков совместно с Оператором СМЭВ.
Мнемоника ИС Участника информационного взаимодействия будет предоставлена Оператором СМЭВ после регистрации информационной системы. Заявка на подключение может поступить только от Участника взаимодействия (ОИВ, ОМСУ, КО, УЦ, ЗАГС, МФЦ, БКИ, Брокеры, Управляющие, Депозитарии, Управляющие компаний специализированных обществ, Верховный суд РФ, Торгово-промышленная палата РФ, Госкорпорация Роскосмос, ПА, БПА ), территориальные органы не являются Участниками взаимодействия, к СМЭВ не подключаются. Взаимодействие внутри ОИВ производится по внутренним каналам Участника взаимодействия.
Где взять информацию о Видах сведений, находящихся в эксплуатации и готовящихся к вводу в эксплуатацию?
Информация о зарегистрированных ВС публикуется на главной странице Техпортала СМЭВ 3 и в разделе «Новости» Техпортала СМЭВ 3.
Единая система межведомственного электронного взаимодействия (СМЭВ)
Реализация взаимодействия информационных систем организаций и ведомств осуществляется в рамках государственной целевой программы «Информационное общество (2011-2020 годы)».
Взаимодействие реализуется в рамках:
системы межведомственного электронного документооборота (МЭДО).
единой системы межведомственного электронного взаимодействия (СМЭВ).
Что такое СМЭВ и для чего она нужна?
Участниками межведомственного электронного взаимодействия (участниками СМЭВ) являются федеральные органы исполнительной власти, государственные внебюджетных фонды, исполнительные органы государственной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры, иные органы и организации.
Целью создания СМЭВ является повышение качества предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций за счет использования общих информационных ресурсов, уменьшения времени на поиск и обработку информации в электронной форме.
СМЭВ предназначена для решения следующих задач:
обеспечение исполнения государственных и муниципальных функций в электронной форме;
обеспечение предоставления государственных и муниципальных услуг в электронной форме, в том числе с использованием универсальной электронной карты и единого портала 2 ;
обеспечение информационного взаимодействия в электронной форме при предоставлении государственных и муниципальных услуг и исполнении государственных и муниципальных функций.
Основные функции СМЭВ
Основными функциями СМЭВ являются:
передача запросов, документов и сведений, необходимых для получения государственных и муниципальных услуг и поданных заявителями через единый портал, в подключенные к СМЭВ информационные системы;
обмен электронными сообщениями между участниками СМЭВ;
передача на единый портал запросов, иных документов и сведений, обработанных в информационных системах, а также информации о ходе выполнения запросов и результатах предоставления услуг.
В целях исполнения своих функций СМЭВ обеспечивает:
доступ к электронным сервисам 3 информационных систем, подключенных к СМЭВ;
возможность использования централизованных баз данных и классификаторов информационными системами, подключенными к СМЭВ;
получение, обработку и доставку электронных сообщений в рамках информационного взаимодействия участников СМЭВ, обеспечение фиксирования времени их передачи, целостности и подлинности, указания их авторства и возможности предоставления сведений, позволяющих проследить историю движения электронных сообщений;
защиту передаваемой информации от несанкционированного доступа, искажения или блокирования с момента поступления указанной информации в СМЭВ до момента передачи ее в подключенную к СМЭВ информационную систему;
ведение реестра электронных сервисов информационных систем, подключенных к СМЭВ.
Технологическое обеспечение СМЭВ
Технологическое обеспечение информационного взаимодействия с применением СМЭВ достигается путем использования:
сервис-ориентированной архитектуры, представляющей собой совокупность электронных сервисов, построенных по общепринятым стандартам;
единых технологических решений и стандартов, единых классификаторов и описаний структур данных.
Как стать участником СМЭВ?
Интеграция информационных систем в рамках СМЭВ осуществляется в соответствии с Техническими требованиями к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия (утв. приказом Минкомсвязь России от 27.12.2010 № 190).
Чтобы стать участником СМЭВ органу или организации, предоставляющей государственные и муниципальные услуги и исполняющей государственные и муниципальные функции, необходимо:
Обеспечить разработку электронных сервисов и интерфейсов взаимодействия используемой информационной системы и СМЭВ.
Для этого нужно обратиться к поставщику или разработчику используемой информационной системы для выполнения им работ по реализации необходимых сервисов и интерфейсов.
Обеспечить наличие защищенного канала связи между используемой информационной системой и СМЭВ.
АИС МФЦ ДЕЛО
АИС МФЦ ДЕЛО — решение для автоматизации деятельности многофункциональных центров предоставления государственных и муниципальных услуг (МФЦ). Основная цель внедрения АИС МФЦ – повышение качества работы МФЦ. Это достигается путем взаимодействия со СМЭВ, РСМЭВ, УЭК, ИАС МКГУ, ГИС ГМП, Центром Телефонного Обслуживания, а также с федеральной государственной информационной системой «ЕСИА»:
Справочная информация: Перечень наиболее важных документов по организации информационного взаимодействия органов государственной власти в рамках СМЭВ:
Распоряжение Правительства РФ от 17.12.2009 № 1993-р «Об утверждении сводного перечня первоочередных государственных и муниципальных услуг, предоставляемых в электронном виде».
Постановление Правительства РФ от 08.09.2010 № 697 «О единой системе межведомственного электронного взаимодействия».
Приказ Министерства связи и массовых коммуникаций РФ от 27.12.2010 № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия».
Постановление Правительства РФ от 08.06.2011 № 451 «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме».
Постановление Правительства РФ от 28.12.2011 № 1184 «О мерах по обеспечению перехода федеральных органов исполнительной власти и органов государственных внебюджетных фондов на межведомственное информационное взаимодействие в электронном виде».
Постановление Правительства РФ от 22.12.2012 № 1382 «О присоединении информационных систем организаций к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме».
Распоряжение Правительства РФ от 25.12.2013 № 2516-р «Об утверждении Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде».
Распоряжение Правительства РФ от 09.06.2014 № 991-р «Об утверждении плана мероприятий («дорожной карты») по реализации Концепции развития механизмов предоставления государственных и муниципальных услуг в электронном виде, утв. распоряжением Правительства РФ от 25.12.2013 № 2516-р».
Приказ Министерства связи и массовых коммуникаций РФ от 01.07.2014 № 184 «О реализации положений постановления Правительства Российской Федерации от 19 марта 2014 г. № 208 «О внесении изменений в положение о единой системе межведомственного электронного взаимодействия».
Постановление Правительства РФ от 19.11.2014 № 1222 «О дальнейшем развитии единой системы межведомственного электронного взаимодействия».
1. В соответствии с Положением о единой системе межведомственного электронного взаимодействия (утв. постановлением Правительства РФ от 08.09.2010 № 697).
2. Федеральная государственная информационная система «Единый портал государственных и муниципальных услуг (функций)».
3. Программные и технические средства, обеспечивающие возможность доступа к информационным системам через СМЭВ.
4. В соответствии с Положением о единой системе межведомственного электронного взаимодействия.
Как оператору связи подключиться к СМЭВ
В материале рассматриваются особенности подключения операторов связи к СМЭВ: нормативно-правовые основания, преимущества СМЭВ в качестве источника данных, оптимальные виды сведений (сервисы) для интеграции, алгоритм подключения, открытые вопросы по методике проведения проверки.
Зачем оператору связи СМЭВ
C 1 июня 2018 года вступили в силу поправки в Федеральный закон «О связи», в соответствии с которыми операторы обязаны проверять достоверность сведений об абонентах (п. 6 ст. 44 ФЗ). При этом под абонентом понимаются:
Перечень проверяемых данных является открытым – в соответствии с требованиями закона в него входят ФИО, дата рождения, а также другие данные документа, удостоверяющего личность абонента или пользователя услугами связи. Логично предположить, что к «другим данным» относятся серия и номер паспорта, дата выдачи, наименование выдавшего органа, информация о прописке, а также статус паспорта (действующий/не действующий).
Проверку требуется проводить как для новых, так и для существующих абонентов и пользователей. Для этого оператору предлагается использовать один из способов:
Также были внесены изменения в соответствующие документы, регламентирующие вопросы доступа организаций к данным ЕСИА, ЕПГУ и СМЭВ. Например, в соответствии с п.23 подраздела 6.1. раздела 6 «Общий порядок предоставления Участникам доступа к СМЭВ» Приложения 3 «Правила и процедуры работы в СМЭВ по Методическим рекомендациям версии 3.Х» Регламента обеспечения предоставления государственных услуг и исполнения государственных функций в электронном виде в число участников СМЭВ включены операторы подвижной радиотелефонной связи.
Далее в статье будут рассмотрены особенности и преимущества использования операторами СМЭВ для проверки абонентов и пользователей услуг связи.
В каких случаях целесообразно использовать дистанционную проверку
Наиболее простым и очевидным способом проверки является предоставление документа, удостоверяющего личность. Однако, существует ряд ситуаций, в которых его применение невозможно:
Во всех указанных случаях наиболее эффективным будет сопоставление данных абонентов и пользователей с информацией, содержащейся в базах данных – то есть дистанционная проверка.
Преимущества СМЭВ над другими инструментами дистанционной проверки
В ФЗ «О связи» предлагаются несколько инструментов дистанционной проверки данных абонента: усиленная КЭП, ЕСИА, ЕПГУ и СМЭВ.
Усиленная квалифицированная подпись – самый сомнительный инструмент. КЭП есть далеко не у всех граждан. Механизм проверки выстроить достаточно сложно. Кроме того, существует много спорных моментов – например, какие удостоверяющие центры считать валидными.
ЕСИА (единая система идентификации и аутентификации) и ЕПГУ (единый портал госуслуг) представляют собой единый инструмент. Для того чтобы пользователь мог получать услуги на ЕПГУ ему требуется учетная запись в ЕСИА. Таким образом, данные в ЕСИА и ЕПГУ дублируются.
По сравнению со СМЭВ у ЕСИА есть ряд существенных ограничений:
Какие виды сведений СМЭВ требуются оператору
Для того чтобы получать информацию из СМЭВ необходимо подключиться к отдельным сервисам (видам сведений) системы. Каждый сервис предоставляет свой набор данных.
Алгоритм подключения видам сведений СМЭВ
Для получения доступа к видам сведений СМЭВ оператору связи необходимо выполнить следующие действия:
Вопросы по процессу проверки абонентов
В ФЗ «О связи» и других нормативных документах не содержится требований к процедуре проведения проверки абонента и потребителя услуг. В результате возникает множество вопросов организационного характера:
Интеграция с «Госуслугами». Место СМЭВ в общей картине (часть I)
В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.
Общая схема взаимодействия через СМЭВ
Участники взаимодействия
Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.
Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).
Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.
Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.
Виды сведений
Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.
Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.
На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.
Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.
Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:
Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:
На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.
Обмен по универсальному виду сведений можно представить так:
На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:
Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.
Очереди сообщений и процесс взаимодействия
В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.
Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.
Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.
На каждый запрос может поступить как успешный, так и неуспешный ответ.
Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:
Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.
На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.
Постановка задачи
С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.
Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.
В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.
СМЭВ 3. Электронная подпись сообщений на Java и КриптоПро
Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.
В настоящее время СМЭВ продолжает расширять свои возможности и вовлекать все большее количество участников взаимодействия.
Что оказалось как нельзя кстати, в том числе для коммерческих организаций, в частности банков, которые все больше стремятся перевести свои услуги в цифру и сериализовать процессы.
В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.
Здравствуйте!
Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где
По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.
Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.
В то же время заглянуть в открытый код клиента всегда полезно, а его наличие само по себе говорит о зрелости системы и высоком уровне поддержки.
Анализ исходных данных
Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.
Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 3.
Каноникализация — процесс приведения данных, имеющих несколько возможных форм представления, к одному нормализованному стандартному виду.
Перед тем как посчитать хэш подписываемого атрибута в XML-конверте и подписать, необходимо выполнить его конвертацию в заданный правилами СМЭВ 3 вид.
В поисках описания трансформации urn://smev-gov-ru/xmldsig/transform открываем Методические рекомендации 3.4.0.3
Знакомимся с пунктом 4.4.2.1 Правила формирования электронной подписи сообщений
Формат подписи XMLDSig detached (https://www.w3.org/TR/xmldsig-core/)
Трансформация, дополнительно к канонизации urn://smev-gov-ru/xmldsig/transform
Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.
Пункт Методических указаний 12.4. ПРИЛОЖЕНИЕ 4: ОБРАЗЦОВАЯ РЕАЛИЗАЦИЯ ТРАНСФОРМАЦИИ URN://SMEV-GOV-RU/XMLDSIG/TRANSFORM
содержит Java класс SmevTransformSpi.java, реализующий алгоритм трансформации «urn://smev-gov-ru/xmldsig/transform», наследник org.apache.xml.security.transforms.TransformSpi из библиотеки Apache Santuario.
Таким образом, чтобы обеспечить каноникализацию подписываемого конверта СМЭВ 3, можно использовать в своем коде этот класс трансформации.
Единственным условием и ограничением в этом случае будет, что для обработки XML-документа при формировании подписи или ее проверки нужно использовать именно org.apache.xml.security.signature.XMLSignature из проекта Apache Santuario.
Задействовать инструменты из пакетов javax.xml.crypto.dsig или ru.CryptoPro.JCPxml.xmldsig просто так уже не получится.
Подготовка к подписи по правилам СМЭВ 3
Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.
В библиотеке xmlsec-1.5.0.jar в файле \org\apache\xml\security\resource\config.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.
Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.
По старинке это делалось так:
В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:
Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:
Заодно сразу выполняем требование из Методических указаний:
Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.
Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.
Просто через настройку системного свойства:
Через настройку опции JVM:
Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».
Такая реализация приводит к невозможности гибко настроить в одном Java процессе для части методов игнорировать перевод строк, а для другой части не игнорировать.
Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.
С этим свойством, конечно, возникает вопрос к Apache Santuario:
Подпись сообщений СМЭВ 3
Для подписи документов СМЭВ 3 все готово.
Код подписания выглядит следующим образом:
Основными параметрами здесь являются:
Проверка подписи сообщения СМЭВ 3
Код проверки подписи выглядит следующим образом:
Проблемы. Хэш не совпадает
Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.
Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как
ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП
не совпадал с оригинальным примером:
Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.
для параллельного анализа всех этапов трансформации.
Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:
Поиск решения показал, что, во-первых форум КриптоПро, нормализованный документ может выглядеть на самом деле иначе и соответственно его хэш будет другой и возможно правильный.
Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.
Старая версия класса трансформации выдала следующий нормализованный документ:
С ним хэш стал совпадать, а подпись успешно проходить валидацию.
Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:
Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:
, которая удаляет первый объект из стека с префиксами
, что приводило к неверной работе SmevTransformSpi.
Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.
Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3
Результаты
Подписание конвертов СМЭВ 3 выполняется успешно.
Сообщения проходят проверку на портале Электронного правительства Госуслуги