Смэв 3 технический портал

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

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

Общие положения

Взаимодействие клиентской системы с сервисами шлюза, обеспечивающими идентификацию пользователей через ЕСИА, происходит через стандартный протокол OAuth 2.0/OpenID Connect. Авторизация в ЕСИА происходит, в данном случае, как обычная OAuth авторизация.

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

Чтобы начать работу с ЕСИА Шлюзом необходимо интегрировать в целевую информационную систему одно из готовых средств, реализующих работу с протоколом OAuth 2.0.

Спецификация OpenID Connect

Sokolko

4 года, 1 месяц назад

Как мы уже писали в статье про СМЭВ 3, Система Межведомственного Электронного Взаимодействия уже давно востребована не только государственным учреждениями и органами власти, но и рядом коммерческих организаций. У наших клиентов также возникла необходимость взаимодействия со СМЭВ. История взаимодействия была начата ещё во времена “расцвета” СМЭВ 2, для которой не было готового Адаптера СМЭВ (как для СМЭВ 3). В то время для взаимодействия со СМЭВ 2 нами был разработан собственный Адаптер СМЭВ. Он всё ещё остаётся актуальным для интеграции с некоторыми сервисами СМЭВ, которые остаются работать на СМЭВ 2 (например, отправка и регистрация сертификатов в ЕСИА для Удостоверяющих Центров). Ориентировочной датой переноса всех сервисов на СМЭВ 3 называют март 2019 года, но всё может круто поменяться, учитывая специфику функционирования СМЭВ. В данной статье речь пойдёт о запуске бесплатного Адаптера СМЭВ 3 для взаимодействия с ним.

Схемы процесса взаимодействия между Клиентской ИС, ЕСИА Шлюзом и ЕСИА/ЕБС/ЦПГ

ЕСИА Шлюз не хранит персональные данные пользователей в базе данных. Передача персональных данных пользователя происходит через защищенный по https канал связи.

ЕСИА Шлюз хранит только транспортную информацию (scopes, redirect_uri, время запроса, авторизационный код ЕСИА) и SHA-512 от ФИО и СНИЛСа пользователя. Эти данные необходимы для обработки внештатных ситуаций, таких как составление заявки в службу поддержку ЕСИА и реагирование на запросы правоохранительных органов и не являются персональными данными.

Подготовка к запуску

В нашем случае, организация уже имела доступ к СМЭВ 2, была зарегистрирована в СМЭВ и имела все необходимые учётные записи. Но, как оказалось, для подключения к СМЭВ 3 этого недостаточно. Для получения учётной записи СМЭВ 3 необходимо снова собрать все документы и пройти процедуру подключения. Процедура описана в на Технологическом портале СМЭВ. После успешного подключения, на электронную почту будет направлено зарегистрированное наименование участника (название организации) и мнемоника, которая понадобится в дальнейшем для настройки Адаптера СМЭВ.

Установка адаптера СМЭВ

Для установки под Windows мы использовали полезную с технологического портала СМЭВ 3. Единственное. что следует учитывать: для настройки лицензии Trusted Java необходимо установить VC++ redistributable (из состава меню самой Trusted Java). Без неё окошко ввода лицензии не появляется. После установки и запуска адаптера он настраивается полностью по видеоинструкции на работу с тестовой средой (). Нужно не забыть настроить мнемонику системы и указать интеграцию через файловое хранилище (это потребуется дальше). Если планируется использовать web-интерфейс адаптера, рекомендую после установки сделать резервную копию машины: добавляемые в систему виды сведений никогда не удаляются. Такая уж особенность адаптера.

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

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

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

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

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

Тестовое взаимодействие со СМЭВ 3

