Техподдержка смэв

Система исполнения регламентов

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

Описание систем исполнения регламентов

Руководство пользователя СИР 3.0

Состав процедур, необходимых для обеспечения возможности работать в СИР и последовательность их выполнения описаны в документе «Технологическая карта процесса подготовки и предоставления услуг РОИВ и ОМСУ»

Порядок действий пользователей СИР по настройке рабочих мест с переходом на аутентификацию через ЕСИА

1. Настройка ПК пользователя.

1. Зарегистрировать себя, как физическое лицо на сайте ЕСИА https://esia.gosuslugi.ru, согласно Инструкции по переходу на аутентификацию с использованием ЕСИА. Результатом регистрации должно быть получение подтвержденной учетной записи физ. лица в ЕСИА
2. Уполномоченный сотрудник ведомства, к которому относится Пользователь (руководитель или администратор), должен выполнить в ЕСИА процедуру присоединения сотрудника к органу власти (ведомству) — см. Инструкции по переходу на аутентификацию с использованием ЕСИА
3. Направить заявку на sd@egov66.ru на создание учетной записи пользователя в СИР по своему СНИЛС, либо выпуск сертификата доступа к системе, в том случае, если ранее Пользователь не работал в СИР. Если Пользователь имел сертификат доступа к СИР, то проверить срок его действия. Если закончился, то направить заявку на sd@egov66.ru на продление этого сертификата (чтобы сохранить все настройки пользователя в СИР).
4. Получив ответ от техподдержки о создании учетной записи пользователя СИР, либо сертификат доступа к системе, новый Пользователь должен направить заявку на sd@egov66.ru на настройку его СНИЛС, либо сертификата, на какие-то виды настроек: для работы с МФЦ, для настройки на АРМ МВ, для настройки на тиражируемые услуги ЛАНИТ и АТК, на АРМ–Поставщика и др.
5. Направить на sd@egov66.ru Заявку на изменение пользователей СНИЛС

3. Порядок входа Пользователя в СИР по окончании настроeк

1. Открыть браузер Mozilla Firefox, и очистить в нем КЭШ и КУКи
2. Ввести в адресную ссылку https://66.sir.egov.local/tp-manager/
3. Подтвердить выбор своего сертификата, если система предложит — выполнится переход на ЕСИА автоматически
4. Подтвердить себя в ЕСИА. Подтвердить выбор своего сертификата, если система предложит. Выполнится переход на СИР автоматически.

Шаг №1 — получение разрешения на использование ЦПГ в ЦБ РФ

Для получения доступа к ЦПГ, необходимо обратиться в ЦБ РФ, с просьбой
предоставить доступ к Цифровому профилю. Отправлять запрос необходимо через ЛК ЦБ РФ. Видеоинструкция по отправке запроса через ЛК ЦБ РФ доступна по ссылке. Ответ занимает до 3-х рабочих дней.

Шаг №2 — создание учетной записи организации в ЕСИА

Необходимо создать учетную запись организации через портал Госуслуг (см. раздел
3.2 Руководства). Это может сделать
руководитель организации через сайт Госуслуг. Для этого он должен быть
зарегистрирован на госуслугах и иметь квалифицированную электронную подпись
(КЭП) юридического лица (в т.ч. это может быть подпись ЭП-СП). За получением
средства КЭП нужно обратиться в один из аккредитованных Минкомсвязью России
удостоверяющих центров вашего региона. Подробнее о процессе получения КЭП
можно прочитать здесь: http://minsvyaz.ru/ru/appeals/faq/35

Шаг №3 — получение КЭП в УЦ

