Раздел 7.1. Требования к межведомственному взаимодействию информации при оказании государственных и муниципальных услуг

Внедрение СМЭВ — беспрецедентный интеграционный проект в России. Если раньше для получения услуги гражданам необходимо было обойти несколько учреждений и множество кабинетов, чтобы собрать все справки и документы, то сейчас все намного проще. За счет организации работы электронного правительства, получение любой услуги становится минутным делом. Все благодаря тому, что теперь существует система, в которой в автоматическом режиме происходит быстрый обмен информацией между независимыми ведомствами.

В этой статье рассказываем про устройство СМЭВ, как работает система и какие инструменты интеграции нужно использоваться, чтобы подключиться к сервису.

Основные определения и понятия

СМЭВ — система общегосударственного масштаба для быстрого поиска информации во всех инстанциях, подключенных к сервису. Цель внедрения системы межведомственного электронного взаимодействия — улучшить качество обслуживания населения в государственных учреждениях, упростить и ускорить обработку запросов, подключить отдельные ведомства к единой базе данных.

СМЭВ постоянно расширяется, так как все больше организаций присоединяются к системе. Благодаря системе обеспечивается доступ к электронным сервисам, быстро передаются данные об истории электронных сообщений во время оказания услуг.

Система упрощает и ускоряет обмен данными в электронном виде, а значит, гражданам не нужно часами простаивать в очереди, чтобы получить ответ на простой запрос. Благодаря СМЭВ реализуется принцип «единого окна». Человек обращается за услугой в одно из профильных ведомств, а специалисты собирают необходимые данные через систему межведомственного электронного взаимодействия. Никакой бумажной волокиты, потраченного времени и испорченных нервов.

Законодательная база

По закону № 210 муниципальные/федеральные/государственные органы, предоставляющие услуги населению, при обращении граждан не должны запрашивать у них дополнительные документы, которые можно получить через систему в других инстанциях.

Для исполнения этого закона и реализации принципа «одного окна» ведомства самостоятельно осуществляют взаимодействия через СМЭВ — инстанции могут быстро обменяться документами и всей информацией, которая может потребоваться при оказании услуг. Такой подход ускоряет удобен для обеих сторон — ускоряет и упрощает предоставление услуги, гарантирует конфиденциальность и сохранность данных.

Также межведомственное взаимодействие регламентируется постановлениями РФ № 697 и № 1222.

Функционал СМЭВ и обеспечение

Система межведомственного электронного взаимодействия обеспечивает мгновенный обмен электронными сообщениями и поддерживает передачу запросов, а также документов, обработанных в информационных системах.

• Требуется разработать электронные интерфейсы и сервисы, которые можно использовать при подключении к единой системы. Здесь есть два пути — можно обратиться к разработчику используемой инфосистемы, чтобы доработать сервисы и интерфейсы, а можно упростить задачу и использовать готовое решение. Об одном из таких продуктов расскажем далее в этой статье.
• Второе правило, которое нужно учесть, заключается в том, что оператору узла системы нужно будет предоставить доступ к электронному сервису для регистрации и внесения компании в реестр. Потребуется паспорт электронного сервиса. Также организация должна обеспечить доступность сервера, что необходимо для успешной приемки.
• Необходимо организовать защищенный канал связи между, по которому будет передаваться информация от инфосистемы организации в СМЭВ и обратно.

Для быстрого и эффективного подключения предлагаем использовать готовое решение от «КСК. Технологии». Дальше рассказываем о продукте и его преимуществах.

Интеграция СМЭВ

Интегрировать информационные системы в рамках СМЭВ необходимо в соответствии с техническими требованиями, утвержденными приказом № 190.

Чтобы организация могла стать членом СМЭВ, необходимо выполнить следующие шаги:

1. Оформить заявку на присоединение к регламенту, а также заявку на регистрацию.
2. Доработать собственную информационную систему. Возможно потребуется разработать электронные сервисы/интерфейсы для взаимодействия СМЭВ. В этом вопросе необходимо отталкиваться от требований оператора узла и следовать методическим рекомендациям.
3. Задействовать мероприятия для защищенности канал связи между используемой в организации системой и непосредственно СМЭВ. При подаче заявки важно проконтролировать доступность сервиса.
4. Подготовить типовое описание формата сервиса, отправить оператору узла паспорт электронного сервиса. Эти документы необходимы для инициирования процесса регистрации.
5. Получить разрешение на предоставление доступа к сервису.

Чтобы пройти процесс интеграции быстро и избежать типичных ошибок, рекомендуем использовать готовое решение для быстрого внедрения сервиса межведомственного электронного взаимодействия.

Узайте больше о возможностях КСК.Шлюз

Простое ваимодействие множества разнородных информационных систем

• Единый протокол интеграции
• Гарантированная доставка сообщений
• Более 1000 готовых адаптеров
• Мониторинг цепочек взаимодействия
• Совместимость с технологиями СМЭВ 2 и СМЭВ 3

Решение для интеграции

«КСК. Шлюз СМЭВ 3» — готовое решение для взаимодействия информационных систем клиента с единой системой межведомственного электронного взаимодействия. Продукт помогает реализовать такие задачи, как установка системы и подготовка пакета документов для регистрации в СМЭВ, установка видов сведений и вызовов видов сведений. Также Шлюз поддерживает интеграцию с ведомственными информационными системами и предоставляет алгоритм для обучения сотрудников.

Архитектура продукта состоит из таких элементов:

• Модули ядра, поддерживающие работу внутренних механизмов шлюза.
• Адаптеры для преобразования информационной части сообщения из одного формата в другой или, так называемые, модули-трансформеры.
• Сервер приложений для размещений модулей.
• Внутренняя СУБД для хранения сообщений.

Продукт разработан российской компанией на открытом ПО, соответствует требованиям импортозамещения. Эксперты «КСК ТЕХНОЛОГИИ» готовы проконсультировать и помочь с интеграцией, а также обучением сотрудников. Помимо «КСК. Шлюз» компания предлагает и другие отраслевые решения, например, «КСК. СИУМВВ» для межведомственного взаимодействия, «КСК. Реестр услуг» и другие.

Система межведомственного электронного взаимодействия (СМЭВ)

Межведомственное взаимодействие возникает при
предоставлении госорганами услуг гражданам и при осуществлении госфункций.
Электронное взаимодействие между ведомствами — логичный шаг в концепции
построения Электронного правительства.

Предпосылки появления СМЭВ

Для исполнения закона, реализовывая принцип «одного окна»,
ведомства (федеральные и территориальные органы власти и органы местного
самоуправления) самостоятельно в процессе предоставления госуслуг обмениваются электронными
документами и информацией, требуемыми для оказания услуг.

Обмен обеспечивается посредством СМЭВ — Системы
межведомственного электронного взаимодействия. Подход ускоряет предоставление
госуслуг и обеспечивает максимальную безопасность и конфиденциальность
передаваемых данных.

Что собой представляет Система межведомственного электронного
взаимодействия

Фактически СМЭВ является информационной системой,
объединяющей:

• базы данных, в которых среди прочего содержатся сведения об
  используемых органами и организациями технических средствах;
• историю предоставления сведений;
• а также сами технические и программные средства, позволяющие органам и
  организациям взаимодействовать через СМЭВ.

С точки зрения инфраструктуры СМЭВ представляет собой сеть
специальных защищенных каналов, объединяющих узлы — шины на базе Oracle Enterprise Service Bus — в ЦОД-ах «Ростелекома».

На 2015 год созданы один федеральный и 83 региональных
узла, подключенных к федеральному. Кроме того, к федеральному узлу Системы
межведомственного электронного взаимодействия подключен ряд федеральных
ведомств и кредитных организаций.

СМЭВ ориентирована на работу через специальные сервисы (а
именно — веб-сервисы). Это означает, что поставщики сведений создают электронные
сервисы, которые могут обработать входящие запросы и предоставить в ответ
необходимые сведения, а потребители сведений создают собственные адаптеры,
отправляющие запросы и получающие ответы.

Регистрация и получение доступа к сервисам Системы межведомственного
взаимодействия

Регистрация

Для регистрации сервиса поставщик сведений должен пройти
определенную процедуру:

1. оформить
   заявку на присоединение к регламенту обеспечения предоставления государственных
   услуг и исполнения государственных функций в электронном виде;
2. оформить
   заявку на регистрацию информационной системы, посредством которой будет
   реализован сервис;
3. запрограммировать
   электронный сервис, опираясь на требования оператора и следуя методическим
   рекомендациям по работе со СМЭВ;
4. обеспечить
   защищенность канала и доступность сервиса;
5. предоставить
   типовое описание формата сервиса, а также руководство пользователя, паспорт
   сервиса, контрольные примеры и сертификат ЭП органа власти (открытый ключ).

Получение доступа

Чтобы иметь доступ к сервису потребителю сведений
потребуется:

1. выбрать
   сервис, при помощи которого можно получать необходимые сведения, для этого
   необходимо ознакомиться с описаниями сервисов;
2. оформить
   заявку на присоединение к регламенту;
3. обеспечить
   доработку собственной ИС, чтобы она соответствовала требованиям оператора Системы
   межведомственного взаимодействия, а также методическим рекомендациям по работе
   со СМЭВ;
4. оформить
   заявку на предоставление доступа к сервису и направить ее в департамент
   государственной политики в области создания и развития Электронного правительства;
5. получить
   подтверждение о предоставлении доступа к сервису (в ряде случаев заявителю
   может быть отказано в доступе).

Более подробно о процедурах можно прочитать на Технологическом портале СМЭВ
в разделе часто задаваемых вопросов.

Готовые решения на базе платформы DIRECTUM для
работы обеспечения межведомственного электронного взаимодействия

В ходе реализации знаковых проектов в органах
государственной власти, в частности в Удмуртской Республики, Тюменской, Кировской,
Ярославской, Омской областях и других регионах РФ, компания DIRECTUM совместно с партнерами наработала опыт организации
взаимодействия региональных информационных систем со СМЭВ, создания и
регистрации сервисов, а также получения доступа к ним.

В частности разработано готовое техническое решение «DIRECTUM: Государственные
(муниципальные) услуги и межведомственное взаимодействие». Внедрение
данного решения в том числе предполагает обеспечение обмена между органами
власти федерального и регионального уровней через Систему межведомственного
электронного взаимодействия.

Архитектура решения (в части интеграции со СМЭВ) выглядит
следующим образом:

На базе технического решения построено бизнес-решение «DIRECTUM: Комплексная система
предоставления государственных (муниципальных) услуг региона». Часть задач,
закрываемых решением, напрямую связана с взаимодействием региональной
информационной системы на базе DIRECTUM с Системой межведомственного электронного взаимодействия:

• получение региональными органами исполнительной власти сведений
  от федеральных органов исполнительной власти через СМЭВ;
• предоставление региональными органами исполнительной власти
  сведений федеральным органам исполнительной власти;