Для того, чтобы иметь возможность работы с производственным контуром СМЭВ, необходимо обязательно пройти тестирование на тестовом контуре. Без соблюдения этого условия заявка на доступ к виду сведений будет сразу же отклонена. Тестирование предполагает отправку и получение эталонных запросов и ответов в адрес эмулятора СМЭВ. Результаты взаимодействия со СМЭВ по тестовому контуру отправляются в виде файлов с сообщениями адаптера как вложения к заявке на доступ к виду сведений. Для того, чтобы сообщения сохранялись в файлы, нужно в “Настройках конфигурации” Адаптера СМЭВ нажать кнопку “Показать расширенные настройки” и отметить галочку “12.2 Сохранение входящих/исходящих сообщений СМЭВ”

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

Для того, чтобы отправить эталонные сообщения, нам необходимо подготовить файлы отправки. Т.к. мы выбрали интеграцию через файловое хранилище, адаптер будет забирать файлы из папки %ADAPTER_ROOT%integrationiles%MNEMONIC%out и на их основании отправлять сообщения. Тут проблема заключается в том, что у адаптера несколько иной формат конверта (сообщения), чем у сервиса ЕСМЭВ. Подробнее о формате можно почитать в руководстве администратора адаптера СМЭВ. Ниже приводится пример содержимого файла в формате адаптера для отправки эталонного сообщения тестирования вида сведений “Выписки из ЕГРЮЛ по запросам органов государственной власти”:

Здесь 111111 – мнемоника системы, 3e83e83a-6a23-4908-b0d2-e3ad08fe2602 – идентификатор запроса. Он должен меняться при каждом запросе. Можно воспользоваться онлайн-генератором по ссылке:

Как видно из примера, в блок MessagePrimaryContent помещается тело эталонного сообщения.

После отправки сообщения нужно подождать некоторое время и в папке  %ADAPTER_ROOT%messages%MNEMONIC% появятся файлы, в которых будут находиться XML-сообщения запроса и ответа. Данные файлы следует сохранить и впоследствии прикрепить к заявке на доступ к виду сведений производственного контура СМЭВ. Операцию по тестированию следует повторить для всех эталонных сообщений в архиве.

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

Надеемся, наш опыт был Вам полезен. Удачи в работе со СМЭВ!

Выбор программной платформы для адаптера

Согласно официальной документации на Адатер СМЭВ 3, поддерживается как Windows, так и Linux. Это неудивительно, т.к. он написан на Java и изначально задумывался как кроссплатформенное программное обеспечение. Тем не менее, после более детального изучения документации, стало ясно, что поддержка Linux только номинальная. В частности, в руководстве администратора адаптера СМЭВ детально расписано, какие библиотеки для Java необходимо установить на Windows, представлены сведения о криптопровайдерах и т.д. В разделе об установке на Linux написано дословно “1. Развернуть и настроить java JRE в среде Linux.”. Это максимум информации, которую можно почерпнуть из официального руководства по вопросу установки на Linux. После нашего запроса в техподдержку пришла стандартная отписка, что нужно “настроить те же компоненты, что и в варианте с Windows”. После этого вопрос с выбором платформы был решён в пользу ОС Microsoft.

Взаимодействие с сервисами шлюза

В данном разделе приводится пошаговое взаимодействие клиентской системы и шлюза, доступного по адресу https://gate.esia.pro/ В качестве клиентской ИС рассматривается система с идентификатором a4fb804bfdf54df4f4da7faae24375e6, секретом 6cd6a2bd732bb66fed6ff7fd7ca2442ccc316a8e6764cbea4e8ad589407a4c28 и путем возврата https://ya.ru

Общее описание HTTP API предоставляемого со стороны ЕСИА Шлюза

Для инициации процесса идентификации и аутентификации пользователей через ЕСИА необходимо сформировать авторизационный запрос и передать его на соответствующий URL шлюза. Для пользователя с вышеуказанными параметрами ссылка будет иметь следующий вид.

Для получения данных об организации требуется

Указать в параметре scope необходимые значения, соответствующие методическим рекомендациям ( допустимые значения scope приведены в таблице ниже ).
Согласно регламенту ЕСИА scope org_# нужно формировать запросом вида scope=“http://esia.gosuslugi.ru/org_emps?org_oid=1000000357”
На странице 237 регламента есть информация про org_# и формирование запроса.

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