Требуется получить средство технологической электронной подписи для
информационной системы («ключ для СМЭВ»/ «ключ Организации (ЭП- ОВ)»,
извлекаемый ключ, в сертификате которого должны быть указаны только данные
Организации), обратившись в любой удостоверяющий центр, входящий в Единое
пространство доверия.
Перечень удостоверяющих центров доступен по адресу
https://digital.gov.ru/ru/activity/govservices/certification_authority/.
Это может сделать
руководитель организации через сайт Госуслуг. Для этого он должен быть
зарегистрирован на госуслугах и иметь квалифицированную электронную подпись
(КЭП) юридического лица (в т.ч. это может быть подпись ЭП-СП). За получением
средства КЭП нужно обратиться в один из аккредитованных Минкомсвязью России
удостоверяющих центров вашего региона. При невозможности получения КЭП в УЦ, необходимо обратиться в федеральное казначейство, ЦБ РФ или федеральную налоговую службу. В зависимости от типа организации.

Внимание: полученный из КЭП сертификат, должен использоваться только в одной ИС в СМЭВ и только для работы с сервисом ЦПГ и ЕСИА, при необходимости работать с другими СМЭВ сервисами, нужно будет создать отдельную ИС в СМЭВ, и выпустить отдельный сертификат

Шаг №4 — присоединение к регламенту СМЭВ

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

Внимание: следующий шаг рекомендуется выполнять не ранее, чем через 3 дня после отправки заявки.

Шаг №5 — регистрация ИС в среде СМЭВ 3

На рабочем столе ЛК УВ запустит страницу Информационные системы / Добавление.
На странице добавления информационной системы следует заполнить:

Среда СМЭВ – нередактируемое поле;

Мнемоника – нередактируемое текстовое поле, содержит уникальную мнемонику создаваемой Информационной системы, при создании новой информационной системы, ЛК УВ автоматически создаст уникальную мнемонику Информационной системы;

Краткое наименование – текстовое поле, содержит краткое наименование создаваемой Информационной системы;

Полное наименование – текстовое поле, содержит полное наименование создаваемой Информационной системы;

Сертификат – нередактируемое поле, после загрузки на форму сертификата, в поле отображается его номер.

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

Далее откроется окно добавление сертификата создаваемой Информационной системы.
Необходимо загрузить сертификат вашей КЭП в окно загрузки, сертификат пройдет проврку в системе ЛК УВ.

После заполнения всей необходимой инофрмации и добавления сертификата система предложит вам подтвердить добавление системы, нужно проверить инофрмацию и нажать кнопку “Да, уверен”

После создания ИС в тестовой среде СМЭВ, нужно создать ИС в продуктивной среде СМЭВ и загрузить файл сертификата вашей КЭП по аналогии из шагов выше. ИС в продуктивной среде СМЭВ копируется из тестовой среды, при создании ИС вам предложат выбрать это действие.

Шаг №6 — предоставление доступа к тех. порталу

Для доступа к техпорталу и переходу к шагу №7 вам необходимо, в учетной записи
созданной организации перейти в раздел «Сотрудники» и добавить всех сотрудников,
которым будет необходим доступ к техпорталу. Во вкладке «Доступ к системам»,
также предоставить добавить всех сотрудников, которым необходим доступ для
управления системой. Во вкладке «Группы доступа» необходимо «присоединить»
сотрудников, которым будет необходимо управлять ИС на техпортале, а также
«присоединить» администратора ИС к «Администраторам профиля ораганизации».
Внимание: После добавления сотрудников во все группы, необходимо выйти из
техпортала и госуслуг, очистить кэш в браузере и перезайти в систему.

Шаг №7 — создание ИС на тех. портале

Регистрация ИС в ЕСИА необходима для дальнейшего получения доступа к сервисам СМЭВ 3.0, взаимодействующим с ЕСИА (УПРИД, Сервис регистрации пользователей и т.д.).
Зарегистрировать ИС можно через технологический портал ЕСИА. Подробную инструкцию по регистрации ИС в
ЕСИА смотрите в руководстве пользователя технологического портала: http://minsvyaz.ru/ru/documents/4545/. В результате регистрации ваша информационная система заносится в реестр ИС, взаимодействующих с ЕСИА.