• обмен сведениями между региональными органами исполнительной
  власти в электронном виде через СМЭВ.

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

С 2015 года запланирован переход на СМЭВ 3.0 с принципиально другой архитектурой, работающую с
новыми форматами. Решения, внедренные у заказчиков, будут адаптироваться, что
приведет к доработке готовых решений для новых клиентов-госорганов.

Дата публикации: 26.10.2012 16:07 (архив)

положений Федерального закона от 27.07.2010 № 210-ФЗ «Об организации предоставления государственных и муниципальных услугФедеральные органы, предоставляющие государственные услуги, не вправе требовать от заявителя представления документов и информации, которые находятся в распоряжении государственных органов, участвующих в предоставлении государственных и муниципальных услуг.              

СМЭВ – федеральная государственная информационная система, предназначенная для организации информационного взаимодействия между информационными системами участников СМЭВ в целях предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме.                                                            

Целью создания СМЭВ является повышение качества предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций за счет использования общих информационных ресурсов, уменьшения времени на поиск и обработку информации в электронной форме.

Участниками СМЭВ являются федеральные органы исполнительной власти, государственные внебюджетные фонды, исполнительные органы государственной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры, иные органы и организации.                  

Одним из крупнейших поставщиков данных является Федеральная Налоговая служба. Государственная регистрация юридических лиц и индивидуальных предпринимателей, учет организаций и физических лиц в качестве налогоплательщиков, государственные услуги ФНС России по лицензированию некоторых видов деятельности и регистрация контрольно-кассовой техники это те государственные услуги, оказываемые Налоговыми органами, которые требуют организации межведомственного электронного взаимодействия.         

Правительством России определены 11 базовых информационных реестров, из которых 4 (ЕГРИП, ЕГРЮЛ, ЕГРН, ФИАС) – реестры ФНС России.

(введена Федеральным законом от 01.07.2011 N 169-ФЗ)

1. Предоставление документов и информации, указанных в пункте 2 части 1 статьи 7 настоящего Федерального закона, а также предоставление документов и информации в случае, предусмотренном частью 4 статьи 19 настоящего Федерального закона, осуществляется в том числе в электронной форме с использованием единой системы межведомственного электронного взаимодействия и подключаемых к ней региональных систем межведомственного электронного взаимодействия по межведомственному запросу органа, предоставляющего государственную услугу, органа, предоставляющего муниципальную услугу, подведомственной государственному органу или органу местного самоуправления организации, участвующей в предоставлении предусмотренных частью 1 статьи 1 настоящего Федерального закона государственных и муниципальных услуг, либо многофункционального центра.

(в ред. Федеральных законов от 03.12.2011 N 383-ФЗ, от 28.07.2012 N 133-ФЗ)

(см. текст в предыдущей редакции)

1.1. Для реализации предусмотренных федеральным законом функций оператор Единого федерального реестра сведений о фактах деятельности юридических лиц вправе использовать систему межведомственного электронного взаимодействия.

(часть 1.1 введена Федеральным законом от 03.07.2016 N 360-ФЗ)

2. Направление межведомственного запроса и представление документов и информации, указанных в пункте 2 части 1 статьи 7 настоящего Федерального закона, допускаются только в целях, связанных с предоставлением государственных или муниципальных услуг и (или) ведением базовых государственных информационных ресурсов в целях предоставления государственных или муниципальных услуг. Требования к порядку формирования, актуализации и использования базовых государственных информационных ресурсов определяются Правительством Российской Федерации. Указанные требования должны содержать перечень мер, направленных на обеспечение соблюдения прав субъектов персональных данных, а также предусматривать меры по защите информации в соответствии с законодательством Российской Федерации. Сведения о базовых государственных информационных ресурсах и о порядке доступа к сведениям базовых государственных информационных ресурсов включаются в реестр базовых государственных информационных ресурсов, порядок формирования, актуализации и использования которого определяется Правительством Российской Федерации.

(часть 2 в ред. Федерального закона от 28.07.2012 N 133-ФЗ)

(см. текст в предыдущей редакции)

3. Предоставление налоговыми органами документов и сведений, составляющих налоговую тайну, или документов и сведений, доступ к которым ограничен законодательными актами Российской Федерации, органам, предоставляющим государственные услуги, органам, предоставляющим муниципальные услуги, и подведомственным государственным органам или органам местного самоуправления организациям, участвующим в предоставлении государственных и муниципальных услуг, предусмотренных частью 1 статьи 1 настоящего Федерального закона, либо многофункциональными центрами, а также предоставление органами, предоставляющими государственные услуги, органами, предоставляющими муниципальные услуги, иными государственными органами, органами местного самоуправления и подведомственными государственным органам или органам местного самоуправления организациями, участвующими в предоставлении государственных и муниципальных услуг, предусмотренных частью 1 статьи 1 настоящего Федерального закона, по межведомственному запросу налогового органа сведений, доступ к которым ограничен законодательными актами Российской Федерации, в целях предоставления государственной или муниципальной услуги и (или) ведения базовых государственных информационных ресурсов не является разглашением налоговой тайны или информации, доступ к которой ограничен законодательными актами Российской Федерации.

(в ред. Федерального закона от 03.12.2011 N 383-ФЗ)

(см. текст в предыдущей редакции)

4. В целях настоящего Федерального закона направление межведомственных запросов органами, предоставляющими государственные услуги, органами, предоставляющими муниципальные услуги, иными государственными органами, органами местного самоуправления и подведомственными государственным органам или органам местного самоуправления организациями, участвующими в предоставлении государственных и муниципальных услуг, предусмотренных частью 1 статьи 1 настоящего Федерального закона, многофункциональными центрами о представлении документов и информации для осуществления деятельности, не связанной с предоставлением государственных или муниципальных услуг или ведением базовых государственных информационных ресурсов в целях предоставления государственных или муниципальных услуг, не допускается, а должностные лица и (или) работники, направившие необоснованные межведомственные запросы, несут ответственность в соответствии с законодательством Российской Федерации.

(в ред. Федеральных законов от 03.12.2011 N 383-ФЗ, от 29.12.2017 N 479-ФЗ)

(см. текст в предыдущей редакции)

5. Межведомственное информационное взаимодействие в целях представления и получения документов и информации, указанных в пункте 2 части 1 статьи 7 настоящего Федерального закона, в электронной форме с использованием единой системы межведомственного электронного взаимодействия и подключаемых к ней региональных систем межведомственного электронного взаимодействия осуществляется в соответствии с положением о единой системе межведомственного электронного взаимодействия, утвержденным Правительством Российской Федерации, и принятыми в соответствии с ним правовыми актами высших исполнительных органов государственной власти субъектов Российской Федерации о региональных системах межведомственного электронного взаимодействия. Порядок представления и получения документов и информации, указанных в пункте 2 части 1 статьи 7 настоящего Федерального закона, может определяться нормативным правовым актом субъекта Российской Федерации, органа местного самоуправления с учетом указанного положения.

6. Непредставление (несвоевременное представление) органом или организацией по межведомственному запросу документов и информации, указанных в пункте 2 части 1 статьи 7 настоящего Федерального закона, в орган, указанный в абзаце первом части 1 статьи 7 настоящего Федерального закона, не может являться основанием для отказа в предоставлении заявителю государственной или муниципальной услуги. Должностное лицо и (или) работник, не представившие (несвоевременно представившие) запрошенные и находящиеся в распоряжении соответствующих органа либо организации документ или информацию, подлежат административной, дисциплинарной или иной ответственности в соответствии с законодательством Российской Федерации.

(в ред. Федерального закона от 29.12.2017 N 479-ФЗ)

(см. текст в предыдущей редакции)

7. Перечень сведений, находящихся в распоряжении государственных органов субъектов Российской Федерации, органов местного самоуправления, территориальных государственных внебюджетных фондов либо подведомственных государственным органам субъектов Российской Федерации или органам местного самоуправления организаций, участвующих в предоставлении предусмотренных частью 1 статьи 1 настоящего Федерального закона государственных или муниципальных услуг, и необходимых для предоставления государственных услуг федеральными органами исполнительной власти и органами государственных внебюджетных фондов Российской Федерации в соответствии с федеральными законами и иными правовыми актами Российской Федерации, утверждается Правительством Российской Федерации. Указанные в таком перечне сведения подлежат обязательному предоставлению федеральному органу исполнительной власти, органу государственного внебюджетного фонда Российской Федерации или многофункциональному центру по межведомственному запросу. Федеральные органы исполнительной власти, уполномоченные на установление требований к формату предоставления сведений, указанных в настоящей части, определяются Правительством Российской Федерации.

(часть 7 введена Федеральным законом от 03.12.2011 N 383-ФЗ)

8. Перечень сведений, находящихся в распоряжении государственных органов субъекта Российской Федерации, органов местного самоуправления, территориальных государственных внебюджетных фондов либо подведомственных государственным органам субъекта Российской Федерации или органам местного самоуправления организаций, участвующих в предоставлении предусмотренных частью 1 статьи 1 настоящего Федерального закона государственных или муниципальных услуг, и необходимых для предоставления государственных услуг исполнительными органами государственной власти другого субъекта Российской Федерации, территориальными государственными внебюджетными фондами и муниципальных услуг органами, предоставляющими муниципальные услуги, на территории другого субъекта Российской Федерации, определяется правовыми актами высшего исполнительного органа государственной власти субъекта Российской Федерации.

(часть 8 введена Федеральным законом от 03.12.2011 N 383-ФЗ)

9. Правительством Российской Федерации утверждаются правила межведомственного информационного взаимодействия, в том числе рекомендуемые правила организации межведомственного информационного взаимодействия между исполнительными органами государственной власти субъектов Российской Федерации и (или) органами местного самоуправления.

(часть 9 введена Федеральным законом от 30.12.2020 N 509-ФЗ)

В цикле статей мы, команда Gems Development, расскажем о работе с «Госуслугами» по ту сторону экрана и о том, как оформить эффективное взаимодействие органов государственной власти с порталом.

Общая схема взаимодействия через СМЭВ

Участники взаимодействия

Представим, что «Госуслуги» — это магазин, на витрине которого представлены сервисы для граждан и организаций. Запрос «покупателя» на услугу передаётся соответствующим органам через систему межведомственного электронного взаимодействия (СМЭВ). Система передаёт сообщения между порталом и ведомством.

Работа через СМЭВ происходит по протоколу SOAP (Simple Object Access Protocol — простой протокол для доступа к объектам).

Участники взаимодействия, как в магазине, делятся на поставщиков и потребителей. Поставщик — это информационная система (ИС), которая предоставляет сведения по запросу, а потребитель — система, запрашивает сведения.

Одна и та же ИС может действовать сразу в двух ролях. Например, в процессе предоставления услуги нужно уведомить портал о смене её статуса. В этом случае ИС-поставщик исполняет роль потребителя — проводит информационный обмен по статусам.

Виды сведений

Участники обмениваются данным через виды сведений (протоколы обмена) — правила формирования пакетов данных для передачи от одного участника другому.

Хороший пример вида сведений — Всероссийская перепись населения 2020. Данные о переписи передают федеральным органам исполнительной власти в электронном виде. В полученных данных существует чёткая структура сведений: ФИО, пол, дата рождения, гражданство, семейное положение. Также в рамках вида сведений описан ответ, который должен быть получен, если обработка запроса прошла успешно.

На июнь 2020 года в СМЭВ зарегистрировано более 1000 промышленных (рабочих) и 2000 тестовых видов.

Обмен данными в промышленной среде по всем видам сведений ведётся через защищённые каналы связи. Все передаваемые данные сопровождаются электронной цифровой подписью, с помощью которой СМЭВ идентифицирует участников взаимодействия.

Данные передаются по протоколу SOAP, при этом каждое сообщение представляет собой вложенную структуру:

Виды сведений делятся на две группы — простые и универсальные. Рассмотрим схему обмена данными по простому виду сведений:

На схеме видно, что данные форм отображаются непосредственно в конверты обмена данными. Из-за этого появляется ограничение: необходимо разработать структуру блока данных, запроса/ответа для каждого такого вида сведений.

Обмен по универсальному виду сведений можно представить так:

На первый взгляд схема может показаться более сложной, однако она демонстрирует принципиальную разницу, которая в итоге упрощает взаимодействие между участниками по универсальному виду сведений (УВС). Специфические данные форм передаются во вложении к конверту СМЭВ, а признаки УВС, позволяющие идентифицировать вид сведений, передаются непосредственно в конверте и имеют одинаковую для любого ВС структуру:

• номер заявления портала и сведения, позволяющие определить услугу;
• целевое подразделение, к которому пользователь обращается за услугой.

Данные формы, заполненные пользователем портала, пакуются во вложение к основному сообщению.

Таким образом можно оформить предоставление практически любых услуг без необходимости проходить трудную регистрацию нового вида сведений.

Очереди сообщений и процесс взаимодействия

В процессе взаимодействия сообщения помещаются в очереди входящих запросов и очереди входящих ответов. По сути очереди — это контейнеры, в которых содержатся сообщения по видам сведений.

Взаимодействие с очередями происходит с помощью специальных запросов. Более подробно они описаны в методических рекомендациях по работе со СМЭВ. Отметим только то, что благодаря очередям становится возможным асинхронный обмен данными: потребитель может оставить заявку на получение сведений, а поставщик — разместить ответ.

Следует помнить: чтобы забрать сообщение из очереди, необходимо подтвердить его получение с помощью Ack-запроса. В противном случае СМЭВ посчитает сообщение недоставленным и вернёт его в очередь через 15 минут после извлечения.

На каждый запрос может поступить как успешный, так и неуспешный ответ.

Представим себя в роли поставщика сведений: по запросу мы выдаём пользователю градостроительный план земельного участка, причём в рамках нашего ведомства действуют несколько территориальных подразделений, некоторые из которых такую услугу вовсе не оказывают. Допустим, пользователь портала при формировании заявления на получение услуги указал подразделение, не оказывающее услугу. Такая ситуация может возникнуть по двум причинам:

• Произошло расхождение справочных данных на портале и у поставщика;
• Нужного соответствия просто нет в настройках системы поставщика.

В любом случае поставщик должен ответить на запрос так, чтобы принимающая сторона могла понять, что запрос завершился неудачно, и, возможно предпринять ответные действия. Ответ на такой запрос оформляется в специальном пакете данных со сведениями о причине отказа.

Успешный ответ предполагает сценарий, в котором результат услуги — это набор файлов (что бывает довольно часто). Перед отправкой результата необходимо выгрузить файлы в файловое хранилище СМЭВ на основе FTP-сервера. Названия файлов и их контрольные суммы нужно зафиксировать в пакете, который отправляем через SOAP. Таким образом, есть две операции по передачи данных, которые нужно связать общим контекстом — сведениями о файлах.

На практике встречаются случаи, когда во время взаимодействия СМЭВ находится в режиме обслуживания, и запросы участника оборачиваются неудачей и требуют повторной отправки. Неудачу нужно зафиксировать и отправить запрос повторно.

Постановка задачи

С учётом приведённых выше особенностей, нашей команде предстояло обеспечить интеграцию ИС заказчика с «Госуслугами» по универсальному виду сведений. Информационная система заказчика — ИАС «Градоустройство». С её помощью пользователи ведомств, ответственные за оказания услуг, могут собирать пакеты документов и формировать результаты для дальнейшей передачи на портал через СМЭВ.

Итак, СМЭВ, как в поговорке про слова в песне, нельзя исключить из решения задачи интеграции с порталом государственных услуг. Но это к лучшему: благодаря системе у всех участников есть универсальная среда взаимодействия. Это позволяет опираться на определённый стандарт и не изобретать велосипед.

В следующих статьях мы рассмотрим, как на стороне поставщика сведений организовать обработку заявлений по данным пользователя с использованием движка автоматизации бизнес-процессов Workflow Core.

Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.

В настоящее время СМЭВ продолжает расширять свои возможности и вовлекать все большее количество участников взаимодействия.

Что оказалось как нельзя кстати, в том числе для коммерческих организаций, в частности банков, которые все больше стремятся перевести свои услуги в цифру и сериализовать процессы.

В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.

Здравствуйте!

Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где

• опубликована вся документация и методические указания,
• есть раздел с часто задаваемыми вопросами,
• можно скачать актуальную версию библиотек клиента СМЭВ 3,
• предоставлены примеры полных конвертов сообщений с подписями,
• можно даже проверить онлайн свое сообщение или из примера на соответствие схемам сервиса СМЭВ и на предмет валидности его электронной подписи

Все верно, портал, безусловно, крайне полезный, и всеми его подсказками и инструментами можно и нужно пользоваться, но вот код на Java напишем свой.

По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.

Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.

В то же время заглянуть в открытый код клиента всегда полезно, а его наличие само по себе говорит о зрелости системы и высоком уровне поддержки.

Анализ исходных данных

Загружаем с портала СМЭВ 3:

Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.

Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1">
   <S:Body>
      <ns2:SendRequestRequest xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">
         <ns:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">	<ns:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns:MessageID><ns2:MessagePrimaryContent><ns1:BreachRequest xmlns:ns1="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0"  xmlns:ns2="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"  xmlns:ns3="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1" Id="PERSONAL_SIGNATURE"> <ns1:RequestedInformation> <ns2:RegPointNum>Т785ЕС57</ns2:RegPointNum> </ns1:RequestedInformation> <ns1:Governance> <ns2:Name>ГИБДД РФ</ns2:Name> <ns2:Code>GIBDD</ns2:Code> <ns2:OfficialPerson> <ns3:FamilyName>Загурский</ns3:FamilyName> <ns3:FirstName>Андрей</ns3:FirstName> <ns3:Patronymic>Петрович</ns3:Patronymic> </ns2:OfficialPerson></ns1:Governance> </ns1:BreachRequest> </ns2:MessagePrimaryContent>	<ns:TestMessage/></ns:SenderProvidedRequestData>
         <ns2:CallerInformationSystemSignature><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><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="#SIGNED_BY_CONSUMER"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J3746ks34pOcPGQpKzc0sz3n9+gjPtzZbSEEs4c3sTwbtfdaY7N/hxXzEIvXc+3ad9bc35Y8yBhZ/BYbloGt+Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIBcDCCAR2gAwIBAgIEHVmVKDAKBgYqhQMCAgMFADAtMRAwDgYDVQQLEwdTWVNURU0xMQwwCgYDVQQKEwNJUzIxCzAJBgNVBAYTAlJVMB4XDTE1MDUwNzEyMTUzMFoXDTE4MDUwNjEyMTUzMFowLTEQMA4GA1UECxMHU1lTVEVNMTEMMAoGA1UEChMDSVMyMQswCQYDVQQGEwJSVTBjMBwGBiqFAwICEzASBgcqhQMCAiMBBgcqhQMCAh4BA0MABEDoWGZlTUWD43G1N7TEm14+QyXrJWProrzoDoCJRem169q4bezFOUODcNooQJNg3PtAizkWeFcX4b93u8fpVy7RoyEwHzAdBgNVHQ4EFgQUaRG++MAcPZvK/E2vR1BBl5G7s5EwCgYGKoUDAgIDBQADQQCg25vA3RJL3kgcJhVOHA86vnkMAtZYr6HBPa7LpEo0HJrbBF0ygKk50app1lzPdZ5TtK2itfmNgTYiuQHX3+nE</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns2:CallerInformationSystemSignature>
      </ns2:SendRequestRequest>
   </S:Body>
</S:Envelope>

Дедуктивным методом выясняется что:

• больше не используется прием с выносом из содержимого тега Signature в Security заголовок элемента BinarySecurityToken с сертификатом открытого ключа проверки электронной подписи и ссылкой на него через SecurityTokenReference в теле самого Signature, как, например, в СМЭВ 2.4.6. Теперь сертификат должен находиться внутри Signature.
• второе и, по сути, самое существенное и важное изменение, оказывающее большое влияние на процесс подписи — это добавление новой проприетарной трансформации:

  <ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>

Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 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 содержатся настройки только для работы с зарубежными криптографическими алгоритмами.

Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.

По старинке это делалось так:

//APACHE-SANTUARIO INIT WITH CryptoPro JCP
        System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml");
        org.apache.xml.security.Init.init();
        String cfile1 = System.getProperty("org.apache.xml.security.resource.config");
        LOGGER.log(Level.INFO, "Init class URL: " + org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation());
        LOGGER.log(Level.INFO, cfile1);

В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:

ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();

Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:

  try {
                Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName());
                santuarioIgnoreLineBreaks(true);
                LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized");
            } catch (AlgorithmAlreadyRegisteredException e) {
                LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: " + e.getMessage());
            } 

Заодно сразу выполняем требование из Методических указаний:

Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

santuarioIgnoreLineBreaks(true);

    private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";

/**
     * Apache Santuario privileged switch IgnoreLineBreaks property
     * 
     * @param mode
     */
    private void santuarioIgnoreLineBreaks(Boolean mode) {
        try {
            Boolean currMode = mode;
            AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
                
                public Boolean run() throws Exception {
                    Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD);
                    f.setAccessible(true);
                    f.set(null, currMode);
                    return false;
                }
            });
            
        } catch (Exception e) {
            LOGGER.warning("santuarioIgnoreLineBreaks " + ExceptionUtils.getFullStackTrace(e));
        }
    }

Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.

Просто через настройку системного свойства:

System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");

Через настройку опции JVM:

-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true

Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».

private static boolean ignoreLineBreaks =
        AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
            public Boolean run() {
                return Boolean.valueOf(Boolean.getBoolean
                    ("org.apache.xml.security.ignoreLineBreaks"));
            }
        }).booleanValue();
public static boolean ignoreLineBreaks() {
        return ignoreLineBreaks;
    }

Такая реализация приводит к невозможности гибко настроить в одном Java процессе для части методов игнорировать перевод строк, а для другой части не игнорировать.

Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.

С этим свойством, конечно, возникает вопрос к Apache Santuario:

Подпись сообщений СМЭВ 3

Для подписи документов СМЭВ 3 все готово.

Код подписания выглядит следующим образом:

private static final String XMLDSIG_MORE_GOSTR34102001_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411";
    private static final String XMLDSIG_MORE_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr3411";
    private static final String CANONICALIZATION_METHOD = "http://www.w3.org/2001/10/xml-exc-c14n#";
    private static final String DS_SIGNATURE = "//ds:Signature";
    private static final String SIG_ID = "sigID";
    private static final String COULD_NOT_FIND_XML_ELEMENT_NAME = "ERROR! Could not find xmlElementName = ";
    private static final String GRID = "#";
    private static final String XML_SIGNATURE_ERROR = "xmlDSignature ERROR: ";

try {
            // инициализация объекта чтения XML-документа
            DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
            
            // установка флага, определяющего игнорирование пробелов в
            // содержимом элементов при обработке XML-документа
            dbf.setIgnoringElementContentWhitespace(true);
            
            // установка флага, определяющего преобразование узлов CDATA в
            // текстовые узлы при обработке XML-документа
            dbf.setCoalescing(true);
            
            // установка флага, определяющего поддержку пространств имен при
            // обработке XML-документа
            dbf.setNamespaceAware(true);
            
// загрузка содержимого подписываемого документа на основе
            // установленных флагами правил из массива байтов data            DocumentBuilder documentBuilder = dbf.newDocumentBuilder();
         
           Document doc = documentBuilder.parse(new ByteArrayInputStream(data));
            
            /*
             * Добавление узла подписи <ds:Signature> в загруженный XML-документ
             */
            
            // алгоритм подписи (ГОСТ Р 34.10-2001)
            final String signMethod = XMLDSIG_MORE_GOSTR34102001_GOSTR3411;
            
            // алгоритм хеширования, используемый при подписи (ГОСТ Р 34.11-94)
            final String digestMethod = XMLDSIG_MORE_GOSTR3411;
            
            final String canonicalizationMethod = CANONICALIZATION_METHOD;
            
         
            String[][] filters = {{XPath2FilterContainer.SUBTRACT, DS_SIGNATURE}};
            String sigId = SIG_ID;
                
                // инициализация объекта формирования ЭЦП в соответствии с
                // алгоритмом ГОСТ Р 34.10-2001
                XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod);
                
                // определение идентификатора первого узла подписи
               
                sig.setId(sigId);
                
                // получение корневого узла XML-документа
                Element anElement = null;
                if (xmlElementName == null) {
                    anElement = doc.getDocumentElement();
                } else {
                    NodeList nodeList = doc.getElementsByTagName(xmlElementName);
                    anElement = (Element) nodeList.item(0);
                }
                // = doc.getElementById("#AppData");
                // добавление в корневой узел XML-документа узла подписи
                if (anElement != null) {
                    anElement.appendChild(sig.getElement());
                } else {
                    throw new SignatureProcessorException(COULD_NOT_FIND_XML_ELEMENT_NAME + xmlElementName);
                }
                
                /*
                 * Определение правил работы с XML-документом и добавление в узел подписи этих
                 * правил
                 */
                
                // создание узла преобразований <ds:Transforms> обрабатываемого
                // XML-документа
                Transforms transforms = new Transforms(doc);
                
                // добавление в узел преобразований правил работы с документом
                // transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
                transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
                transforms.addTransform(SmevTransformSpi.ALGORITHM_URN);
                
                // добавление в узел подписи ссылок (узла <ds:Reference>),
                // определяющих правила работы с
                // XML-документом (обрабатывается текущий документ с заданными в
                // узле <ds:Transforms> правилами
                // и заданным алгоритмом хеширования)
                sig.addDocument(xmlElementID == null ? "" : GRID + xmlElementID, transforms, digestMethod);
                
                /*
                 * Создание подписи всего содержимого XML-документа на основе закрытого ключа,
                 * заданных правил и алгоритмов
                 */
                
                // создание внутри узла подписи узла <ds:KeyInfo> информации об
                // открытом ключе на основе
                // сертификата
                sig.addKeyInfo(x509Cert);
                
                // создание подписи XML-документа
                sig.sign(privateKey);
            
            // определение потока, в который осуществляется запись подписанного
            // XML-документа
            bais = new ByteArrayOutputStream();
            
            // инициализация объекта копирования содержимого XML-документа в
            // поток
            TransformerFactory tf = TransformerFactory.newInstance();
            
            // создание объекта копирования содержимого XML-документа в поток
            Transformer trans = tf.newTransformer();
            
            // копирование содержимого XML-документа в поток
            trans.transform(new DOMSource(doc), new StreamResult(bais));
            bais.close();
        } catch (TransformationException e) {
            throw new SignatureProcessorException("TransformationException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (XMLSignatureException e) {
            throw new SignatureProcessorException("XMLSignatureException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (TransformerException e) {
            throw new SignatureProcessorException("TransformerException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (IOException e) {
            throw new SignatureProcessorException("IOException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (XMLSecurityException e) {
            throw new SignatureProcessorException("XMLSecurityException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (SAXException e) {
            throw new SignatureProcessorException("SAXException " + XML_SIGNATURE_ERROR + e.getMessage());
        } catch (ParserConfigurationException e) {
            throw new SignatureProcessorException(
                    "ParserConfigurationException " + XML_SIGNATURE_ERROR + e.getMessage());
        }
        return bais.toByteArray();

Основными параметрами здесь являются:

byte[] data, // XML сообщение в виде массива байтов

String xmlElementName, // имя элемента в XML вместе с префиксом, в который следует добавить подпись, для СМЭВ-3 в общем случае "ns2:CallerInformationSystemSignature"

String xmlElementID // ID элемента в XML (если присутствует) вместе с префиксом, на который следует поставить подпись, для СМЭВ-3 в общем случае "SIGNED_BY_CONSUMER"

X509Certificate certificate // сертификат открытого ключа проверки подписи

PrivateKey privateKey // закрытый ключ подписи

Проверка подписи сообщения СМЭВ 3

Код проверки подписи выглядит следующим образом:

private static final QName QNAME_SIGNATURE = new QName("http://www.w3.org/2000/09/xmldsig#", "Signature", "ds");
    private static final String SIGNATURE_NOT_FOUND = "Signature not found!";
    private static final String SIGNATURE_NOT_VALID = "Signature not valid";
    private static final String SMEV_SIGNATURE_PASSED_CORE_VALIDATION = "SmevSignature passed core validation";
    private static final String VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION = "Verify signature on XML IOException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION = "Verify signature on XML ParserConfigurationException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION = "Verify signature on XML SAXException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION = "Verify signature on XML XMLSignatureException: ";
    private static final String VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION = "Verify signature on XML XMLSecurityException: ";
    private static final String ID = "Id";

   boolean coreValidity = true;
        try {
            DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance();
            bf.setNamespaceAware(true);
            DocumentBuilder b = bf.newDocumentBuilder();
            Document doc = b.parse(new InputSource(new ByteArrayInputStream(signedXmlData)));
            
            NodeList sigs = doc.getElementsByTagNameNS(QNAME_SIGNATURE.getNamespaceURI(), QNAME_SIGNATURE.getLocalPart());
            org.apache.xml.security.signature.XMLSignature sig = null;
            sigSearch: {
                for (int i = 0; i < sigs.getLength(); i++) {
                    Element sigElement = (Element) sigs.item(i);
                    String sigId = sigElement.getAttribute(ID);
                    if (sigId != null) {
                        sig = new org.apache.xml.security.signature.XMLSignature(sigElement, "");
                        break sigSearch;
                    }
                }
                throw new XMLSignatureVerificationException(SIGNATURE_NOT_FOUND);
            }
            org.apache.xml.security.keys.KeyInfo ki = (org.apache.xml.security.keys.KeyInfo) sig.getKeyInfo();
            
            X509Certificate certificate = ki.getX509Certificate();
            
            if (!sig.checkSignatureValue(certificate.getPublicKey())) {
                coreValidity = false;
                LOGGER.log(Level.INFO, SIGNATURE_NOT_VALID);
            } else {
                LOGGER.log(Level.INFO, String.format(SMEV_SIGNATURE_PASSED_CORE_VALIDATION));
            }
            
        } catch (IOException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (ParserConfigurationException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (SAXException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (org.apache.xml.security.signature.XMLSignatureException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION + ExceptionUtils.getStackTrace(e));
        } catch (XMLSecurityException e) {
            throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION + ExceptionUtils.getStackTrace(e));
        }
        
        return coreValidity;

Проблемы. Хэш не совпадает

Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.

Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как

ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП

<ds:DigestValue>e76oVeYGapFDE+PV6glsj0XDjLHydLMd0cSkFPY8fWk=</ds:DigestValue>

не совпадал с оригинальным примером:

<ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo==</ds:DigestValue>

Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8); 

для параллельного анализа всех этапов трансформации.

Нормализованный элемент XML, на который требуется поставить подпись, выглядел следующим образом:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns4:Name>ГИБДД РФ</ns4:Name><ns4:Code>GIBDD</ns4:Code><ns4:OfficialPerson><ns5:FamilyName xmlns:ns5="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns5:FamilyName><ns5:FirstName>Андрей</ns5:FirstName><ns5:Patronymic>Петрович</ns5:Patronymic></ns4:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

Поиск решения показал, что, во-первых форум КриптоПро, нормализованный документ может выглядеть на самом деле иначе и соответственно его хэш будет другой и возможно правильный.

Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.

Старая версия класса трансформации выдала следующий нормализованный документ:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns5:Name xmlns:ns5="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">ГИБДД РФ</ns5:Name><ns6:Code xmlns:ns6="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">GIBDD</ns6:Code><ns7:OfficialPerson xmlns:ns7="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"><ns8:FamilyName xmlns:ns8="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns8:FamilyName><ns9:FirstName xmlns:ns9="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Андрей</ns9:FirstName><ns10:Patronymic xmlns:ns10="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Петрович</ns10:Patronymic></ns7:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

С ним хэш стал совпадать, а подпись успешно проходить валидацию.

Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:

if (logger.isDebugEnabled()) {
                debugStream = new DebugOutputStream(argDst);
                dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8);
            } else {
                dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8);
            }

Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:

prefixMappingStack.pop();

, которая удаляет первый объект из стека с префиксами

  Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();

, что приводило к неверной работе SmevTransformSpi.

Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.

Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3

Результаты

Подписание конвертов СМЭВ 3 выполняется успешно.

Сообщения проходят проверку на портале Электронного правительства Госуслуги

И в собственном приложении:

Skip to content

СМЭВ-Интегратор

Взаимовыгодный обмен информацией
между бизнесом и властью