После получения идентификатора, необходимо отправить запрос на получение данных организации.
На пример запрос на получение Инн по компании:

Для идентификации пользователя через ЕБС требуется:

• Изменить значение параметра provider на ebs_oauth;
• В параметре scope указать openid bio.

Для получения данных Цифрового профиля требуется:

• Изменить значение параметра provider на cpg_oauth;
• В параметре scope указать openid;
• указать опциональный параметр responsible_object – Иванов Иван Иванович.

Должна получиться ссылка вида:

https://demo.gate.esia.pro/auth/authorize?client_id=a4fb804bfdf54df4f4da7faae24375e6response_type=codescope=openidredirect_uri=https://ya.ruprovider=cpg_oauthpermissions=fullnamepurposes=CREDITsysname=CREDITactions=ALL_ACTIONS_TO_DATAexpire=3responsible_object=Иванов Иван Ивановичstate=1a73f168-4485-11ed-b878-0242ac120002

Для запроса нескольких целей согласия нужно указать их в запросе в параметре purposes=
Должна получиться ссылка следующего вида:

В случае успешной авторизации произойдет редирект на url следующего вида

где, в параметре code передается авторизационный код.

В случае возникновения ошибки будет редирект на url возврата с указанием ошибки

где, в параметрах error и error_description хранится информация об ошибке.

Получение токена доступа (Обмен авторизационного кода на токен доступа)

• grant_type – тип авторизационного кода (допустимое значение authorization_code);
• redirect_uri – путь возврата специфичный для конкретного клиента;
• client_id – идентификатор клиента;
• code – авторизационный код;
• client_secret – секрет клиента.

На предыдущем шаге после успешной авторизации в ЕСИА был получен авторизационный код, который следует обменять на токен доступа (access_token) для его последующего использования при получении пользовательских данных. Один код можно обменять только на один токен. Для этого отправляем POST запрос на url

со следующими параметрами запроса:

• grant_type=authorization_code;
• redirect_uri=https://ya.ru – путь возврата специфичный для конкретного клиента;
• client_id=a4fb804bfdf54df4f4da7faae24375e6 – идентификатор клиента;
• code – авторизационный код;
• client_secret=6cd6a2bd732bb66fed6ff7fd7ca2442ccc316a8e6764cbea4e8ad589407a4c28 – секрет клиента.

Пример запроса получения access_token:

curl POST https://demo.gate.esia.pro/auth/token

Будет получен следующий ответ.

В поле access_token находится токен доступа.

Получение данных пользователя

Для получения данных отправляется GET или POST запрос на url

со следующими заголовками запроса:

Пример запроса на получение данных:

На основе полученного токена доступа шлюз предоставляет клиентским системам доступ к областям данных из защищённого хранилища ЕСИА.

ВАЖНО! В соответствии с законодательством перечень скоупов доступных для клиентских систем шлюза может быть ограничен. Поэтому, прежде чем указывать перечень скоупов в запросе к шлюзу, необходимо сверить этот перечень с перечнем скоупов указанным в заявке на подключение к тестовой/промышленной ЕСИА.

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

Получение согласий пользователя из Цифрового профиля

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

Получение документов из Цифрового профиля

Запрос документов происходит так же, как и запрос других данных – путем указания нужного scope. Но в случае запроса документа ответ может поступить не сразу, а в течении некоторого времени.
В случае, если сведение запрошено в ведомстве и ответ еще не поступил, возвращается
идентификатор этого запроса и идентификатор пользователя (oid). С помощью идентификатора
запроса осуществляется процесс обработки персональных данных. Для возможности получения
сведения о документах необходимо обновить запрос. Для типа документа
INCOME_REFERENCE (Справка о доходах и суммах налога физического лица (форма 2-НДФЛ))
дополнительно указывается параметр year – год, за который успешно получена справка 2-НДФЛ
в ведомстве.
В случае, если у пользователя нет информации по следющим сведениям: FID_BRTH_CERT,
OLD_BRTH_CERT, RF_BRTH_CERT, MARRIED_CERT, DIVORCE_CERT,
NAME_CHANGE_CERT и FATHERHOOD_CERT, то в ответе на запрос вернется ошибка 404.
Перечень параметров, которые возвращаются по каждому типу документа (doc_type),
приведены в разделе 7.2 методических рекомендаций.