Внимание: При регистрации ИС в ЕСИА необходимо указать Мнемонику ИС в ЕСИА = Мнемонике ИС в СМЭВ.
Также, требуется загрузить сертификат электронной подписи системы, такой же как зарегистрирован в СМЭВ для этой системы.

• название системы – желательно использовать официальное название ИС на русском языке;
• отображаемое название – текст, который будет отображаться на форме логина ИС;
• мнемоника системы – идентификатор системы, который будет использоваться в ЕСИА;
• информация о системе – краткое описание ИС;
• URL системы – url с обязательным указанием протокола HTTP/HTTPS, например: https://esia.gosuslugi.ru/;
• Алгоритм формирования электронной подписи – GOST (как на скриншоте выше);
• URL для отправки push сообщений – оставить пустым.

• поле URL для отправки push сообщений – оставить пустым;
• «Категория информационной системы» – оставить по умолчанию, параметры «время жизни» не менять;
• данные об ответственном за эксплуатацию ИС – ответственный должен быть предварительно зарегистрирован в ЕСИА и присоединен к организации-оператору ИС в качестве сотрудника. Для выбора сотрудника достаточно ввести первые буквы фамилии, после чего будут предложены возможные варианты. Поля «адрес электронной почты» и «номер телефона» отображаются автоматически после выбора сотрудники (это служебные контакты указанного сотрудника).

После заполнения данных полей необходимо нажать на кнопку «Сохранить». Запись ИС будет добавлена в регистр ЕСИА.

Шаг №8 — генерация необходимых файлов

При подаче заявки на подключение к тестовой среде ЕСИА вам потребуются ключ и
сертификат ключа.

Для получения необходимо обратиться в один из аккредитованных удостоверяющих
центров. Ключом будут шифроваться запросы от вашей ИС к ЕСИА. Перечень
аккредитованных удостоверяющих центров доступен по адресу
https://digital.gov.ru/ru/activity/govservices/certification_authority/ . Для экспорта ключа
используйте инструкцию указанную на шаге No8.

Шаг №11 — заполнение и отправка заявки на промышленную среду

После получения положительного ответа о подключении к тестовой среде ЕСИА
следует аналогично шагам No6-7 направить заявку на “На подключение к
промышленной среде ЕСИА”. В бланке заявке указать номер заявки на подключение к тестовой среде.

Шаг №12 — передача ключа и сертификата

После завершения процесса подключения необходимо экспортировать контейнер из КЭП в
соответствии с инструкцией – https://crypto.rnds.pro/.
Вам необходимо выполнить первые 5 шагов инструкции и полученные 6 файлов загрузить в систему.

Шаг №13 — Получение доступа к ВС ЦПГ через ЛК УВ

Для получения доступа к ВС ЦПГ через ЛК УВ необходимо:
1.Пройти авторизацию на сайте ЛУ УВ(сотрудник должен находиться в группе доступа к “ЛК УВ”) – https://lkuv.gosuslugi.ru/
2.В ЛК УВ основного меню выбрать пункт “Доступ к виду сведений”

3.Выбрать продуктивную среду СМЭВ

4.Необходимо выбрать вид сведений ЦПГ из списка доступных ВС.

Запрос перечня согласий пользователя ЕСИА, выданных организации – https://docs.agredator.ru/docs/services/esia/issued-person-permissions/
Запрос согласий пользователя ЕСИА от организации – https://docs.agredator.ru/docs/services/esia/claim-person-permissions/
Запрос персональных данных при наличии согласия пользователя ЕСИА – https://docs.agredator.ru/docs/services/esia/personal-data/#запрос-персональных-данных-при-наличии-согласия-пользователя-есиа

5.Выбрать версию ВС к которой вы хотите получить доступ.

6.Необходимо выбрать информационную систему для которой запрашивается доступ
к ВС.

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