Выписка с данными в исходном виде

Получение данных о документах в исходном виде происходит так же путем указания scope.
Сервис доступен для типов документов VEHICLE_INFO (Выписка
о транспортном средстве по владельцу), ILS_PFR (Cведения о состоянии индивидуального
страхового счета застрахованного лица), PAYOUT_INCOME (Сведения о доходах
физического лица и о выплатах страховых взносов, произведенных в пользу физического
лица). Но в случае запроса данных ответ может поступить не сразу, а в течении некоторого времени.
В случае, если сведение запрошено в ведомстве и ответ еще не поступил, возвращается
идентификатор этого запроса и идентификатор пользователя (oid). С помощью идентификатора
запроса осуществляется процесс обработки персональных данных. Для возможности получения
сведения о выписки транспортого средства по владельцу необходимо обновить запрос. Перечень
параметров, которые возвращаются по каждому типу документа (doc_type), приведен в разделе
7.2 методических рекомендаций.

Пример ответа в случае запроса openid и fullname из защищённого хранилища ЕСИА:

Выход из системы ЕСИА

• client_id=a4fb804bfdf54df4f4da7faae24375e6 – идентификатор клиента;
• redirect_uri=https://ya.ru/callback – путь возврата специфичный для конкретного клиента, на который будет перенаправлен пользователь;
• state – набор случайных символов, имеющий вид 128 битного идентификатора запроса, сформированного по стандарту UUID. Должен отличаться от набора, использованного для получения авторизационного кода. Необходим для предотвращения CSRF атак.

Для получения данных отправляется GET запрос

Для инициации процесса выхода из системы ЕСИА необходимо сформировать авторизационный запрос и передать его на соответствующий URL шлюза. Для пользователя с вышеуказанными параметрами ссылка будет иметь следующий вид:

ВАЖНО! Путь возврата пользователя обязательно должен быть указан в соответствующей КИС

Также, необходимо добавить на тех.портал ЕСИА url вида https://gate.esia.pro/auth/esia_oauth/logout_callback

После завершения сессии в системе ЕСИА пользователь будет перенаправлен на адрес, указанный в параметре redirect_uri

Взаимодействие по защищённому протоколу

В соответствии с ч. 19 и ч. 21 ст. 14.1 Федерального закона от 27.07.2006 №149-ФЗ “Об информации, информационных технологиях и о защите информации” для обеспечения защиты передаваемых биометрических персональных данных от актуальных угроз безопасности должны применяться сертифицированные средства криптографии (шифрования). Таким образом каждый пользователь, инициирующий (по средством браузера) соединение, с целью проведения процедур биометрической идентификации должен быть уведомлён о необходимости установки российских сертифицированных средств криптографической защиты если таковые не были установлены в его браузере. В случае отказа пользователя от использования российских сертифицированных средств криптографической защиты его необходимо уведомить о рисках перехвата биометрических персональных данных злоумышленником, для дальнейшего их использования в мошеннических целях.

Браузеры, поддерживающие российские сертифицированные средства криптографической защиты:

• Яндекс.Браузер версии 19.3. и выше
• Спутник версии 4.1 и выше
• Internet Explorer версии 11.0.9600 и выше

• КриптоПРО CSP 5.0
• ViPNet CSP Win 4.4 Windows RUS

Контроль использования российских сертифицированных средств криптографической защиты возлагается на клиентскую систему (КИС), являющуюся стороной, по средством которой пользователь инициирует процесс биометрической идентификации.

Отличия СМЭВ 2 от СМЭВ 3

Изначально мы планировали доработать наш Адаптер СМЭВ 2 собственной разработки для взаимодействия со СМЭВ 3. Но, как выяснилось, отличия двух систем не просто значительные, а радикальные. По сути, с точки зрения интеграции СМЭВ 2 не имеет почти ничего общего со СМЭВ 3. В СМЭВ 2 каждый поставщик данных (ФНС, ПФР, МВД) имел свой SOAP-сервис со своим файлом WSDL и особенностями работы. В СМЭВ 3 присутствует единый сервис, который является посредником между запрашивающей стороной (нами) и поставщиками информации. Более детально СМЭВ 3 описан в документе Методические рекомендации по работе с ЕСМЭВ

При выборе способа интеграции нужно учитывать, что передаваемые сообщения подписываются электронной подписью (ЭП) организации. Кроме того, при взаимодействии с единым сервисом СМЭВ 3 нужно использовать протокол SOAP с нестандартным алгоритмом каноникализации. Не совсем понятно, почему разработчики СМЭВ решили использовать свою каноникализацию, это уже останется на их совести. Само собой, свободных и открытых библиотек для данного алгоритма нет. Трудности есть и с подписыванием запросов SOAP по ГОСТ, т.к. не все языки программирования поддерживают ГОСТ “из коробки”. Эталонная реализация алгоритма каноникализации доступна только на Java, так что разработчики, использующие другие языки должны либо реализовывать данный алгоритм самостоятельно, либо отказаться от работы со СМЭВ.

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

Полностью собственное решение на удобном нам языке (Python)

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

Реализация собственного адаптера на Java

Данный способ использует для хранения закрытой части ключа КриптоПРО JCP. Такое решение соответствует законодательным требованиям РФ по защите ЭП, т.к. используется сертифицированный криптопровайдер. К недостаткам можно отнести поддержку не всех носителей ЭП и необходимость приобретения лицензии на КриптоПРО JCP. Библиотека для Java распространяется свободно.

Мы решили не останавливаться на этом способе, т.к. он “прибит гвоздями” к Java, а для нас удобнее несколько иные технологии разработки.

Бесплатный Адаптер СМЭВ 3

Мы выбрали за основу последний способ. При данном подходе за взаимодействие со СМЭВ 3 отвечает бесплатный адаптер СМЭВ от Ростелекома. Он полностью реализует функции асинхронной работы с единым сервисом СМЭВ (постановка в очередь запросов и формирование ответов). Подпись вычисляется через Trusted Java, ключ хранится в стандартном КриптоПРО CSP, который поддерживает очень большое количество носителей ЭП и имеет все необходимые сертификаты. Тут следует отметить, что требуется приобретение лицензий на Trusted Java и КриптоПРО CSP, но они довольно бюджетные и не оказали существенного влияния на общую смету проекта (порядка 3 000 руб. суммарно).

На схеме цветом выделены те сервисы, которые реализуются непосредственно нами на удобной нам технологии разработки ПО (Python). Благодаря возможности выбора способа интеграции (база данных, файловый обмен, SOAP) мы не привязаны к Java или каким-либо другим языкам программирования. Более подробно интерфейсы интеграции Адаптера СМЭВ описаны в руководстве администратора Адаптера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ к сервисам шлюза

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

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

• адрес шлюза (например, адрес демо стенда RNDSOFT https://gate.esia.pro/);
• идентификатор клиента (например, a4fb804bfdf54df4f4da7faae24375e6);
• секрет клиента (например, 6cd6a2bd732bb66fed6ff7fd7ca2442ccc316a8e6764cbea4e8ad589407a4c28);
• страница с конфигурацией OАuth https://gate.esia.pro/.well-known/openid-configuration

Значение идентификатора и секрета для КИС берутся из её параметров в административной панели шлюза.

ЕСИА Шлюз не занимается валидацией скоупов, переданных клиентской системой. Скоупы просто передаются в ЕСИА. Поэтому .well-known/openid-configuration содержит пустой массив в scopes_supported.