8.После прохождения всех шагов получения доступа к ВС ЦПГ, нужно подтвердить процедуру подтверждения технической готовности, выбрав кнопку ”Да,уверен”
При подтверждении, воспроизводится процедура прохождения тестирования с ЛК УВ.

Шаг №14 — Прохождение тестирования

Необходимо пройти тестирование на подключение к ВС ЦПГ
Описание ВС в СМЭВ:
https://smev3.gosuslugi.ru/portal/inquirytype_one.jsp?id=168374&zone=fed&page=1&dTest=false

И дополнительным ВС:

Описание ВС в СМЭВ:
«Запрос согласий пользователя ЕСИА от организации».

С помощью данного ВС система-клиент может запрашивать согласия у гражданина.

Описание ВС в СМЭВ:
«Запрос перечня согласий пользователя ЕСИА, выданных организации».
https://smev3.gosuslugi.ru/portal/inquirytype_one.jsp?id=169220&zone=fed&page=1&dTest=false

С помощью данного ВС система-клиент может запрашивать перечень выданных
гражданином организации-владельцу ИС согласий.

Для завершения подключения к ВС ЦПГ необходимо отправить тестовые запросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с требованиями Федерального закона Российской Федерации от 27 июля 2006 года № 152-ФЗ «О персональных данных» приостановлена регистрация учетных записей пользователей на платформе Единой системы официальных сайтов. Создание учетных записей осуществляется специалистом оператора технической поддержки на основании заявки исключительно для ответственных за наполнение и администрирование сайта ИОГВ и ОМСУ.

Для получения доступа в систему ответственных лиц за наполнение сайта необходимо:

Заполнить форму заявки на добавление нового пользователя.

Направить официальное сопроводительное письмо на имя Директора ГБУ СО «Оператор электронного правительства» о назначении ответственного лица за наполнение и администрирование сайта.

Для отключения учетной записи пользователя необходимо:

Направить официальное сопроводительное письмо на имя Директора ГБУ СО «Оператор электронного правительства» о назначении ответственного лица за наполнение и администрирование сайта.

Для ускорения процесса регистрации/изменений прав в Единой системе официальных сайтов копии документов (отсканированные) можно направлять в ГБУ СО «Оператор электронного правительства» по электронной почте на адрес sd@egov66.ru

Пароль назначается администратором системы и передается заявителю в электронном виде.

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

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

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

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

В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 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 выполняется успешно.

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

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

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

Реализация взаимодействия информационных систем организаций и ведомств осуществляется в рамках государственной целевой программы «Информационное общество (2011-2020 годы)».

Взаимодействие реализуется в рамках:

• системы межведомственного электронного документооборота (МЭДО).

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

Что такое СМЭВ и для чего она нужна?

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

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

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

СМЭВ предназначена для решения следующих задач:

• обеспечение исполнения государственных и муниципальных функций в электронной форме;

• обеспечение предоставления государственных и муниципальных услуг в электронной форме, в том числе с использованием универсальной электронной карты и единого портала² ;

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

Основные функции СМЭВ

Основными функциями СМЭВ являются:

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

• обмен электронными сообщениями между участниками СМЭВ;

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

В целях исполнения своих функций СМЭВ обеспечивает:

• доступ к электронным сервисам³ информационных систем, подключенных к СМЭВ;

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

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

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

• ведение реестра электронных сервисов информационных систем, подключенных к СМЭВ.

Технологическое обеспечение СМЭВ

Технологическое обеспечение информационного взаимодействия с применением СМЭВ достигается путем использования:

• сервис-ориентированной архитектуры, представляющей собой совокупность электронных сервисов, построенных по общепринятым стандартам;

• единых технологических решений и стандартов, единых классификаторов и описаний структур данных.

Как стать участником СМЭВ?

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

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

Регламенты и подключение к СМЭВ

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

Создана в соответствии с Федеральным законом Российской Федерации от 27 июля 2010 года № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг».