"Методические рекомендации по использованию Единой системы идентификации и аутентификации. Версия 2.84" (приложение 17 к протоколу заседания Подкомиссии по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по использованию информационных технологий для улучшения качества жизни и условий ведения предпринимательской деятельности от 13.05.2016 N 168пр)
к протоколу заседания Подкомиссии
по использованию информационных
технологий при предоставлении
государственных и муниципальных услуг
Правительственной комиссии
по использованию информационных
технологий для улучшения качества
жизни и условий ведения
предпринимательской деятельности
от 13 мая 2016 г. N 168пр
ЕДИНАЯ СИСТЕМА ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ
ПО ИСПОЛЬЗОВАНИЮ ЕДИНОЙ СИСТЕМЫ ИДЕНТИФИКАЦИИ
И АУТЕНТИФИКАЦИИ
- | - | ||
- | - | Создана новая версия документа в рамках развития ЕСИА в 2013 г. | |
- | - | Внесены исправления в документ: - уточнено описание процедуры подписания запроса при аутентификации с помощью протокола SAML; - уточнено описание перечня SAML-атрибутов; - уточнено описание электронного сервиса по регистрации пользователей ЕСИА, опубликованного в СМЭВ (добавлено описание процедуры получения доступа к сервису, добавлены идентификаторы сервиса ЕСИА в СМЭВ, уточнено описание метода восстановления доступа); - уточнено описание областей доступа (scope), используемых программными интерфейсами на основе REST. | |
- | - | Исключено приложение с описанием электронных сервисов ЕСИА для работы с должностными лицами ОГВ. Произведена перенумерация остальных приложений. Внесены уточнения и детализации в технические описания во всех приложениях | |
- | - | Детализация описания механизма аутентификации с использованием OpenID Connect 1.0 | |
- | - | Добавлено описание программного интерфейса на основе REST по получению данных о филиалах и ОГВ. Уточнено описание программного интерфейса на основе REST по получению данных о системных группах. Изменено обозначение типов учетных записей. Добавлены ссылки на Технологический портал ЕСИА. Уточнено описание redirect_uri при использовании сервиса авторизации ЕСИА на основе OAuth 2.0. Уточнено описание сервиса получения данных о субъекте (Приложение Б.7). Уточнен формат адреса, используемый в REST-сервисе ЕСИА | |
- | - | Уточнен формат запроса на получение маркера доступа при реализации модели контроля доступа на основе полномочий системы-клиента. Уточнен процесс завершения активной сессии пользователя при использовании протокола SAML | |
- | - | - новых типов документов физических лиц, получаемых через REST API ЕСИА; - данных о детях, получаемых через REST API ЕСИА; - новых возможностей по использованию аутентификации с использованием OpenID Connect 1.0 (проверка аутентификации в фоновом режиме и открытие страницы аутентификации во всплывающем окне); - возможностей по управлению данными организации; - новых разрешений на доступ к данным (scope); - возможности возврата пользователя в систему, направившую пользователя в ЕСИА для выполнения операций. | |
- | - | Добавлено описание сервиса "Единый сервис упрощенной идентификации пользователей Единой системы идентификации и аутентификации" | |
- | - | Добавлено описание использования разрешения (scope) для передачи сведений о детях. | |
- | - | Добавлено описание использования разрешения (scope) "openid" для интеграции информационных систем | |
- | - | Добавлено в Таблицу 11 "Состав набора данных" пункт - место рождения, при вызове скоупа id_doc и foreign_passport_doc | |
- | - | Из Таблицы 11 исключен пункт место рождения. Добавлено описание сервиса УПРИД. Уточнена информация по сервису регистрации. Добавлен раздел Б.9 Предоставление списка измененных пользователей или организаций за период времени В таблице 6 добавлены параметры ответа на запрос о персональных данных пользователя: verifying и status. | |
- | - | К Таблице 11 в примечании добавлено описание scope, позволяющих получить Гражданство пользователя. | |
- | - | Уточнено описание структуры маркера идентификации (Приложение В.7). | |
- | - | В Таблице 11 добавлен скоуп "birthplace". | |
- | - | В Таблице 10 исправлены коды ошибок. | |
- | - | В Таблице 11 добавлен скоуп usr_org. | |
- | - | Добавлено описание полей "district" и "settlement" для атрибута orgAddresses (Таблица 5). | |
17.01.2017 | Пригарина Д.А. | В Таблице 10 добавлен новый код ошибки при отсутствии разрешения на доступ к указанному скоупу. В таблице 6 добавлены параметры ответа на запрос о контактах пользователя: vrfValStu и verifyingValue. | |
31.01.2017 | Пригарина Д.А. | Добавлен раздел с описанием метода импорта учетной записи пользователя (Приложение Б.9). | |
08.02.2017 | Маслова Г.В. | В таблице 6 изменен параметр fiasCode ответа на запрос о сведениях об отдельной записи в перечне адресов физического лица. | |
09.03.2017 | Пригарина Д.А. | Обновлен алгоритм импорта УЗ, пример ответа на запрос, обязательность полей адреса (Приложение Б.9). | |
10.04.2017 | Пригарина Д.А. | Добавлено описание получения информации для скоупа usr_org (Приложение В.4). В Приложении Б.9 добавлено описание заголовков запроса (Request-Data, Request-Data Sign). Обновлено описание параметров series и number для документа, удостоверяющего личность. | |
02.05.2017 | Горбунова О.Е. | В Приложении В.4 в перечень скоупов добавлен скоуп usr_avt. Добавлено описание получения информации для скоупа usr_avt (Приложение Б.9.2). | |
04.05.2017 | Пригарина Д.А. | Добавлено описание ошибок для параметра errorStatusInfo (Приложение Б.9). Обновлено описание ответа для запроса: https://esia-portal1.test.gosuslugi.ru/rs/orgs/100000/emps?embed=(elements.person) (Приложение Б.1). | |
20.06.2017 | Маслова Г.В. | Обновлен пример запроса (вызов сервиса в среде разработки) в Приложении Б.11 (добавлен параметр "birthplace"). | |
03.07.2017 | Пригарина Д.А. | В разделе 3.1.1 добавлена информация о прекращении поддержки SAML 2.0 в ЕСИА. В разделах Б.2, В.2.2, В.4, В.5 обновлены примеры, касающиеся скоупа id_doc. В разделах В.6.2.2, В.6.2.3 обновлены примеры запросов. | |
18.07.2017 | Маслова Г.В. | Добавлена Таблица 10 с кодами ошибок от сервиса импорта. Для параметров запроса импорта актуализированы форматы данных и значение обязательности для отправки в запросе. В Приложениях Б8, В 3.2, В4 удалена информация о скоупе sbj_inf. Добавлено приложение Д4 по устаревшим скоупам ЕСИА. | |
17.08.2017 | Пригарина Д.А. | Обновлена обязательность следующих полей запроса метода импорта (Б.9): birthplace, series, number, issuedBy. | |
29.08.2017 | Пригарина Д.А. | В описании метода импорта (Б.9) добавлен новый тип документа - FRGN_PASS (заграничный паспорт гражданина РФ), обновлено описание параметров запроса для документа, удостоверяющего личность. В Таблице 13 для параметра flowDetails в поле name добавлено новое значение - raRegistrationEndorsement (подтверждение регистрации пользователем по СМС). | |
08.11.2017 | Пригарина Д.А. | Обновлена обязательность поля middleName запроса метода импорта (Б.9). | |
19.12.2017 | Маслова Г.В. | Обновлена обязательность поля middleName запроса метода импорта (Б.9). | |
26.12.2017 | Жукова Д.А. | Добавлены новые параметры в ответе на запрос при получении данных организации (rs/orgs, Б.4). Добавлены новые параметры при ответе на запрос при получении списка организация пользователя (rs/prns/{prn_oid}/roles, В.4). | |
30.01.2018 | Маслова Г.В. | Внесены уточнения в таблицу 10. | |
02.02.2018 | Маслова Г.В. | Внесены изменения в раздел 3.5 "Возврат пользователя в систему, вызвавшую профиль пользователя в ЕСИА или регистрацию пользователя в ЕСИА". | |
09.02.2018 | Маслова Г.В. | Исправлены опечатки. | |
01.03.2018 | Цирихов А.М. | Внесены изменения в Приложение Б.9 Импорт учетной записи пользователя: - в таблице с описанием параметров запроса: обязательность параметра документа issuedBy - наименование подразделения, выдавшего паспорт - указана как Y/N (обязателен только для паспорта гражданина РФ); - в примере запроса импорта УЗ скорректировано содержимое элемента addresses; - скорректированы примеры ответов на запрос импорта УЗ; - Таблица 10 - Коды и описание ошибок от сервиса импорта: добавлены коды ESIA-030007, ESIA-032205, ESIA-039812, ESIA-039815, и их описания; - Таблица 11 - Параметры ответа на запрос о статусе проверки данных пользователя: в описание добавлен параметр personOid - идентификатор зарегистрированной учетной записи; - Таблица 11 - Параметры ответа на запрос о статусе проверки данных пользователя: в перечень возможных значений атрибута name параметра flowDetails добавлено значение "C" - операция отменена; - Скорректирован основной и добавлены дополнительные примеры ответов на запрос о статусе выполнения заявки. | |
07.03.2018 | Жукова Д.А. | Добавлен раздел "Удаленная идентификация с использованием биометрической идентификации" (Приложение В.8). | |
12.03.2018 | Маслова Г.В. | Исправлены опечатки. | |
13.03.2018 | Цирихов А.М. | Выполнены доработки и внесены изменения в Приложение Б.9 Импорт учетной записи пользователя: - обновлена схема, представленная на рисунке 14 - Алгоритм импорта учетной записи в ЕСИА; - скорректирована таблица с параметрами ответа на запрос импорта УЗ в ЕСИА: - в примечаниях добавлено описание возможных значений возвращаемого параметра code (Код завершения операции); - в примечаниях добавлено описание назначения возвращаемого параметра description (Текстовое описание кода завершения операции); - в примечаниях добавлено описание назначения возвращаемого параметра message (Текстовое описание кода ошибки выполнения операции); - Таблица 10 - Коды и описание ошибок от сервиса импорта: - скорректировано содержимое столбца с описанием кодов возврата для некоторых кодов ошибок; - добавлен код ошибки ESIA-910307 и его описание. | |
10.04.2018 | Цирихов А.М. | Выполнены доработки и внесены изменения в Приложение Б.9 Импорт учетной записи пользователя: - Таблица 11 - Параметры ответа на запрос о статусе проверки данных пользователя: перечень возможных значений атрибута name параметра flowDetails разделен на две возвращаемые группы: - задачи и статусы их выполнения до момента завершения проверки СНИЛС; - задачи и статусы их выполнения после успешного завершения проверки СНИЛС и создания упрощенной УЗ; - скорректированы примеры ответов на запрос о статусе выполнения заявки - в соответствии с разделением статусов на две возвращаемые группы (до и после проверки СНИЛС). | |
28.04.2018 | Маслова Г.В. | Внесены изменения в Приложение Б.1 Общие сведения о программном интерфейсе ЕСИА. | |
29.06.2018 | Жукова Д.А. | Обновление описания информации о получении аватара пользователя (Приложение Б.9.2). Дополнение раздела об удаленной идентификации с использованием биометрической идентификации примерами получаемых маркеров доступа (Приложение В.8) и общей схемой взаимодействия участников. | |
04.07.2018 | Жукова Д.А. | Добавлено описание нового scope - "ext_auth_result" (Приложение В.4). Обновлена информация о структуре маркера доступа, выдаваемого ЕСИА, в частности об алгоритме шифрования (Приложение В.5). | |
17.07.2018 | Жукова Д.А. | Добавлены новые типы свидетельства о рождении и новый параметр (номер актовой записи) при получении информации о документах пользователя и о документах детей пользователя (Приложение Б.2). | |
30.07.2018 | Жукова Д.А. | Добавлена информация о необходимости наличия подтвержденного мобильного телефона в профиле пользователя при изменении основных данных в стандартной и подтвержденной УЗ (п. 4.2.1). | |
26.09.2018 | Жукова Д.А. | Обновлена информация о завершении удаленной идентификации пользователя (получение пользовательского маркера доступа) (Приложение В.8, п. 2). Добавлен новый код ошибки в Таблицу 12 - ESIA-032110 (Приложение Б.9). Добавлена информация о завершении сессии ЕСИА при закрытии браузера (п. 3.2.1, п. 3.3). Добавлена информация о возможности обмена авторизационного кода на один маркер доступа (Приложения В.2.3 и В.6.3). | |
05.10.2018 | Жукова Д.А. | Добавлена информация о настройке сроков жизни маркера доступа и маркера обновления (Приложение Б.1). Добавлена информация о дополнительных возможных кодах ошибок при получении маркера доступа в обмен на маркер обновления (Приложение В.2.4). | |
22.10.2018 | Цирихов А.М. | Приложение В.7 - в подраздел Сведения о структуре маркера идентификации: добавлено описание возможных типов субъекта ("urn:esia:sbj:typ"). Приложение В.8 - Удаленная идентификация с использованием биометрической идентификации: в подразделе "2. Завершение удаленной идентификации пользователя, получение пользовательского маркера доступа" скорректирован пример состава расширенного маркера доступа (PAYLOAD-часть) | |
26.11.2018 | Маслова Г.В. | В Приложении Б.2 REST-API /prns/{oid}/ctts/{ctt_id} удалена информация о служебной электронной почте. | |
27.11.2018 | Мезин Д.А. | В таблице 10 скорректировано описание кодов возврата для кодов ошибок: - ESIA-032205; - ESIA-039815. | |
06.12.2018 | Маслова Г.В. | Добавлена информация о поддержке ГОСТ Р 34.10-2012. | |
18.12.2018 | Мезин Д.А. | В таблице 10 скорректировано описание кода возврата для кода ошибки: ESIA-032205. | |
21.12.2018 | Мезин Д.А. | В таблице 10 удалена информация о коде ошибки: ESIA-039815. | |
26.12.2018 | Маслова Г.В. | В Приложении В.5 скорректированы сведения о структуре и проверке маркера доступа: добавлено описание информации о наличии делегирования полномочий. | |
26.12.2018 | Мезин Д.А. | Добавлено описание областей доступа (scopes): gosbar и gosbar_org (Приложение В.4). | |
28.12.2018 | Цирихов А.М. | 1. В Приложении А.5 Описание метаданных поставщика услуг в таблице 5 расширено описание атрибута principalDocuments в части типов документа "Свидетельство о рождении". 2. В Приложения Б.2 и Б.4 (сервисы ЕСИА на базе подхода REST, предоставление персональных данных пользователей и предоставление данных из профиля организации) добавлено описание методов REST API ЕСИА для получения данных о транспортных средствах пользователей и организаций в соответствии с выполненными доработками (параметры пагинации, общее количество транспортных средств, полная информация о транспортном средстве). | |
11.01.2019 | Жукова Д.А. | Обновлено описание метода импорта учетной записи пользователя: 1. Текущее описание перенесено в Приложение Д.5 как устаревшее. Добавлен новый код ошибки ESIA-039600; 2. Приложение Б.9 было обновлено: добавлена информация об адресе новой версии метода импорта, новых кодах ошибок (ESIA-039601, ESIA-039602, ESIA-039603, ESIA-039815), новой функции подтверждения упрощенных учетных записей. Обновлен алгоритм работы метода импорта. | |
18.01.2019 | Маслова Г.В. | В таблице 18 в состав набора данных для scope "id_doc" и "foreign_passport_doc" добавлено значение "гражданство". В разделе Б.9 добавлен код ошибки ESIA-035116. | |
30.01.2019 | Мезин Д.А. | В разделе Б.9 добавлен код ошибки ESIA-039805, скорректировано описание кода возврата для кода ошибки ESIA-035116. | |
13.02.2019 | Цирихов А.М. | Приложение В.7 - в подразделе "Сведения о структуре маркера идентификации" скорректировано описание возможных типов субъекта ("urn:esia:sbj:typ"): "P" - физическое лицо. | |
13.03.2019 | Цирихов А.М. | Приложение В.8 "Удаленная идентификация с использованием биометрической идентификации" - добавлена ссылка на раздел документа "Методические рекомендации по работе с Единой биометрической системой", описывающий интеграцию внешних систем с Единой биометрической системой, в том числе содержащий указания по использованию защищенных сетей передачи данных при использовании методов REST API Биометрической верификации. Исправлено описание формата параметра "17irthdate" (Таблица 6). | |
11.04.2019 | Мезин Д.А. | В таблицу 10 добавлен код ошибки ESIA-039810 | |
26.04.2019 | Жукова Д.А. | Указание информации о scope "bio" в Приложениях В.4 и В.8 | |
05.06.2019 | Мезин Д.А. | В Приложение Г. Добавлен новый раздел Г.9.5 Рекомендации по взаимодействию с видами сведений в СМЭВ 3.X | |
11.06.2019 | Цирихов А.М. | 1. В документ добавлено Приложение Б.11 - Сервис управления внешними ИС центрами обслуживания организаций. 2. В подразделы 3.1.1 и 3.1.2 добавлена информация и ссылка на сертификаты тестовой и продуктивной сред ЕСИА, используемые для формирования электронных подписей ответов как поставщика. | |
16.07.2019 | Мезин Д.А. | В пункте Б.11 скорректировано описание сервиса REST API. | |
07.08.2019 | Мезин Д.А. | В Приложение Б. Обновлен формат fiasCode. | |
08.10.2019 | Цирихов А.М. | 1. Исключено указание на возможность использования ИС самоподписанных сертификатов электронных подписей. 2. Исключено указание на возможность использования сертификатов электронных подписей, выпущенных с использованием криптографических алгоритмов, отличных от ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 (кроме раздела 3.1.1 Аутентификация с использованием стандарта SAML и приложения А. Использование ЕСИА в целях идентификации и аутентификации посредством стандарта SAML 2.0). | |
23.10.2019 | Мезин Д.А. | В приложении В.3.2 скорректировано описание получения маркера доступа. | |
02.12.2019 | Мезин Д.А. | В приложении В.3.1.1 и В.3.1.2 скорректировано описание. | |
24.12.2019 | Мезин Д.А. | В приложении Б.11.3 актуализирован пример ответа метода сервиса REST API получения списка ЦО организации. | |
26.12.2019 | Мезин Д.А. | В приложение Б.11 Сервис управления внешними ИС центрами добавлено описание для поля opnModes. | |
26.02.2019 | Мезин Д.А. | 1) Добавлено новое приложение Б.10 Сервис подтверждения операций по регистрации УЗ через интеграционный модуль ЕПГУ; 2) В приложение Б.9 добавлен код ошибки ESIA-032010; 3) В разделы 3.2.2 и В.6.5 добавлена информация об обязательности вызова Logout. | |
26.03.2020 | Петраков С.В. | В приложение Б.12.2 Сервис REST API безусловного добавления сотрудников в организацию в перечень возвращаемых ошибок добавлено описание ошибки ESIA-036102 | |
14.04.2020 | Мезин Д.А. | В приложении Б.4 Предоставление данных из профиля организации актуализированы коды типов ОГВ. | |
28.05.2020 | Тихонова Е.Н. | 1. В разделе Б.9 добавлен код ошибки ESIA-039803, скорректировано описание кода возврата для кода ошибки ESIA-032010; 2. В разделе Б.9 добавлено описание способа формирования подписи запроса (Request-Data-Sign) для метода импорта. | |
15.07.2020 | Цирихов А.М. | В документ добавлено Приложение Б.13 - Сервис получения маркера доступа по идентификационному ключу | |
17.08.2020 | Жукова Д.А. | В Таблицу 6 добавлен новый параметр <actDate> - дата актовой записи (только для свидетельства о рождении ребенка РФ) для свидетельства о рождении РФ ребенка. | |
21.08.2020 | Мезин Д.А. | В приложении Б. - Сервисы ЕСИА на базе подхода REST скорректировано описание для метода "Сведения об отдельной записи в перечне документов физического лица" | |
08.09.2020 | Маркелова М.Н. | 1. В приложение Б.4 добавлено описание методов REST API ЕСИА для получения данных о категориях организации; 2. В Приложение В.4 в перечень скоупов добавлен скоуп categories. | |
17.09.2020 | Тихонова Е.Н. Маркелова М.Н. | 1. В приложение Б.2 добавлена информация о самозанятых и добавлено описание методов REST API ЕСИА для получения данных о категориях самозанятого; 2. В приложение В.4 в перечень скоупов добавлен скоуп self_employed. 3. В приложении Б. - Сервисы ЕСИА на базе подхода REST скорректировано описание для методов "Данные о пользователе с идентификатором prn-id" и "Сведения об отдельной записи в перечне документов физического лица" | |
05.10.2020 | Мезин Д.А. | В приложение Б добавлен новый раздел Б.9.1 Модернизированный сервис импорта учетных записей пользователя из внешних информационных систем | |
27.10.2020 | Мезин Д.А. | В приложение Б.12.4 Сервис REST API прикрепления сотрудников к ЦО добавлен код ошибки: ESIA-039961 | |
03.12.2020 | Цветкова Г.А. | 1. В приложении Б.9 в таблице 13 добавлено описание кодов ошибок ESIA-910100 и ESIA-910001 2. В приложении Б.9 скорректировано описание примера с ошибкой ESIА-910100 | |
08.12.2020 | Тихонова М.А. | В приложении В4 - для получения информации об организациях, в которые включен пользователь - к данному REST-API добавлен атрибут <admin> с его значением. | |
25.12.2020 | Маркелова М.Н. | В приложении А.5 и Б.4 изменено наименование параметра телефон с "PHN" на "OPH" в контактах организации | |
19.03.2021 | Тихонова М.А. | 1. Актуализирована схема импорта (Рисунок 14 - Обобщенный алгоритм импорта в ЕСИА) 2. Внесены изменения в таблицу ФЛК - Параметры ответа на запрос о статусе проверки данных пользователя для полей: ФИО, наименование подразделения, выдавшего документ, и номер подразделения для паспорта РФ; фамилия и имя на латинице и наименование подразделения, выдавшего документ для заграничного паспорта 3. Внесены изменения в таблицу с параметрами ответа. В параметр "code" добавлено примечание по возвращению значения ответа. 4. Удален параметр "message" из таблицы, которая хранит в себе параметры, передающиеся в ответе от вызова метода импорта 5. Добавлены коды ответов на запрос о статусе выполнения заявки (Таблица 12 - Коды и описание ошибок от сервиса импорта) - Изменено описание https-адреса REST-API, добавлено описание версии v2 - Добавлена информация об адресе временной регистрации (Таблица 6) - Добавлен скоуп addresses, удален скоуп contacts (Таблица 18) - Добавлен скоуп contacts (Таблица 24) | |
14.04.2021 | Тихонова М.А. | Добавлен пункт 7 "Перечень scope для предоставления доступа к API ЕПГУ" | |
21.04.2021 | Тихонова М.А. | 1. Добавлены коды ESIA-020016, ESIA-033448, ESIA-033445 и описание ошибок от сервиса импорта (Таблица 12 - Коды и описание ошибок от сервиса импорта). 2. Актуализирована схема импорта (Рисунок 14). В конце документа приложен архив со схемой импорта в rar-формате. В приложении В.6.2.2 добавлено описание реализации механизма бесшовной аутентификации. | |
23.04.2021 | Жукова Д.А. | В Таблице 16 добавлен новый код ошибки - ESIA-007023. | |
27.04.2021 | Тихонова М.А. | 1. Добавлен параметр "message" в таблицу, которая хранит в себе параметры, передающиеся в ответе от вызова метода импорта. 2. Добавлено описание условий отображения параметром "message" и "decription". |
Единый государственный реестр индивидуальных предпринимателей | |
Федеральная государственная информационная система "Единый портал государственных и муниципальных услуг (функций)" | |
Федеральная государственная информационная система "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме" | |
Орган государственной власти. Федеральные органы исполнительной власти, государственные внебюджетные фонды, органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры предоставления государственных и муниципальных услуг, а также иные организации, определенные федеральными законами, актами Президента Российской Федерации и актами Правительства Российской Федерации | |
Основной государственный регистрационный номер индивидуального предпринимателя | |
Орган или организация, обладающая правом создания (замены) ключа ПЭП в соответствии с постановлением Правительства РФ от 25 января 2013 г. N 33 "Об использовании простой электронной подписи при оказании государственных и муниципальных услуг". В соответствии с указанным постановлением Правительства, в качестве Операторов выдачи ключа ПЭП могут выступать федеральные органы исполнительной власти, государственные внебюджетные фонды, органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры предоставления государственных и муниципальных услуг, а также иные организации, определенные федеральными законами, актами Президента Российской Федерации и актами Правительства Российской Федерации (а также уполномоченные ими организации), осуществляющие оказание государственных или муниципальных услуг и подключенные к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме | |
Министерство связи и массовых коммуникаций Российской Федерации | |
Организация, осуществляющая регистрацию и управление ИС. В качестве операторов ИС, включенных в регистр информационных систем ЕСИА, могут быть организации, обеспечивающие решение следующих задач: - предоставление государственных и муниципальных услуг; - исполнение государственных и муниципальных функций; - формирование БГИР; - межведомственное электронное взаимодействие; - иные задачи, предусмотренные федеральными законами, актами Президента РФ и актами Правительства РФ. | |
Пользователь информационно-телекоммуникационной сети "Интернет", зарегистрированный в ЕСИА в качестве физического лица. Может иметь роли индивидуального предпринимателя, сотрудника юридического лица, должностного лица ОГВ | |
ИС, интегрированная с ЕСИА и осуществляющая предоставление пользователям ЕСИА данных и услуг, в частности, государственных и муниципальных услуг в электронной форме | |
Регламент взаимодействия участников информационного взаимодействия с оператором ЕСИА и оператором инфраструктуры электронного правительства при организации информационно-технологического взаимодействия информационных систем с использованием ЕСИА | |
Федеральная государственная информационная система "Единая система межведомственного электронного взаимодействия" | |
Страховой номер индивидуального лицевого счета застрахованного лица в системе персонифицированного учета Пенсионного фонда России | |
Сотрудник Оператора выдачи ключа ПЭП, осуществляющий подтверждение личности пользователей ЕСИА | |
Специализированное веб-приложение, размещенное по адресу https://esia.gosuslugi.ru/console/tech. Предназначено, в частности, для управления ИС организаций | |
Центр обслуживания органа или организации, имеющей право создания (замены) и выдачи ключа ПЭП. В Центре обслуживания специалистами Центра обслуживания осуществляется регистрация и/или подтверждение личности пользователей ЕСИА | |
Передача репрезентативного состояния (Representational State Transfer) | |
Переход к оказанию государственных и муниципальных услуг в электронном виде требует от государства предоставить людям и органам государственной власти возможности безопасно идентифицировать друг друга онлайн. Когда люди и органы государственной власти могут доверять результатам идентификации друг друга, они могут предоставлять и потреблять услуги, чего нельзя было бы достичь в другом случае из-за большой сложности или важности услуг.
В текущей онлайн среде от людей требуется ведение десятков различных имен пользователей и паролей - по одной паре для каждого веб-сайта, с которым пользователь взаимодействует. Сложность такого подхода является бременем для людей и потворствует такому поведению, как повторное использование паролей, что упрощает онлайн мошенничества и нарушения идентификации. В то же время органы государственной власти сталкиваются с постоянно возрастающими затратами на управление учетными записями пользователей, последствиями онлайн мошенничеств и неэффективностью электронных услуг в результате нежелания потенциальными пользователями проходить регистрацию еще одной учетной записи.
Созданная Минкомсвязью России ФГИС ЕСИА:
1. Предоставляет использующим ее информационным системам органов государственной власти решение по достоверной идентификации пользователей (как физических, так и должностных лиц ЮЛ и ОГВ), достигнутой благодаря тому, что:
- регистрация лица в ЕСИА сопряжена с проверкой значимых для удостоверения личности критериев;
- ЕСИА обеспечивает защиту размещенной в ней информации в соответствии с законодательством Российской Федерации.
2. Является ориентированной на пользователя - предоставляет ему возможности:
- идентификации и аутентификации с использованием единой учетной записи и широкого спектра поддерживаемых методов аутентификации при доступе к различным информационным системам органов государственной власти;
- управления своими персональными данными, размещенными в ЕСИА, и контроля над их предоставлением в информационные системы органов государственной власти.
1. Описывает базовые сценарии использования ЕСИА:
- идентификация и аутентификация пользователей при доступе к информационным системам органов государственной власти (раздел 3);
- ведение идентификационных данных и полномочий пользователей (раздел 4);
- получения информационными системами органов государственной власти данных из регистров, хранимых в ЕСИА (раздел 4).
2. Поясняет порядок ведения в ЕСИА регистров (справочников), необходимых для реализации базовых сценариев использования ЕСИА:
- регистр юридических лиц и должностных лиц юридических лиц;
- регистр органов государственной власти и должностных лиц органов государственной власти;
- регистр информационных систем.
3. Предоставляет методические рекомендации по интеграции информационных систем с ЕСИА и обеспечению соответствия положениям нормативно-правовых актов в части использования ЕСИА.
Настоящий документ разработан в целях реализации и во исполнение следующих нормативно-правовых актов:
- Федеральный закон от 27 июля 2010 г. N 210-ФЗ "Об организации предоставления государственных и муниципальных услуг".
- Федеральный закон от 6 апреля 2011 г. N 63-ФЗ "Об электронной подписи".
- Государственная программа Российской Федерации "Информационное общество (2011 - 2020 годы)", утвержденная распоряжением Правительства Российской Федерации от 20 октября 2010 г. N 1815-р.
- Постановление Правительства Российской Федерации от 28 ноября 2011 г. N 977 "О федеральной государственной информационной системе "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме".
- Постановление Правительства Российской Федерации от 9 февраля 2012 г. N 111 "Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке ее использования, а также об установлении требований к обеспечению совместимости средств электронной подписи".
- Постановление Правительства Российской Федерации от 25 января 2013 г. N 33 "Об использовании простой электронной подписи при оказании государственных и муниципальных услуг".
- Постановление Правительства Российской Федерации от 10 июля 2013 г. N 584 "Об использовании федеральной государственной информационной системы "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме".
- Положение "Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме", утвержденное постановлением Правительства Российской Федерации от 8 июня 2011 г. N 451.
- Положение "О федеральной государственной информационной системе "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме", утвержденное приказом Минкомсвязи России от 13 апреля 2012 г. N 107.
В соответствии с постановлением Правительства Российской Федерации от 28 ноября 2011 г. N 977 ЕСИА должна обеспечивать санкционированный доступ участников информационного взаимодействия (заявителей и должностных лиц ОГВ) к информации, содержащейся в государственных информационных системах, муниципальных информационных системах и иных информационных системах.
При этом ЕСИА не обеспечивает выполнение процессов идентификации, аутентификации и авторизации участников межведомственного взаимодействия, возникающих в процессе использования СМЭВ, в частности, при взаимодействии информационных систем с использованием СМЭВ.
Основные функциональные возможности ЕСИА:
- идентификация и аутентификация пользователей, в том числе:
-- однократная аутентификация <1>, которая дает пользователям ЕСИА следующее преимущество: пройдя процедуру идентификации и аутентификации в ЕСИА, пользователь может в течение одного сеанса работы обращаться к любым информационным системам, использующим ЕСИА, при этом повторная идентификация и аутентификация не требуется;
--------------------------------
<1> Соответствующий термин на английском языке - Single Sign On.
-- поддержка различных методов аутентификации: по паролю, по электронной подписи, а также двухфакторная аутентификация (по постоянному паролю и одноразовому паролю, высылаемому в виде sms-сообщения);
-- поддержка уровней достоверности идентификации пользователя (упрощенная учетная запись, стандартная учетная запись, подтвержденная учетная запись).
- ведение идентификационных данных <2>, а именно - ведение регистров физических, юридических лиц, органов и организаций, должностных лиц органов и организаций и информационных систем;
--------------------------------
<2> Соответствующий термин на английском языке - Identity Management.
- авторизация уполномоченных лиц ОГВ при доступе к следующим функциям ЕСИА:
-- ведение регистра должностных лиц ОГВ в ЕСИА;
-- ведение справочника полномочий в отношении ИС и предоставление пользователям ЕСИА (зарегистрированным в ЕСИА как должностные лица ОГВ) полномочий по доступу к ресурсам ИС, зарегистрированным ЕСИА;
-- делегирование вышеуказанных полномочий уполномоченным лицам нижестоящих ОГВ.
- ведение и предоставление информации о полномочиях пользователей в отношении информационных систем, зарегистрированных в ЕСИА.
Обращение участников информационного взаимодействия к ЕСИА должно происходить только по протоколу HTTPS (использовать протокол HTTP запрещено).
3 АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ ЧЕРЕЗ ЕСИА
Разработчики государственных сайтов, порталов и прочих веб-приложений могут предоставить своим пользователям возможность входить в систему, используя учетную запись ЕСИА. Это избавляет разработчиков от необходимости делать собственное хранилище учетных записей, обеспечивать безопасность хранения паролей, разрабатывать механизмы регистрации, аутентификации пользователей, поддерживать их в рабочем состоянии.
Под пользователями ЕСИА понимаются следующие категории участников информационного взаимодействия:
- физические лица, имеющие учетную запись в регистре физических лиц ЕСИА;
- индивидуальные предприниматели, т.е. физические лица, имеющие признак индивидуального предпринимателя;
- должностные лица юридических лиц, т.е. физические лица, присоединенные к учетным записям юридических лиц ЕСИА;
- должностные лица органов и организаций, т.е. физические лица, присоединенные к учетным записям ОГВ.
Пользователи получают возможность однократной аутентификации. Это означает, что, пройдя процедуру аутентификации в ЕСИА, пользователь может в течение одного сеанса работы войти в несколько систем, и при этом повторно вводить логин и пароль не потребуется.
С целью обеспечения указанного функционала в ЕСИА реализовано два альтернативных механизма, которые позволяют разработчику использовать наиболее подходящий для его системы:
- механизм, основанный на стандарте SAML версии 2.0;
- механизм, основанный на модели OpenID Connect 1.0.
Аутентификация с использованием стандарта SAML
ЕСИА использует стандарт SAML версии 2.0, который был разработан в 2005 году концерном OASIS. SAML базируется на языке XML и определяет способы обмена информацией об аутентификации пользователей, их полномочиях и идентификационных данных. В соответствии с принятой в этом стандарте терминологией ЕСИА выступает в роли доверенного поставщика идентификации (Identity Provider), а система выступает в роли поставщика услуг (Service Provider) <3>.
--------------------------------
<3> Подробное описание схемы интеграции посредством SAML 2.0 представлено в приложении А.
Общая схема подключения системы к ЕСИА представлена на рисунке ниже.
Рисунок 1 - Схема взаимодействия ИС с ЕСИА с целью
идентификации и аутентификации с использованием стандарта
SAML 2.0
Аутентификация с использованием модели OpenID Connect
В ЕСИА создан механизм аутентификации пользователей, основанный на спецификациях OAuth 2.0 и расширении OpenID Connect 1.0.
Протокол определяет взаимодействие следующих сторон:
- владелец ресурса (resource owner) - сущность, которая может предоставить доступ к защищаемому ресурсу (например, физическое лицо, заявитель);
- система-клиент (client) - приложение, которое запрашивает доступ к защищаемому ресурсу от имени его владельца;
- сервис авторизации (authorization server) - сервис, который выпускает для системы-клиента маркеры идентификации с разрешениями от владельца ресурса, а также маркеры доступа, позволяющие получать доступ к данным;
- поставщик ресурса (resource server) - сервис, обеспечивающий доступ к защищаемому ресурсу на основе проверки маркеров идентификации и маркеров доступа (например, к идентификационным данным пользователя).
Расширение OpenID Connect 1.0 предполагает использование маркера идентификации (ID Token) в целях проведения идентификации и аутентификации пользователя. Маркер идентификации содержит идентификационные данные пользователя, а также ряд служебных параметров (дата выдачи, время окончания срока действия и пр.).
Для иллюстрации использования OpenID Connect 1.0 в ЕСИА принята следующая терминология:
- владелец ресурса - это пользователь;
- система-клиент - это информационная система, интегрированная с ЕСИА с целью идентификации и аутентификации, например региональный портал услуг;
- сервис авторизации и поставщик ресурса - это ЕСИА.
Общая схема подключения системы к ЕСИА для проведения аутентификации представлена на рисунке ниже.
Рисунок 2 - Схема подключения системы к ЕСИА
3.1 Как обеспечить вход пользователей через ЕСИА
Чтобы предоставить пользователям вашей системы возможность входить через ЕСИА, используя тот или иной механизм, со стороны подключающейся системы необходимо обеспечить:
- Регистрацию ИС в регистре информационных систем ЕСИА (в соответствии с Регламентом <4>).
--------------------------------
<4> Раздел 6 Регламента.
- Регистрацию системы с целью идентификации и аутентификации в тестовой среде в соответствии с Регламентом <5>. Исполнение этого процесса предоставляет возможность участнику производить взаимодействие с ЕСИА в тестовой среде.
--------------------------------
<5> Раздел 9 Регламента.
- Выполнение доработки интегрируемой системы с целью обеспечения поддержки выбранного механизма идентификации и аутентификации.
- Подключение продуктивной версии интегрируемой системы к продуктивной среде ЕСИА в соответствии с Регламентом <6>.
--------------------------------
<6> Раздел 10 Регламента.
Далее каждый из шагов для каждого механизма аутентификации рассмотрен подробнее.
3.1.1 Аутентификация с использованием стандарта SAML <7>
--------------------------------
<7> Внимание! В связи с прекращением поддержки SAML 2.0 в ЕСИА подключение ИС к ЕСИА через этот интерфейс будет прекращено с 01.01.2018, поэтому для подключения рекомендуется использовать протокол OAuth 2.0/OpenID Connect. Запрещено подключение по протоколу SAML 2.0 и по протоколу OAuth 2.0/OpenID Connect одновременно. Возможность изменения параметров подключения к ЕСИА через интерфейс SAML 2.0 для ранее подключенных ИС будет сохранена.
Аутентификация с использованием SAML доступна для использования исключительно государственными органами и организациями (далее - ОГВ), т.е. федеральными органами исполнительной власти, государственными внебюджетными фондами, органами исполнительной власти субъектов Российской Федерации, органами местного самоуправления, государственными и муниципальными учреждениями, многофункциональными центрами предоставления государственных и муниципальных услуг, а также иными организациями в случаях, предусмотренных федеральными законами, актами Президента Российской Федерации и актами Правительства Российской Федерации.
Регистрация ИС осуществляется согласно Регламенту (раздел 6).
Рекомендуемая последовательность действий:
1. Сформулировать функциональные требования к взаимодействию своей системы с ЕСИА.
- изучить рекомендуемые сценарии использования и выбрать нужные;
- определить перечень сведений о пользователе, которые вашей ИС требуется получать из ЕСИА в утверждениях SAML;
- определить требования к уровню достоверности идентификации пользователя (см. п. 4.1.1).
2. Представить для своей системы сертификат ключа неквалифицированной электронной подписи в формате X.509 версии 3. Сертификат требуется для идентификации ИС при взаимодействии с ЕСИА. Более подробную информацию о сертификате X.509 можно посмотреть по ссылке http://tools.ietf.org/html/rfc5280.
3. Сертификаты тестовой и продуктивной сред ЕСИА, используемые для формирования электронных подписей ответов как поставщика (алгоритм электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012).
4. Реализовать интерфейсы поставщика услуг SAML. В качестве исходных данных для разработки следует использовать:
- функциональные требования, сформированные на 1 шаге;
- спецификация SAML 2.0 (доступна по ссылке http://saml.xml.org/saml-specifications), в том числе описание профилей Web Browser SSO, Assertion Query/Request, Single Logout Profile;
- спецификация Interoperable SAML 2.0 Web Browser SSO Deployment Profile (доступна по ссылке http://saml2int.org/profile/current);
- описание форматов и примеры сообщений SAML в ЕСИА (см. п. А.4 - А.7 приложения А);
- рекомендации по использованию готовых реализаций поставщиков услуг с открытым кодом (см. п. А.2 приложения А).
5. Доработать дизайн сайта, выбрав место для размещения кнопки "Войти через ЕСИА", и реализовать в системе логику обработки данных о пользователях, получаемых из ЕСИА. Недопустимо отображать страницу аутентификации ЕСИА во фрейме сайта.
6. Обеспечить в соответствии с требованиями законодательства комплекс мер, необходимых для обеспечения информационной безопасности и защиты персональных данных пользователей, получаемых информационной системой в процессе ее взаимодействия с системой ЕСИА.
7. Загрузить актуальные метаданные поставщика идентификации ЕСИА:
- метаданные тестового поставщика идентификации ЕСИА опубликованы по ссылке https://esia-portal1.test.gosuslugi.ru/idp/shibboleth <8>;
--------------------------------
<8> Здесь и далее esia-portal1 в ссылке - имя тестового домена в зависимости от тестовой среды. Конкретную тестовую среду для регистрации устанавливает оператор эксплуатации при обработке заявки на регистрацию.
- метаданные промышленного поставщика идентификации ЕСИА опубликованы по ссылке https://esia.gosuslugi.ru/idp/shibboleth.
8. Подготовить метаданные интегрируемой системы (поставщика услуг). Чтобы подготовить их правильно, рекомендуется использовать следующие исходные данные:
- описание файла метаданных (п. А.5 приложения А);
- шаблон файла метаданных (п. А.6 приложения А);
- требования вашей системы к типу учетной записи:
-- тип роли пользователя (физическое лицо, индивидуальный предприниматель, представитель юридического лица, должностное лицо государственной организации) - блок SupportedGlobalRoles и метаданных;
-- допустимый метод аутентификации (по паролю, по КЭП, усиленная аутентификация) - блок SupportedGlobalRoles метаданных;
-- допустимый уровень (статус) учетной записи (подтверждена или упрощенная/стандартная учетная запись) - блок SupportedAccTypes метаданных.
- требования вашей системы к перечню сведений о пользователе, которые нужно получать из ЕСИА в утверждениях SAML;
- сертификат ключа электронной подписи.
9. Синхронизировать системное время сервера, на котором установлена ваша система (поставщик услуг), со значением точного времени. Расхождение более чем в минуту может приводить к возникновению ошибок при взаимодействии поставщика услуг с поставщиком идентификации ЕСИА.
10. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом <9>.
--------------------------------
<9> Раздел 9 Регламента.
4 шаг: Ввести доработку в эксплуатацию
1. Осуществить регистрацию метаданных в промышленной ЕСИА в соответствии с Регламентом <10>.
--------------------------------
<10> Раздел 10 Регламента.
2. После регистрации метаданных проверить работу промышленной версии ЕСИА с промышленной версией вашей системы.
3.1.2 Аутентификация с использованием OpenID Connect 1.0
Регистрация ИС осуществляется согласно Регламенту (раздел 6).
При использовании способа аутентификации, основанного на OAuth 2.0 и расширения OpenID Connect, не требуется формирование метаданных.
Рекомендуемая последовательность действий:
1. Выпустить ключевой контейнер и сертификат ключа квалифицированной электронной подписи для подключаемой информационной системы (должен содержать ОГРН ЮЛ, являющегося оператором информационной системы).
Сертификат требуется для идентификации ИС при взаимодействии с ЕСИА. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012.
2. Сертификаты тестовой и продуктивной сред ЕСИА, используемые для формирования электронных подписей ответов как поставщика, доступны по ссылке http://esia.gosuslugi.ru/public/esia.zip.
3. Реализовать интерфейсы системы-клиента REST-сервисов ЕСИА и модели контроля доступа, основанной на OAuth 2.0. Детальная информация содержится в приложениях Б и В.
4. Доработать дизайн сайта, выбрав место для размещения кнопки "Войти через ЕСИА", и реализовать в системе логику запроса данных о пользователях, получаемых с помощью программного интерфейса ЕСИА. Недопустимо отображать страницу аутентификации ЕСИА во фрейме сайта.
5. Обеспечить в соответствии с требованиями законодательства комплекс мер, необходимых для обеспечения информационной безопасности и защиты персональных данных пользователей, получаемых информационной системой в процессе ее взаимодействия с системой ЕСИА.
6. Синхронизировать системное время сервера, на котором установлен поставщик услуг, со значением точного времени. Расхождение более чем в минуту может приводить к возникновению ошибок при взаимодействии поставщика услуг с поставщиком идентификации ЕСИА.
7. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом <11>.
--------------------------------
<11> Раздел 9 Регламента.
4 шаг: Ввести доработку в эксплуатацию
1. Осуществить подключение ИС к промышленной ЕСИА в соответствии с Регламентом <12>.
--------------------------------
<12> Раздел 10 Регламента.
2. После подключения ИС к промышленной ЕСИА проверить работу промышленной версии ЕСИА с промышленной версией вашей системы.
3.2 Рекомендуемые сценарии интеграции по SAML
3.2.1 Сценарии аутентификации пользователей через ЕСИА
Базовый сценарий аутентификации пользователя
Базовым сценарием является сценарий аутентификации физического лица (например, заявителя). Этот сценарий позволяет получить сведения об индивидуальном пользователе (физическом лице) в момент аутентификации и соответствует профилю Web Browser SSO Profile стандарта SAML 2.0. Сценарий включает следующие шаги:
1. Пользователь нажимает на странице системы поставщика услуг кнопку "Войти через ЕСИА".
2. Поставщик услуг формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на страницу аутентификации ЕСИА.
3. ЕСИА проверяет статус аутентификации пользователя. Если пользователь в ЕСИА не аутентифицирован, то для продолжения процесса он должен пройти аутентификацию одним из доступных способов. Если пользователь еще не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации.
4. Когда пользователь аутентифицирован, ЕСИА проверяет, что уровень достоверности идентификации пользователя соответствует требованиям системы, которые зафиксированы в метаданных.
5. Когда пользователь успешно аутентифицирован, ЕСИА передает в систему ответ на запрос аутентификации, который содержит набор утверждений SAML (SAML Assertions) о пользователе.
6. Поставщик услуг принимает решение об авторизации пользователя на основе полученной из ЕСИА информации.
Рисунок 3 - Идентификация и аутентификация пользователей
посредством ЕСИА при использовании SAML 2.0
Дополнительный сценарий аутентификации пользователя в качестве представителя организации
ЕСИА также позволяет аутентифицировать пользователя в качестве представителя:
Эта функция востребована системами, среди пользователей которых есть сотрудники организаций, например, выступающие как заявители услуг или как должностные лица ОГВ. Если включить эту функцию в метаданных поставщика услуг, то ЕСИА в ответе на запрос аутентификации будет передавать сведения об организации пользователя. Если пользователь является участником нескольких организаций, то ЕСИА предварительно попросит пользователя ту из них, от лица которой он осуществляет аутентификацию. Если система поддерживает работу пользователей с различными ролями, то в процессе аутентификации пользователь будет иметь возможность сделать выбор роли, в которой он будет работать в данной ИС.
Для проверки наличия у аутентифицированного сотрудника ЮЛ необходимых полномочий следует использовать функционал системных групп (4.2.2.3).
Для проверки наличия у аутентифицированного должностного лица необходимых полномочий рекомендуется использовать соответствующее SAML-утверждение (п. 4.3.3).
Сценарий с установкой локальной сессии
Как только пользователь прошел аутентификацию, ЕСИА устанавливает пользовательскую сессию, продолжительность которой составляет 3 часа. Факт начала сессии записывается в файле cookie, который хранится на компьютере пользователя. При закрытии пользователем браузера сессия автоматически завершается. Система может установить для пользователя свою "локальную" сессию. Рекомендуемая продолжительность сессии - от 15 минут до 3 часов. При завершении "локальной" сессии система должна направлять в ЕСИА новый запрос на аутентификацию.
Сценарий с авторизацией пользователя
Система ЕСИА обладает функционалом по предоставлению поставщику услуг информации, на основании которой возможно проведение авторизации аутентифицированного пользователя. Решение об авторизации пользователя принимает система, в которую пользователь авторизуется (Таблица 1).
Таблица 1 - Требования к авторизации пользователей
Требуется знать что-то о пользователе для одного сеанса работы (например, имя, которым подписывать комментарии пользователя). Нет необходимости хранить данные об активности пользователя до следующего сеанса | Давать доступ после получения из ЕСИА ответа на запрос аутентификации, содержащего требуемый набор сведений о пользователе |
Требуется знать что-то о пользователе (например, ФИО, email и др.) и длительно хранить пользовательский контекст (настройки, заявки, комментарии) | Давать доступ после получения из ЕСИА ответа на запрос аутентификации, содержащего требуемый набор сведений о пользователе. При первом входе пользователя регистрировать его идентификатор пользователя (userid). В дальнейшем хранить пользовательский контекст в привязке к этому идентификатору |
Требуется ограничить набор предоставляемых функций в зависимости от типа учетной записи, роли пользователя, использованного метода аутентификации | Давать доступ после получения из ЕСИА ответа на запрос аутентификации, содержащего требуемый набор сведений о пользователе. При попытке пользователя обратиться к функции, для предоставления которой текущие тип учетной записи пользователя, роль пользователя или метод аутентификации являются недостаточными, вывести ему сообщение с пояснениями по дальнейшим действиям. Рекомендуемые сообщения для различных ситуаций приведены в таблице 2. В главе 4.1.1 приведены сведения про типы учетных записей пользователей и роли пользователей |
В следующей таблице приведены рекомендации по проверке соответствия требованиям информационной системы типа учетной записи пользователя, роли пользователя и использованного метода аутентификации, а также даны рекомендации по сообщениям, которые стоит предоставить пользователям в случае несоответствия их требованиям системы, и приведены рекомендации по дальнейшим действиям.
Таблица 2 - Рекомендации по информированию пользователя
о несоответствии авторизации требованиям системы
Пользователь с учетной записью с типом упрощенная ("непроверенная") попытался обратиться к функциям, предоставляемым только для стандартных ("проверенных") и/или "подтвержденных" учетных записей | Проанализировать утверждение SAML с именем assuranceLevel или personTrusted (см. таблицу 5) | При доступе к функциям, требующим стандартной (проверенной) учетной записи: "Для доступа вам необходимо пройти процедуру проверки своих данных. Если ваши личные данные только что прошли проверку, то вам нужно войти в систему повторно." Ссылка на проверку данных: https://esia-portal1.test.gosuslugi.ru/validate При доступе к функциям, требующим подтвержденной учетной записи: "Для доступа вам необходимо пройти процедуру проверки своих данных и подтверждения личности. Если вы только что подтвердили свою личность, то вам нужно войти в систему повторно." Ссылка на проверку данных: https://esia-portal1.test.gosuslugi.ru/validate |
Пользователь с учетной записью с типом стандартная (проверенная) попытался обратиться к функциям, предоставляемым только для "подтвержденных" учетных записей | Проанализировать утверждение SAML с именем assuranceLevel (см. таблицу 5) | "Для доступа вам необходимо пройти процедуру подтверждения личности. Если вы только что подтвердили свою личность, то вам нужно войти в систему повторно." Ссылка на подтверждение личности: https://esia-portal1.test.gosuslugi.ru/confirm |
Пользователь с учетной записью с ролью физического лица попытался обратиться к функциям, предоставляемым только для ИП/должностных лиц ЮЛ/должностных лиц ОГВ | Проанализировать утверждение SAML с именем globalRole и orgType (см. таблицу 5) <13> | Если необходима роль сотрудника ЮЛ и текущая учетная запись имеет тип "подтверждена": "Для доступа вам необходимо войти в систему в качестве сотрудника юридического лица. Если вы являетесь руководителем юридического лица, вы также можете зарегистрировать учетную запись юридического лица" Ссылка для регистрации ЮЛ: https://esia-portal1.test.gosuslugi.ru/org Если необходима роль ИП и текущая учетная запись имеет тип "подтверждена": "Для доступа вам необходимо войти в систему в качестве индивидуального предпринимателя. Вы также можете зарегистрировать учетную запись индивидуального предпринимателя." Ссылка: https://esia-portal1.test.gosuslugi.ru/orgs Если необходима роль должностного лица ОГВ и текущая учетная запись имеет тип "подтверждена": "Для доступа вам необходимо войти в систему в качестве должностного лица органа государственной власти." Если пользователь имеет упрощенную (непроверенную)/стандартную (проверенную) учетную запись, то необходимо его проинформировать о необходимости подтверждения личности. Это является необходимым предварительным условием для возможности получения пользователем роли должностного лица ЮЛ, ОГВ или роли ИП |
Пользователь, аутентифицировавшийся по паролю, попытался получить доступ к функции, требующей аутентификации по электронной подписи <14> | Проанализировать утверждение SAML с именем authnMethod (см. таблицу 5) | "Для доступа вам необходимо использовать средство квалифицированной электронной подписи. Если у вас имеется средство электронной подписи, войдите заново, использовав это средство." После этого сообщения рекомендуется разместить кнопку вызова единого завершения сессии |
-------------------------------
<13> Если информационная система работает исключительно с учетными записями юридических лиц/государственных организаций, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, имеющие такую учетную запись (см. Приложение А.6). В этом случае если пользователь, присоединенный к организации, ранее аутентифицировался в ЕСИА как физическое лицо, но перешел в эту ИС, то ЕСИА обеспечит автоматическое переключение его роли на роль юридического лица (если требуется - попросит пользователя выбрать организацию, от которой ему требуется работать).
<14> Если информационная система требует исключительно аутентификации по электронной подписи, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, аутентифицированные таким образом (см. Приложение А.6). В этом случае ЕСИА самостоятельно обеспечит корректное информирование пользователя о необходимых шагах по получению доступа.
Следует учесть, что если информационная система направляет пользователя в "Профиль пользователя ЕСИА" для совершения некоторых операций (например, для выполнения проверок данных учетной записи), то после их выполнения пользователь не будет автоматически возвращен в ИС. В то же время если соответствующая операция может быть выполнена в течение одной сессии пользователя, то пользователю можно дать возможность вернуться в систему (см. п. 3.5).
3.2.2 Сценарий единого завершения сессии
В течение действия сессии пользователь может без повторной аутентификации войти в одну или несколько других систем, подключенных к ЕСИА. При возникновении необходимости в одновременном завершении сессии во всех системах используется соответствующий сценарий. Единое завершение сессии необходимо, например, при изменении данных аутентифицированного пользователя - в этом случае для получения информационными системами в утверждениях SAML обновленных данных пользователь должен совершить выход и повторную аутентификацию в ИС.
Единое завершение сессии выполняется в соответствии с профилем Single Logout стандарта SAML. Процесс инициируется пользователем при нажатии кнопки "Выход" в системе поставщика услуг, реализовавшего указанный сценарий. Информационная система не должна самостоятельно инициировать единое завершение сессии.
Сценарий включает следующие шаги:
1. Пользователь нажимает кнопку "Выход" в системе.
2. Система формирует и направляет в ЕСИА запрос на завершение сессии - <LogoutRequest>. Данный запрос требуется обязательно выполнять.
3. ЕСИА определяет остальных участников сессии. Остальные участники сессии - это все системы, в которые пользователь вошел через ЕСИА на протяжении текущей сессии. Если другие участники существуют, ЕСИА отправляет запрос <LogoutRequest> каждому из них.
4. Система, получившая <LogoutRequest>, завершает на своей стороне активную сессию пользователя (или проверяет, что сессия к этому моменту уже неактивна). Затем формирует и отправляет в ЕСИА ответ о том, что сессия завершена - <LogoutResponse>.
5. Когда все остальные участники корректно завершили свои сессии, ЕСИА формирует и отправляет ответ <LogoutResponse> системе, инициировавшей процедуру завершения сессии. Если какой-то из поставщиков услуг не смог завершить сессию, ЕСИА отображает пользователю веб-страницу, информирующую его о том, что процедура не может быть корректно завершена и что пользователю необходимо перезапустить браузер.
6. Система, инициировавшая процедуру завершения сессии, обрабатывает полученный от ЕСИА ответ. Например, перенаправляет пользователя на веб-страницу завершения сессии.
Основные используемые в ЕСИА форматы электронных сообщений SAML 2.0:
- запрос аутентификации (AuthnRequest);
- ответ на запрос аутентификации (AuthnResponse);
- запрос завершения активной сессии пользователя (LogoutRequest);
- ответ на запрос завершения активной сессии (LogoutResponse).
Детальное описание форматов этих электронных сообщений, а также требований к формированию метаданных для интеграции с ЕСИА, содержится в приложении А.
3.3 Рекомендуемый сценарий аутентификации при интеграции по OpenID Connect 1.0
Базовый сценарий аутентификации
Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица (например, заявителя).
Сценарий включает следующие шаги:
1. Пользователь нажимает на веб-странице системы-клиента кнопку "Войти через ЕСИА".
2. Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа.
3. ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь еще не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации.
4. Когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений.
5. Если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код.
6. Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код.
7. ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации.
8. Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным.
После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа (см. приложения Б и В).
Рисунок 4 - Идентификация и аутентификация пользователей
при использовании механизма OpenID Connect 1.0
Дополнительный сценарий аутентификации пользователя в качестве представителя организации
ЕСИА также позволяет аутентифицировать пользователя в качестве представителя организации, для этого ИС должна:
- запросить у ЕСИА не только маркер идентификации, но и маркер доступа (на получение данных пользователя);
- с использованием маркера доступа и программного интерфейса ЕСИА, основанного на REST, получить информацию о том, сотрудником каких организаций является пользователь;
- запросить у пользователя, от имени какой организации он будет работать в данной ИС (если пользователь является сотрудником нескольких организаций).
При необходимости ИС также может проверять, включен ли пользователь в необходимые системные группы юридического лица, является ли он руководителем организации.
Необходимо помнить, что выбор организации, от имени которой будет работать пользователь в ИС, должен происходить на стороне самой ИС с использованием ее средств.
Сценарий с установкой локальной сессии
Как только пользователь прошел аутентификацию, ЕСИА устанавливает пользовательскую сессию, продолжительность которой составляет 3 часа. Факт начала сессии записывается в файле cookie, который хранится на компьютере пользователя. При закрытии пользователем браузера сессия автоматически завершается. Система может установить для пользователя свою "локальную" сессию. Рекомендуемая продолжительность сессии - от 15 минут до 3 часов. При завершении "локальной" сессии система должна направлять в ЕСИА новый запрос на аутентификацию.
Сценарий с авторизацией пользователя
Система ЕСИА обладает функционалом по предоставлению системе-клиенту информации, на основании которой возможно проведение авторизации аутентифицированного пользователя. Решение об авторизации пользователя принимает система, в которую пользователь авторизуется.
Для получения авторизационных данных следует использовать программный интерфейс, основанный на архитектурном стиле REST (п. 4.3, приложение Б). В этом случае помимо маркера идентификации система должна также запросить маркер доступа к нужным авторизационным данным.
Получив маркер доступа, ИС может получить данные о пользователе и на их основе принять решение о предоставлении доступа пользователю к своим ресурсам.
3.4 Требования к визуальному оформлению входа посредством ЕСИА
При использовании ЕСИА для идентификации и аутентификации пользователей, а также для их регистрации, варианты размещения кнопок для входа могут различаться в зависимости от сценария использования ЕСИА:
- аутентификация исключительно посредством ЕСИА;
- аутентификация посредством ЕСИА в качестве одного из возможных вариантов аутентификации.
Независимо от выбранного сценария, при оформлении входа в систему с использованием ЕСИА не рекомендуется использовать слова "аутентификация" или "авторизация", вместо этого следует использовать слово "вход".
Если система производит аутентификацию по протоколу Open ID Connect 1.0, то имеется возможность проверить наличие у пользователя сессии в ЕСИА в фоновом режиме. Иными словами, кнопку "Вход" можно выводить только в том случае, если пользователь не имеет сессии, а если имеет - то произвести вход в систему автоматически <15>.
--------------------------------
<15> См. Приложение В.6.2.2.
3.4.1 Аутентификация исключительно посредством ЕСИА
Если системой используется аутентификация посредством ЕСИА в качестве единственного способа аутентификации, то в общем случае рекомендуется размещать кнопку "Вход" в верхней правой части ("в шапке") соответствующей страницы.
При нажатии на кнопку "Вход" должно происходить перенаправление пользователя на страницу аутентификации ЕСИА в соответствии с применяемым сценарием аутентификации.
3.4.2 Аутентификация посредством ЕСИА в качестве одного из возможных вариантов аутентификации
Если системой используется аутентификация посредством ЕСИА в качестве одного из возможных способов аутентификации, то рекомендуется размещать ссылку или кнопку "Вход через ЕСИА" в шапке соответствующего сайта, расположив ее рядом со ссылкой (кнопкой), позволяющей войти в систему при помощи альтернативного провайдера аутентификации.
3.5 Возврат пользователя в систему, вызвавшую профиль пользователя в ЕСИА или регистрацию пользователя в ЕСИА
Если ИС вызывает ЕСИА для проведения идентификации и аутентификации пользователя, то пользователь будет возвращен в систему сразу после проведения аутентификации. В то же время ИС может направить пользователя в ЕСИА со следующими целями:
- изменение данных в личном профиле (например, прохождение процедуры проверки данных пользователя);
- прохождение процедуры регистрации.
3.5.1 Возврат пользователей в систему, вызвавшую регистрацию в ЕСИА
После прохождения процедуры регистрации пользователь автоматически будет возвращен в ИС. Для возврата в ИС до окончания процедуры регистрации в ЕСИА пользователю необходимо воспользоваться стандартными средствами навигации браузера.
Чтобы ЕСИА вернула пользователя в систему после выполнения указанной операции, ИС при перенаправлении пользователя должна передать корректный контекст возврата. Контекст возврата определяется следующими параметрами:
- <cid> - мнемоника информационной системы, перенаправившей пользователя в ЕСИА;
- <rurl> - адрес, на который должен быть возвращен пользователь после совершения необходимых действий (этот адрес должен включать в себя URL системы, указанный в Технологическом портале);
- <imm> - признак, позволяющий определить необходимость возврата в систему после регистрации упрощенной учетной записи (при вызове страницы регистрации ЕСИА); возврат после регистрации упрощенной учетной записи будет произведен только при передаче признака со значением "true".
Пример ссылки с корректным контекстом возврата для процедуры регистрации:
https://esia-portal1.test.gosuslugi.ru/registration?cid=TESTSYS&rurl=http://test.ru&imm=true
3.5.2 Возврат пользователя в систему, вызвавшую профиль пользователя ЕСИА
В веб-приложении "Профиль пользователя ЕСИА" в течение действия пользовательской сессии браузера обеспечивается возможность пользователю перейти обратно в вызвавшую ЕСИА систему посредством нажатия на кнопку "Вернуться назад".
Чтобы ЕСИА вернула пользователя в систему после выполнения указанной операции, ИС при перенаправлении пользователя должна передать корректный контекст возврата. Контекст возврата определяется следующими параметрами:
- <cid> - мнемоника информационной системы, перенаправившей пользователя в ЕСИА;
- <rurl> - адрес, на который должен быть возвращен пользователь после совершения необходимых действий (этот адрес должен включать в себя URL системы, указанный в Технологическом портале).
Пример ссылки с корректным контекстом возврата:
https://esia-portal1.test.gosuslugi.ru/profile/user?cid=TESTSYS&rurl=http://test.ru
Следует помнить, что после закрытия пользователем браузера контекст возврата не будет сохранен.
Процессы и механизмы ведения данных регистров ЕСИА имеют свою специфику в зависимости от регистра и типа пользователя. Перечень механизмов и процессов представлен в таблице 3.
Таблица 3 - Основные механизмы ведения регистров ЕСИА
4.1.1 Регистрация физических лиц и получение ролей
В ЕСИА предусмотрены следующие роли пользователей:
- физические лица, имеющие учетную запись в регистре физических лиц ЕСИА;
- индивидуальные предприниматели, т.е. физические лица, имеющие признак индивидуального предпринимателя;
- должностные лица юридических лиц, т.е. физические лица, присоединенные в ЕСИА к учетным записям юридических лиц ЕСИА;
- должностные лица органов и организаций, т.е. физические лица, присоединенные в ЕСИА к учетным записям ОГВ.
Наличие у пользователя роли позволяет информационным системам, взаимодействующим с ЕСИА, использовать эту информацию для выполнения собственных процессов (например, для авторизации).
Пользователи могут иметь в ЕСИА одну или несколько ролей. Базовой является роль физического лица: чтобы получить одну из указанных ролей, пользователь должен быть первоначально зарегистрирован в качестве физического лица.
В ЕСИА предусмотрены учетные записи физических лиц следующих типов, каждый из которых соответствует определенному уровню идентификации пользователя:
- упрощенная (непроверенная) учетная запись (содержит минимальный набор данных о пользователе);
- стандартная (проверенная) учетная запись (данные о пользователе проверены в БГИР);
- подтвержденная учетная запись (данные о пользователе проверены в БГИР, а личность пользователя - физического лица подтверждена одним из доступных способов подтверждения).
Схематично связь между ролями и типами учетных записей физического лица отображена на рис. 5.
Рисунок 5 - Типы учетных записей и роли пользователя в ЕСИА
4.1.1.1 Регистрация учетной записи физического лица
Регистрация учетной записи физического лица возможна следующими способами:
1. Самостоятельная регистрация пользователя через веб-интерфейс. В этом случае пользователю самостоятельно нужно пройти следующие шаги:
- регистрация упрощенной (непроверенной) учетной записи пользователя (требуется указать фамилию, имя, один из возможных подтвержденных каналов коммуникации - мобильный телефон или адрес электронной почты);
- перевод учетной записи в состояние стандартной (проверенной) (включает в себя заполнение пользователем личных данных, инициирование процедуры проверки личных данных в БГИР и автоматическую верификацию личных данных в БГИР);
- перевод учетной записи в состояние подтвержденной (включает в себя подтверждение личности пользователя одним из доступных способов подтверждения - с помощью обращения в один из Центров обслуживания <16>, отправкой кода подтверждения личности по почте или с помощью КЭП).
--------------------------------
<16> Для подтверждения личности Центры обслуживания могут использовать соответствующий программный интерфейс ЕСИА (см. п. Г.3 приложения Г).
2. Регистрация пользователя в одном из Центров обслуживания, ИС которого осуществляет вызов операций с использованием программного интерфейса ЕСИА, опубликованного в СМЭВ. Детальная информация о программном интерфейсе ЕСИА размещена в приложении Г. В результате регистрации в Центре обслуживания пользователь сразу получает подтвержденную учетную запись ЕСИА.
Назначение всех ролей физического лица в ЕСИА осуществляется с помощью веб-интерфейса <17>.
--------------------------------
<17> Инициирование приглашения на присоединение пользователя к юридическому лицу или ОГВ возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.
Детальная информация о назначении основных ролей физического лица представлена в таблице 4.
Таблица 4 - Способы назначения ролей
Самостоятельно через веб-интерфейс ЕСИА с помощью направления заявки с данными ИП, включающей в себя: - ФИО; - ИНН физического лица; - ОГРНИП. Заявка проходит проверку в БГИР. Если в ЕГРИП действительно существует запись с указанными данными, то пользователь получает роль индивидуального предпринимателя | |
Получение роли должностного лица ЮЛ в ЕСИА происходит в результате: - регистрации ЮЛ в ЕСИА, в этом случае регистрирующий ЮЛ пользователь получает роль должностного лица ЮЛ с правами руководителя (см. п. 4.1.2); - приглашения руководителем или администратором профиля ЮЛ в ЕСИА сотрудника. Процедура приглашения сотрудника для присоединения к организации выполняется с помощью веб-интерфейса ЕСИА <18>. Включает в себя следующие шаги: 1. Руководитель или администратор учетной записи ЮЛ в ЕСИА формирует с помощью веб-интерфейса ЕСИА приглашение на присоединение к организации, включающее в себя: - адрес электронной почты пользователя; - ФИО пользователя; - СНИЛС пользователя (опционально). 2. ЕСИА отправляет на указанный адрес электронной почты пользователя приглашение со ссылкой для присоединения к организации. 3. Пользователь, имеющий подтвержденную учетную запись, входит в ЕСИА по ссылке в приглашении. Если его ФИО и СНИЛС совпадает с данными в приглашении, то он присоединяется к учетной записи ЮЛ. Физическое лицо получает роль должностного лица ЮЛ. | |
Получение роли должностного лица ОГВ в ЕСИА происходит в результате: - регистрации ОГВ в ЕСИА, в этом случае регистрирующий ОГВ пользователь получает роль должностного лица ОГВ с правами руководителя (см. п. 4.1.3); - приглашения руководителем или администратором профиля ОГВ в ЕСИА сотрудника. Процедура приглашения сотрудника для присоединения к ОГВ выполняется с помощью веб-интерфейса ЕСИА <19> и аналогична процессу присоединения сотрудника к учетной записи ЮЛ |
--------------------------------
<18> Инициирование приглашения на присоединение пользователя к юридическому лицу возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.
<19> Инициирование приглашения на присоединение пользователя к ОГВ возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.
Один пользователь ЕСИА может одновременно являться должностным лицом в нескольких ОГВ и ЮЛ, а также иметь роль одного индивидуального предпринимателя.
4.1.2 Регистрация юридических лиц
Регистрация ЮЛ (внесение записи в регистр ЮЛ) осуществляется с помощью веб-интерфейса ЕСИА. Создавать учетную запись ЮЛ можно только из подтвержденной учетной записи физического лица - руководителя организации или представителя юридического лица, имеющего право действовать от имени организации без доверенности.
Процедура регистрации ЮЛ из подтвержденной учетной записи пользователя включает в себя следующие шаги:
1. Переход во вкладку "Организации" профиля пользователя и инициирование процедуры регистрации.
2. Подключение средства электронной подписи. Для регистрации юридического лица требуется использовать квалифицированную электронную подпись, выданную на имя руководителя юридического лица или на лицо, имеющее право действовать от имени юридического лица без доверенности.
3. Заполнение формы с данными о юридическом лице и данными о руководителе организации. Основные поля предзаполнены, поскольку они были считаны из сертификата электронной подписи, необходимо указать лишь ряд дополнительных сведений об организации:
- организационно-правовую форму;
- адрес электронной почты организации.
Если в личных данных не был указан ИНН, то следует указать ИНН пользователя как физического лица (или отметить, что ИНН отсутствует).
4. Ожидание окончания автоматической проверки данных организации и руководителя организации в Федеральной налоговой службе. Если ошибок не возникнет, то юридическое лицо будет зарегистрировано, т.е. будет внесена запись в регистр ЮЛ. Руководитель ЮЛ, осуществлявший регистрацию ЮЛ, автоматически получит роль должностного лица данного ЮЛ и права руководителя.
В регистр органов и организаций ЕСИА могут быть включены только организации, подпадающие под действие Постановления Правительства Российской Федерации от 28 ноября 2011 г. N 977.
Регистрация ОГВ осуществляется с помощью единого веб-интерфейса ЕСИА, предусмотренного и для ЮЛ. Специфика заключается в том, что руководитель ОГВ при регистрации в качестве типа своей организации указывает "Государственный орган или организация", указывает свою территориальную принадлежность и выбирает свое ведомство, подтверждающее статус регистрирующейся организации как ОГВ.
После выполнения проверок данных организации формируется запрос в ведомство, подтверждающее статус регистрирующейся организации как ОГВ. Если данное ведомство подтверждает, что организация имеет статус ОГВ, то учетной записи будет присвоен этот признак и она будет включена в регистр ОГВ. Если не подтверждает, что организация будет иметь учетную запись юридического лица (без признака ОГВ).
4.1.4 Регистрация информационных систем
Регистрация ИС выполняется организацией, являющейся оператором данной ИС. Эта организация предварительно должна быть зарегистрирована в ЕСИА.
В ЕСИА должны быть зарегистрированы ИС, которые:
- используют ЕСИА как поставщик идентификации (Identity Provider) для идентификации и аутентификации пользователей;
- используют ЕСИА в качестве поставщика ресурса (для интеграции по REST и OAuth 2.0);
- осуществляют регистрацию пользователей в ЕСИА.
Для регистрации ИС можно воспользоваться функцией Технологического портала ЕСИА <20>.
--------------------------------
<20> Раздел 6 Регламента.
4.1.5 Регистрация системных групп
Для систем, интегрированных с ЕСИА, имеется возможность проверять наличие у пользователей специфических полномочий по доступу к этой системе. Данная возможность обеспечивается в ЕСИА посредством механизма системных групп (групп доступа) - для проведения авторизации сотрудников организаций (ЮЛ или ОГВ). Оператор ИС может зарегистрировать одну или несколько системных групп, которые будут доступны организации; уполномоченные сотрудники организаций смогут включать/исключать своих сотрудников с помощью веб-интерфейса ЕСИА (см. п. 4.2.2.3). После аутентификации данные о принадлежности сотрудника организации к системным группам данной ИС будут переданы в SAML-утверждениях, а также доступны с помощью программного интерфейса, основанного на архитектуре REST.
Регистрацию системных групп можно осуществлять с помощью Технологического портала ЕСИА, при условии, что данной организации предоставлено право создания собственных системных групп.
В ЕСИА предусмотрены следующие типы групп доступа:
- публичная - доступная для назначения всем организациям. Уполномоченный сотрудник организации (не являющейся владельцем группы) всегда может включать в эту группу сотрудников своей организации;
- ограниченно доступная (приватная) группа для ОГВ - доступная всем организациям, имеющим признак ОГВ;
- ограниченно доступная (приватная) - доступная организациям только с разрешения владельца системной группы. Уполномоченный сотрудник организации может включать в эту группу сотрудников своей организации только после получения организацией прав доступа со стороны организации - владельца системной группы.
Организация - владелец ограниченно доступной группы может предоставить организации доступ к группе в следующих режимах:
- с возможностью свободного включения в группу сотрудников;
- с включением в группу сотрудников только с персональным согласованием этого включения со стороны организации - владельца этой группы. В этом случае добавление сотрудника в группу с помощью веб-интерфейса или программного интерфейса влечет за собой направление запроса в учетную запись организации - владельца группы для его рассмотрения; только после согласования запроса со стороны организации-владельца сотрудник будет добавлен в группу.
4.2.1 Управление данными физических лиц
Управление данными пользователя - физического лица осуществляется им самостоятельно с помощью веб-интерфейса ЕСИА. Доступ к профилю пользователя осуществляется по ссылке:
https://esia-portal1.test.gosuslugi.ru/profile/user/
К персональным данным, размещенным в ЕСИА, относятся:
- реквизиты удостоверяющего личность документа (только для стандартной (проверенной) и подтвержденной учетной записи);
- гражданство (только для стандартной (проверенной) и подтвержденной учетной записи).
- СНИЛС (только для стандартной (проверенной) и подтвержденной учетной записи);
- ИНН (только для подтвержденной учетной записи).
- государственный регистрационный знак транспортного средства и реквизиты свидетельства о регистрации транспортного средства.
Процедура редактирования ряда полей различается в зависимости от того, является ли учетная запись пользователя упрощенной (непроверенной), стандартной (проверенной) или подтвержденной. Для стандартной (проверенной) и подтвержденной учетной записи изменение ряда полей возможно только после проверки этих данных в БГИР. До тех пор, пока данные не будут подтверждены, изменение данных не произойдет.
Для стандартной (проверенной) и подтвержденной учетной записи изменение основных данных возможно только при наличии подтвержденного номера мобильного телефона.
4.2.2 Управление данными юридических лиц
Управление данными ЮЛ осуществляется самостоятельно руководителем или администратором профиля ЮЛ с помощью веб-интерфейса ЕСИА <21>. Доступны следующие функции:
--------------------------------
<21> Также возможно управление данными организации с помощью программного интерфейса на основе REST (см. Приложение Б).
- управление идентификационными данными ЮЛ;
- управление принадлежностью сотрудников к системным группам (группам доступа).
Войти в профиль организации ЕСИА и управлять данными организации может только уполномоченный сотрудник - т.е. пользователь, который является руководителем организации, выполнившим регистрацию организации, или который включен в группу администраторов профиля ЕСИА.
4.2.2.1 Управление идентификационными данными ЮЛ
Уполномоченный сотрудник имеет возможность редактировать следующие данные ЮЛ:
- организационно-правовая форма;
4.2.2.2 Управление сотрудниками ЮЛ
Уполномоченный сотрудник с помощью веб-интерфейса ЕСИА имеет возможность просмотреть перечень сотрудников, т.е. пользователей, присоединенных к организации. Также он имеет возможность:
- отредактировать следующие данные сотрудника:
- служебный адрес электронной почты;
- отправить приглашение пользователю для его присоединения к организации (см. п. 4.1.1.2), а также исключить сотрудника из организации. При исключении сотрудника ЕСИА удаляет пользователя из всех системных групп и исключает сотрудника из ЮЛ, при этом учетная запись сотрудника не удаляется из регистра физических лиц <22>.
--------------------------------
<22> Бывший сотрудник ЮЛ может продолжать использовать свою учетную запись ЕСИА, например, для получения государственных услуг в электронном виде.
4.2.2.3 Управление принадлежностью сотрудников к системным группам
Для регулирования доступа сотрудников к интегрированным с ЕСИА информационным системам уполномоченный сотрудник организации имеет возможность с помощью веб-интерфейса ЕСИА включать и исключать сотрудников из системных групп <23>.
--------------------------------
<23> Если соответствующими информационными системами предусмотрены группы доступа (системные группы), см. п. 4.1.5.
Группы доступа (системные группы) связаны с информационными системами, доступ к которым они регулируют. Если сотрудник организации был включен в системную группу, то соответствующие данные сможет обрабатывать ИС-владелец данной системной группы: информация о принадлежности к системной группе будет передана в утверждениях SAML, а также может быть получена с помощью программного интерфейса, основанного на архитектурном стиле REST.
Общая схема взаимодействия выглядит следующим образом:
1. ОГВ регистрирует в ЕСИА информационную систему (ИС-1), доступ к которой должны получать представители организаций, зарегистрированных в ЕСИА. При регистрации ИС-1 данный ОГВ определяет название соответствующей системной группы (см. п. 4.1.4), например "группа 1".
2. Уполномоченный сотрудник организации использует веб-интерфейс ЕСИА для просмотра существующих групп доступа. Находит группы доступа, связанные с системой ИС-1, и видит, что в этом перечне появилась "группа-1" <24>.
--------------------------------
<24> Если это публичная группа или ограниченно доступная группа, доступ к которой предоставлен данной организации.
3. Уполномоченный сотрудник ЮЛ добавляет в "группу-1" сотрудников организации, которым он разрешает действовать в ИС-1 от имени ЮЛ.
4. Сотрудник ЮЛ, включенный в системную группу "группа-1", аутентифицируется с помощью ЕСИА в ИС-1.
5. ИС-1 получает среди SAML-утверждений информацию о том, что пользователь включен в "группу-1" (для этого анализирует утверждение memberOfGroups - см. п. А.5 приложения А), и принимает положительное решение о доступе пользователя к своим ресурсам.
6. Если другая интегрированная с ЕСИА ИС-2 при аутентификации обрабатывает SAML-утверждение о принадлежности пользователя к группам, то она не увидит информацию о "группе-1", потому что данная ИС-2 не является владельцем этой группы.
4.2.2.4 Управление филиалами ЮЛ
Уполномоченный сотрудник с помощью веб-интерфейса ЕСИА имеет возможность просмотреть перечень филиалов организации, зарегистрировать новый филиал, а также:
- управлять сотрудниками филиала и их данными;
- управлять принадлежностью сотрудников филиала к группам.
Указанные операции с филиалами аналогичны соответствующим операциям с учетными записями организаций.
Управление данными ОГВ осуществляется по аналогии с управлением обычными организациями - юридическими лицами, т.е. с помощью веб-интерфейса ЕСИА.
Управление данными ОГВ включает в себя:
- управление должностными лицами ОГВ;
- управление полномочиями должностных лиц ОГВ;
4.2.3.1 Управление должностными лицами ОГВ
Добавление должностных лиц осуществляется в результате выполнения операции приглашения пользователей - физических лиц, имеющих подтвержденную учетную запись ЕСИА. Этот процесс может выполняться с помощью веб-приложения "Профиль организации ЕСИА" по аналогии с управлением сотрудниками ЮЛ.
4.2.3.2 Управление полномочиями должностных лиц ОГВ
Полномочия должностного лица регулируются при помощи механизма системных групп. Выполняется по аналогии с тем, как это реализуется у юридических лиц, не имеющих признака ОГВ (см. п. 4.2.2.3).
4.2.3.3 Управление филиалами ОГВ
Управление филиалами ОГВ выполняется по аналогии с тем, как это реализуется у юридических лиц, не имеющих признака ОГВ (см. п. 4.2.2.4).
Изменение данных ИС осуществляется в соответствии с Регламентом. Уполномоченный сотрудник оператора ИС имеет также возможность с помощью веб-приложения "Технологический портал ЕСИА" осуществлять следующие действия:
- загружать и удалять сертификаты ИС;
- редактировать системные группы (при наличии необходимого полномочия у соответствующей организации).
Информационная система, подключенная к ЕСИА с целью идентификации и аутентификации, получает информацию о субъектах, данные о которых хранятся в регистрах ЕСИА. С этой целью в ЕСИА предусмотрены следующие программные интерфейсы:
1. Программный интерфейс на основе SAML 2.0. ИС, интегрированная с ЕСИА, получает данные пользователя на момент его аутентификации в ЕСИА. Детальная информация об использовании этого программного интерфейса представлена в приложении А.
2. Программный интерфейс на базе архитектурного стиля "Representational State Transfer" (REST). Он позволяет интегрированным с ЕСИА информационным системам получать доступ к хранящимся в ЕСИА данным в произвольный момент времени после предварительного получения разрешения от пользователя <25>. Обеспечивается доступ к следующим данным:
--------------------------------
<25> За исключением получения данных об ИС (см. п. Б.7 приложения Б и п. В.3 приложения В).
- данные о пользователе (идентификационные данные, данные о транспортных средствах, данные о вхождении в организации);
- данные об организациях (идентификационные данные, данные о сотрудниках);
- данные об информационных системах (идентификационные данные, данные об организации-владельце).
Детальная информация об использовании этого программного интерфейса представлена в Приложениях Б и В <26>.
--------------------------------
<26> Порядок подключения к ЕСИА с целью использования программных интерфейсов описан в п. 9 - 10 Регламента.
4.3.1 Особенности получения данных физических лиц
Получать данные физических лиц (с любыми ролями, за исключением должностных лиц ОГВ) можно с помощью программных интерфейсов, основанных на SAML 2.0 и REST.
Получение данных физических лиц, имеющих роль должностного лица ОГВ, возможно с помощью программных интерфейсов, основанных на SAML 2.0.
При получении данных физических лиц с помощью интерфейса, основанного на SAML 2.0, следует принимать во внимание следующие особенности:
- ИС получает данные пользователя на момент его аутентификации, как результат, если данные о пользователе менялись в течение одной сессии, то ИС сможет получить их только после повторной аутентификации пользователя;
- ИС имеет возможность получать только те данные, которые были определены на стадии подключения ИС к ЕСИА (см. п. 3.1.1).
При получении данных физических лиц с помощью интерфейса, основанного на архитектуре REST, следует принимать во внимание следующие особенности:
- ИС получает доступ к данным о пользователе только после явного разрешения со стороны пользователя. У пользователя имеется возможность впоследствии отозвать это разрешение;
- для получения данных о пользователе нет необходимости интегрироваться с ЕСИА по протоколу SAML для аутентификации пользователей.
4.3.2 Особенности получения данных юридических лиц
При получении данных юридических лиц с помощью интерфейса, основанного на SAML 2.0, следует принимать во внимание следующие особенности:
- ИС может получать только данные об одном ЮЛ, в котором состоит физическое лицо, прошедшее аутентификацию (пользователь выбрал ЮЛ, от имени которой будет действовать в данной ИС).
При получении данных юридических лиц с помощью интерфейса, основанного на REST, следует принимать во внимание следующие особенности:
- возможно получение общих данных обо всех ЮЛ, сотрудником которых является данное физическое лицо.
- полный доступ к данным ЮЛ может дать только уполномоченный сотрудник ЮЛ (например, его руководитель), обычный сотрудник ЮЛ может дать разрешение на просмотр лишь ограниченного объема данных.
Схема получения данных о принадлежности сотрудника к системным группам представлена в п. 4.2.2.3.
4.3.3 Особенности получения данных ОГВ и полномочий должностных лиц
Данные об ОГВ могут быть получены с помощью программного интерфейса, основанного на протоколе SAML (в рамках получения данных о должностных лицах ОГВ, аутентифицированных через ЕСИА, см. п. 4.3.1).
Если ИС производит идентификацию и аутентификацию должностных лиц ОГВ с помощью ЕСИА и у нее возникает необходимость проверять наличие у пользователя специфических полномочий, то рекомендуется использовать утверждения SAML systemAuthority (см. Приложение А).
4.3.4 Особенности получения данных ИС
Получать данные об интегрированных с ЕСИА информационных системах можно только посредством программных интерфейсов, основанных на архитектурном стиле REST (см. п. Б.7 приложения Б).
Чтобы система могла быть идентифицирована средствами ЕСИА, она должна загрузить в ЕСИА свой сертификат (см. п. 4.2.4).
Чтобы система могла производить идентификацию ИС через ЕСИА, она должна предварительно получить разрешение на вызов соответствующего REST-сервиса ЕСИА. Необходимость получать данные об ИС должна быть указана в Заявке на создание записи регистра информационных систем в ЕСИА (среди целей подключения ИС в ЕСИА) <27>.
--------------------------------
<27> См. раздел 6 Регламента.
ЕСИА В ЦЕЛЯХ ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ ПОСРЕДСТВОМ
СТАНДАРТА SAML 2.0
А.1 Общие сведения о стандарте SAML 2.0
Взаимодействие ИС с ЕСИА с целью идентификации и аутентификации осуществляется посредством электронных сообщений, основанных на стандарте SAML 2.0.
SAML 2.0 - основанный на XML стандарт по обмену информацией (утверждениями) об аутентификации и авторизации между доверенными доменами безопасности.
Основными компонентами SAML 2.0 являются:
1. Утверждение - информация о подлинности, атрибутах и назначениях;
2. Протокол - правила формирования запросов и ответов в процессе взаимодействий через SAML 2.0.
3. Связывание - отображение протокол SAML 2.0 на транспортные протоколы связи и передачи сообщений;
4. Профиль - сочетание утверждений, протоколов и связываний для поддержки конкретного сценария взаимодействия.
Рисунок 6 - Основные компоненты SAML 2.0
SAML 2.0 определяет синтаксис и семантику утверждений, относящихся к аутентификации, атрибутам и авторизационной информации. Определены следующие типы утверждений:
- утверждение по аутентификации - определяет, что данный субъект прошел аутентификацию определенным способом в определенный момент времени;
- утверждение по авторизации - определяет, на какие действия авторизован конкретный субъект;
- утверждение по атрибутам - определяет специфическую информацию о конкретном субъекте.
SAML 2.0 определяет способ передачи утверждений в протоколах. В ЕСИА используются следующие протоколы SAML 2.0 типа запрос/ответ:
- Authentication Request Protocol (протокол запроса аутентификации) - определяет способы, которыми аутентифицированный субъект может запросить утверждения, содержащие аутентификационные данные и атрибуты субъекта;
- Single Logout Protocol (протокол единого выхода) - определяет механизм одновременного завершения активных сессий, ассоциированных с аутентифицированным субъектом. Выход может инициироваться пользователем или поставщиком идентификации.
Связывания SAML 2.0 определяют, как различные сообщения протоколов SAML 2.0 могут передаваться поверх транспортных протоколов (например, SOAP, HTTP). В ЕСИА используются следующие связывания SAML 2.0:
- HTTP Redirect - определяет, как сообщения протокола SAML 2.0 могут передаваться, используя сообщения HTTP Redirect (ответы с кодом состояния 302);
- HTTP POST - определяет, как сообщения протокола SAML 2.0 могут передаваться с использованием сообщений HTTP POST.
Профили SAML 2.0 определяют, какие утверждения, протоколы и связывания SAML 2.0 могут использоваться в конкретных вариантах использования. В ЕСИА используются следующие профили SAML 2.0:
- Web Browser SSO - определяет, как реализовать однократную аутентификацию в стандартных веб-браузерах;
- Single Logout - определяет, как выполнить одновременный выход из всех сессий.
Как правило, поставщику услуг требуется детальная информация о результатах проведенной аутентификации. Эта информация содержится в контексте аутентификации, передаваемом в утверждениях SAML 2.0. Аутентификационный контекст (authentication context) определяет синтаксис для описания механизмов аутентификации.
А.2 Общие рекомендации по реализации интерфейсов поставщика услуг
Для реализации интерфейсов поставщика услуг можно использовать уже разработанные различные реализации поставщиков услуг с открытым кодом. Одним из таких поставщиков услуг является OIOSAML, реализованный под различные платформы. Различные реализации OIOSAML можно посмотреть на информационном ресурсе http://digitaliser.dk/group/42063/resources.
Примечание. В сборки последних версий OIOSAML разработчики стали включать библиотеки OpenSAML, которые несовместимы с ЕСИА. В настоящий момент с ЕСИА совместима версия 2.4.1. OpenSAML. Скачать данную версию можно по ссылке: http://www.shibboleth.net/downloads/java-opensaml/2.4.1.
Еще одним возможным вариантом реализации поставщика услуг для сред PHP является SimpleSAMLphp. Более подробную информацию о SimpleSAMLphp можно получить на информационном ресурсе http://simplesamlphp.org.
При самостоятельной реализации интерфейсов поставщика услуг на Java или C++ одним из возможных вариантов является использование набора библиотек с открытым кодом OpenSAML (строго версии 2.4.1), который поддерживает работу со спецификациями SAML версии 1.0, 1.1 и 2.0. Подробную информацию о библиотеках OpenSAML можно посмотреть на информационном ресурсе https://wiki.shibboleth.net/confluence/display/OpenSAML/Home. Примеры кода по использованию OpenSAML для Java приведены в разделе А.7.
А.3 Общие требования к реализации интерфейса поставщика услуг
Интерфейсы поставщика услуг должны соответствовать следующим профилям SAML 2.0:
- Web Browser SSO с учетом рекомендаций Interoperable SAML 2.0 Web Browser SSO Deployment Profile.
Запрос к системе ЕСИА от информационной системы на идентификацию и аутентификацию пользователя должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:
- алгоритм c14n для каноникализации сообщения в формате XML;
Ответ с результатами идентификации и аутентификации пользователя, сформированный системой ЕСИА, подписывается с помощью закрытого ключа системы ЕСИА и преобразуется с использованием открытого ключа информационной системы. При этом используются следующие алгоритмы:
- алгоритм c14n для каноникализации сообщения в формате XML;
Запрос к системе ЕСИА от ИС на завершение активной сессии пользователя должен осуществляться из браузера пользователя и должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:
В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.
Запрос от системы ЕСИА к ИС на завершение активной сессии пользователя подписывается с использованием закрытого ключа системы ЕСИА. При этом используются следующие алгоритмы:
В качестве протокола доставки используется метод связывания HTTP-redirect.
Ответ с результатами завершения активной сессии пользователя от информационной системы к системе ЕСИА должен быть подписан с помощью закрытого ключа информационной системы с использованием следующих алгоритмов:
В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.
Ответ с результатами завершения активной сессии пользователя от системы ЕСИА к информационной системе передается подписанным с помощью закрытого ключа системы ЕСИА с использованием следующих алгоритмов:
В качестве протокола доставки используется метод связывания HTTP-redirect.
А.4 Описание форматов электронных сообщений SAML 2.0 в ЕСИА
В данном разделе описываются следующие протоколы SAML 2.0, используемые ЕСИА при формировании электронных сообщений:
- протокол запроса аутентификации;
Запрос аутентификации (AuthnRequest)
Запрос аутентификации (AuthnRequest) представляет собой XML-документ, который содержит следующие элементы:
1. saml2p:AuthnRequest - описывает параметры запроса AuthnRequest и содержит следующие атрибуты:
- AssertionConsumerServiceURL - URL провайдера услуг, предназначенный для обработки ответов от поставщика идентификации (необязательный);
- Destination - URL-адрес ИС-поставщика идентификации, предназначенный для обработки AuthnRequest;
- ID - уникальный идентификатор сообщения;
- IssueInstant - дата создания запроса;
- ProtocolBinding - используемая SAML привязка.
2. saml2:Issuer - идентификатор поставщика услуг, отправившего AuthnRequest (является вложенным по отношению к элементу saml2p:AuthnRequest).
Рисунок 7 - Структура AuthnRequest
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://atc-
504:7002/oiosaml/saml/SAMLAssertionConsumer"
Destination="https://esia-
portal1.test.gosuslugi.ru/idp/profile/SAML2/Redirect/SSO"
ForceAuthn="false"
ID="_054240e4-b2a8-48e9-b4c6-e0b5e84d3a35"
IsPassive="false"
IssueInstant="2012-02-28T06:43:35.704Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST"
Version="2.0">
<saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">sia_test</saml2:Issuer>
</saml2p:AuthnRequest>
Для сгенерированного SAML 2.0 сообщения с запросом AuthnRequest должно быть выполнено связывание (binding) с протоколом HTTP по методу HTTP-Redirect с учетом следующих особенностей:
- сообщение подписывается с помощью электронной подписи поставщика услуг, причем подписана должна быть строка запроса на аутентификацию пользователя;
- подписанное сообщение сжимается и кодируется в кодировке Base64.
В процессе связывания формируется конечный URL AuthnRequest, который в качестве GET-параметров должен содержать:
- SAMLRequest - AuthRequest в конечном виде;
- SigAlg - алгоритм подписи запроса, с помощью которого выполнялась подпись запроса аутентификации;
- Signature - подпись, полученная в результате подписания запроса аутентификации.
portal1.test.gosuslugi.ru/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJBa%2BMwEIX%2FitBdlqzYWyPilLSlbK
FLQ%2BzuYS9FkSepwJGyGtn051dxEtpS6EUg9Oabmfc0v37b92SEgNa7muaZoASc8Z11u5o%2Bt%2FesoteLOep9Lw9qOcRXt4b%2FA
2AkqdChOr3UdAhOeY0WldN7QBWNapZ%2FHpXMhDoEH73xPSVLRAgxtbr1Doc9hAbCaA08rx9r%2BhrjARXnOhpWikJdCSG5t%2F7Ygk
%2FHkfgNQcldGsc6HacVLhS0mnUwZrDzY6YjM0d5n3S7LAzcdgeextraHiaq5GvobAATedM8UXLvg4Fp3ZpudY9AycNdTV9EIcy22JR
sVpYVK%2FIrzTYm75j%2BVVVFJTeiK02S4koj2hE%2BihEHeHAYtYs1lSKXTEgmq1ZUKp%2BpvMhmVfGPktXZqhvrThH85OvmJEL1u2
1XbPXUtJT8vUSZBPQcnJq6h8%2BJ%2FQzWF4%2FpItn4EpO%2Fc%2F4ZtThfv36JxTs%3D&RelayState=_12db488a-a516-41e3-
801c-3e8f23547314&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig%23rsa-
sha1&Signature=k1XL2WfE1KMHzaJtjjaL2O1soweYNM06Xt50E20QgwRzVOBZ0T79HJEjPMu3jBhDdmM47zlrswbhUFPV22oDbk5K
uXJ%2F5FVPwXCTefnVCZGXHU8b1SWuC%2FoKlTSxum6enoommHN5S%2FeYAP9S0KNNW5yEP3eJQHkcsTYuTKPmyP8%3D
Ответ на запрос аутентификации (AuthnResponse).
В случае успешной аутентификации поставщик идентификации формирует ответ на запрос аутентификации - AuthnResponse, который содержит утверждение (Assertion) об аутентификации. AuthnResponse представляет собой XML-документ со следующей структурой:
Рисунок 8 - Структура AuthnResponse
Элементы saml2:Issuer и saml2:Signature содержат идентификатор поставщика идентификации и электронную подпись, созданную с помощью сертификата поставщика идентификации.
Элемент saml2:Subject содержит информацию о AuthnRequest, которому соответствует данный AuthnResponse, и представляет собой следующую структуру:
Рисунок 9 - Структура saml2:Subject
Элемент saml2:NameID содержит уникальный идентификатор, присвоенный поставщиком идентификации соответствующему AuthnRequest.
Элемент saml2:SubjectConfirmationData содержит набор атрибутов, в том числе:
- InResponseTo - содержит идентификатор AuthnRequest (соответствует значению атрибута ID);
- NotOnOrAfter - содержит дату, до которой данный AuthnRequest действителен.
- Recipient - URL обработчика AuthnResponse (соответствует значению AssertionConsumerServiceURL).
Элемент saml2:Condition содержит описание условий, при которых данный AuthnResponse считается действительным. Данный элемент имеет два атрибута - NotBefore и NotOnOrAfter, которые указывают на временной промежуток, в который данный AuthnResponse действителен. Также saml2:Condition имеет вложенный элемент saml2:AudienceRestriction, который содержит элемент saml2:Audience с указанием уникального идентификатора поставщика услуг (entity_id). Уникальный идентификатор системы в ЕСИА (entity_id) не должен содержать символов кириллицы.
Элементы saml2:AuthnStatement и saml2:AttributeStatement содержат информацию о результатах аутентификации.
Элемент saml2:AuthnStatement имеет два атрибута:
- AuthnInstant - дата аутентификации;
- SessionIndex - уникальный идентификатор сессии пользователя (с помощью него, например, выполняется повторная аутентификация и операция Logout).
Элемент saml2:AttributeStatement содержит атрибуты пользователя и имеет следующую структуру:
Рисунок 10 - Структура saml2:AttributeStatement
Элемент saml2:Attribute имеет три атрибута:
- FriendlyName - сокращенное наименование атрибута;
- Name - полное наименование атрибута;
- NameFormat - формат полного наименования атрибута.
Элемент saml2:AttributeValues состоит из двух атрибутов: xmlns:xsi и xsi:type. Эти атрибуты определяют формат значения атрибута пользователя.
Пример AuthnResponse приведен в разделе А.9.
Запрос завершения активной сессии пользователя (LogoutRequest)
Запрос завершения активной сессии (LogoutRequest) представляет собой XML-документ со следующей структурой:
Рисунок 11 - Структура LogoutRequest
Завершение активной сессии пользователя может быть инициировано как со стороны поставщика услуг, так и со стороны поставщика идентификации. В случае, если завершение сессии инициирует поставщик услуг, то LogoutRequest должен содержать обязательный элемент saml2:SessionIndex.
Элемент saml2:LogoutRequest имеет следующие атрибуты:
- Destination - содержит URL обработчика LogoutRequest. В случае если завершение сессии инициировано поставщиком услуг, то содержит URL поставщика идентификации, и наоборот, если инициирован поставщиком идентификации - то URL SP.
- ID - содержит уникальный идентификатор сообщения.
- IssueInstant - дата формирования сообщения.
- Reason - присутствует в случае инициализации завершения сессии со стороны поставщика услуг.
Элемент saml2:Issuer в качестве значения содержит идентификатор (entity_id) инициатора завершения сессии - либо поставщика услуг, либо поставщика идентификации.
Элемент saml2:NameID в качестве значения содержит уникальный идентификатор, присвоенный поставщиком идентификации соответствующему AuthnRequest.
Элемент saml2:SessionIndex содержит уникальный идентификатор пользователя, созданный при аутентификации.
Запрос на завершение сессии должен производиться из браузера (от имени пользователя). В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.
Примеры запроса завершения сессии:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://esia-portal1.test.gosuslugi.ru/idp/profile/SAML2/Redirect/SLO"
ID="_f51e2082-f899-476d-b88b-6dc743cb4969"
IssueInstant="2012-03-01T13:46:01.984Z"
Reason="urn:oasis:names:tc:SAML:2.0:logout:user"
Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Issuer>sia_test</saml2:Issuer>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
_4b58555ef34da11fae0aa08e8987dbb3
</saml2:NameID>
<saml2p:SessionIndex>
86e46a8d455acd02f5a9ef4072f7b66c46b4422bfc38631aa6e50b8d3f032c43
</saml2p:SessionIndex>
</saml2p:LogoutRequest>
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://atc-504:7002/oiosaml/saml/LogoutServiceHTTPRedirect"
ID="_5741a3cde023a8a669dd720e283642df"
IssueInstant="2012-03-01T13:51:41.711Z"
Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
https://esia-portal1.test.gosuslugi.ru/idp/shibboleth
</saml2:Issuer>
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
_4b58555ef34da11fae0aa08e8987dbb3
</saml2:NameID>
</saml2p:LogoutRequest>
Ответ на запрос завершения активной сессии (LogoutResponse)
Ответ на запрос завершения активной сессии (LogoutResponse) представляет собой XML-документ со следующей структурой:
Рисунок 12 - Структура LogoutResponse
Элемент saml2:LogoutResponse имеет следующие атрибуты:
- Destination - содержит URL обработчика LogoutResponse. В случае если завершение сессии инициировано поставщиком услуг, то содержит URL поставщика идентификации, и наоборот, если инициирован поставщиком идентификации - то URL поставщика услуг.
- ID - содержит уникальный идентификатор сообщения.
- InResponseTo - содержит идентификатор LogoutRequest.
- IssueInstant - дата формирования сообщения.
Элемент saml2:Issuer, в зависимости от инициатора завершения сессии, в качестве значения содержит идентификатор (entity_id) инициатора завершения сессии - либо поставщика услуг, либо поставщика идентификации.
Элемент saml2p:Status имеет вложенный элемент saml2p:StatusCode, имеющий атрибут Value, в качестве значения которого передается статус операции.
При этом ответ на запрос завершения сессии не содержит параметр RelayState, переданный изначально при аутентификации пользователя.
Примеры ответа на запрос завершения сессии:
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://atc-504:7002/oiosaml/saml/LogoutServiceHTTPRedirectResponse"
ID="_a0b3a5b88cf9b96d509ee7b9d497f693"
InResponseTo="_f51e2082-f899-476d-b88b-6dc743cb4969"
IssueInstant="2012-03-01T13:45:41.041Z"
Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://esia-portal1.test.gosuslugi.ru/idp/shibboleth
</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
</saml2p:LogoutResponse>
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:LogoutResponse xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="https://esia-portal1.test.gosuslugi.ru/idp/profile/SAML2/POST/SLO"
ID="_472d992a-1e50-40ef-8207-fb556eee4893"
InResponseTo="_5741a3cde023a8a669dd720e283642df"
IssueInstant="2012-03-01T13:52:08.177Z"
Version="2.0">
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
sia_test
</saml2:Issuer>
<saml2p:Status>
<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</saml2p:Status>
</saml2p:LogoutResponse>
А.5 Описание метаданных поставщика услуг
Метаданные поставщика услуг определяют способ описания конфигурационных данных (например, URL конечных точек веб-служб, ключи для проверки ЭП). Для описания метаданных ИС поставщика услуг используется язык XML. Структура файла метаданных ИС поставщика услуг приведена на рисунке 13.
Рисунок 13 - Структура файла метаданных ИС поставщика
услуг (пример)
Перечень атрибутов пользователя (организации), содержащихся в файле метаданных поставщика услуг, приведен в таблице 5. Системам, интегрированным с ЕСИА, рекомендуется не использовать или отказаться от использования устаревших утверждений SAML (см. Приложение Д.2).
Если у пользователя или организации отсутствуют те или иные атрибуты, то они не передаются в SAML-утверждениях.
Таблица 5 - Перечень атрибутов, содержащихся
в файле метаданных поставщика услуг
Уровень достоверности идентификации пользователя. Возможны следующие значения: AL10 - упрощенная (непроверенная) учетная запись; AL15 - стандартная (проверенная) учетная запись; AL20 - подтвержденная учетная запись; AL30 - подтвержденная учетная запись (аутентификация по КЭП). | Рекомендуется использовать атрибуты: - personTrusted - для определения подтвержденных учетных записей; - authnMethod - для определения метода аутентификации. | ||
Метод аутентификации. Принимает следующие возможные значения: PWD - аутентификации по логину и паролю; DS - аутентификации по ЭП. | |||
Пол пользователя. Принимает значения: MALE - мужской; FEMALE - женский. | |||
Роль пользователя. Принимает следующие возможные значения: P - физическое лицо (Physical person); E - должностное лицо организации (Employee). | |||
Сохранен для обеспечения совместимости. Вместо него необходимо использовать personINN | |||
Принадлежность пользователя к группам доступа ИС, осуществляющей идентификацию и аутентификацию должностных лиц ЮЛ. Передается в виде мнемоник системных групп через запятую | Использовать для определения принадлежности должностных лиц ЮЛ к группам доступа ИС | ||
Сохранен для обеспечения совместимости. Необходимо использовать lastName/firstName/middleName | |||
Сохранен для обеспечения совместимости. Необходимо использовать orgOGRN и orgType | |||
Каждый адрес в настоящее время описывается следующими атрибутами: <addressType> - тип адреса, в настоящее время может принимать значения: - ORG_LEGAL - юридический адрес; - ORG_POSTAL - почтовый адрес. <contryChar3Code> - код страны из трех символов (для России - RUS); <index> - индекс; <region> - субъект РФ; <district> - внутригородской район; <settlement> - населенный пункт; <street> - улица; <house> - дом; <corpus> - корпус; <structure> - строение; <flat> - квартира. Все атрибуты, начиная с индекса, - не более 256 символов. | |||
Телефон и Email организации. Передается в виде XML документа | Каждый контакт в настоящее время описывается следующими атрибутами: <contactType> - тип контакта, в настоящее время может принимать значения: - OPH (телефон); - EML (адрес электронной почты); - FAX (факс). <value> - значение контакта, для телефона и факса имеет формат +7(XXX)XXXXXXX*YYYYYY, где *YYYYYY - добавочный номер (только для OPH, опционально, не более 6 цифр), для адреса электронной почты - не более 2000 символов; <verificationStatus> -- статус подтверждения контакта, где S - подтверждено, N - не подтверждено | ||
Сохранен для обеспечения совместимости. Для вновь подключаемых ИС необходимо использовать orgOid | |||
КПП организации, передается в формате XXXXXXXX, где X - цифры | |||
Организационно-правовая форма организации. Передается название формы по справочнику ОКОПФ | |||
ИНН организации пользователя. Передается в формате XXXXXXXXXX, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут globalRole = E | |||
Наименование организации пользователя. Не более 4000 символов. Данный атрибут устанавливается только для случая, когда атрибут globalRole = E | |||
ОГРН организации пользователя. Передается в формате XXXXXXXXXXXXX, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут globalRole = E | |||
Тип организации. Принимает следующие возможные значения: B - индивидуальный предприниматель (Businessman); L - юридическое лицо (Legal entity); A - орган исполнительной власти (Agency). Данный атрибут устанавливается только для случая, когда атрибут globalRole = E | |||
Гражданство пользователя. Гражданство передается по справочнику ОКСМ. Значение для России - "RUS" | |||
Адрес электронной почты пользователя. Не более 2000 символов | |||
ИНН пользователя. Передается в формате XXXXXXXXXXXX, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут personType = R | |||
Номер мобильного телефона пользователя. Передается в формате +7(XXX)XXXXXXX, где X - цифры | |||
ОГРНИП пользователя. Передается в формате XXXXXXXXXXXXXXX, где X - цифры. Данный атрибут устанавливается только для случая, когда атрибут orgType = B | |||
СНИЛС пользователя. Передается в формате XXX-XXX-XXX XX, где X - цифры. Данный атрибут устанавливается только для стандартных (проверенных) и подтвержденных учетных записей | |||
Подтвержденная или неподтвержденная (упрощенная или стандартная) учетная запись пользователя Y - подтвержденная учетная запись; N - неподтвержденная (упрощенная или стандартная) учетная запись | |||
Сохранен для обеспечения совместимости. Необходимо использовать personCitizenship | |||
Контактные данные пользователя. Передается в виде XML документа | Каждый контакт в настоящее время описывается следующими атрибутами: <contactType> - тип контакта, в настоящее время может принимать значения: - EML (адрес электронной почты); - MBT (мобильный телефон); - PHN (домашний телефон); - CEM (служебный адрес электронной почты пользователя, только для случая, когда атрибут globalRole = E); - CPH (служебный номер телефона пользователя, только для случая, когда атрибут globalRole = E). <value> - значение контакта, для телефонов имеет формат +7(XXX)XXXXXXX, для адреса электронной почты - не более 2000 символов; <verificationStatus> - статус подтверждения контакта, где S - подтверждено, N - не подтверждено | ||
Каждый документ в настоящее время описывается следующими атрибутами: <documentType> - тип документа, в настоящее время это: 01 - паспорт гражданина РФ; 02 - документ иностранного гражданина; 05 - водительское удостоверение; 06 - полис ОМС; 07 - загранпаспорт; <xx> - свидетельство о рождении: - 08 - свидетельство о рождении (без типизации документа); - 18 - свидетельство о рождении РФ; - 28 - свидетельство о рождении иностранного государства; - 38 - свидетельство о рождении СССР; 09 - вид на жительство; 10 - разрешение на временное проживание; 11 - военный билет. <series> - серия документа, 4 символа для паспорта гражданина РФ; <number> - номер документа, 6 символов для паспорта гражданина РФ; <issueDate> - дата выдачи документа в формате YYYY-MM-DDT00:00:00; <verificationStatus> - статус подтверждения документа, где S - подтверждено, N - не подтверждено; <issuedBy> - орган, выдавший документ, строка не более чем из 2000 символов | |||
Каждый адрес в настоящее время описывается следующими атрибутами: <addressType> - тип адреса, в настоящее время это "PERSON_REGISTRATION" - адрес регистрации, "PERSON_LIVE" - адрес проживания. <contryChar3Code> - трехбуквенный код страны. <index> - индекс. <house> - номер дома. <corpus> - корпус. <flat> - корпус. | |||
СНИЛС пользователя. Данный атрибут устанавливается только для случая, когда атрибут personType = R | Сохранен для обеспечения совместимости. Необходимо использовать personSNILS | ||
Полномочия должностного лица ОГВ. Передается в виде XML с указанием мнемоники полномочия и мнемоники системы | Использовать для определения полномочий должностных лиц ОГВ и ЮЛ. Для определения принадлежности представителей юридических лиц к группам доступа использовать memberOfGroups <28> | ||
Числовой идентификатор учетной записи пользователя в системе ЕСИА. Любое положительное число | |||
Сохранен для обеспечения совместимости. Необходимо использовать userId, personSNILS | |||
Сохранен для обеспечения совместимости. Необходимо использовать globalRole |
--------------------------------
<28> В целях обеспечения совместимости системы, получавшие ранее полномочия юридических лиц в утверждении systemAuthority, продолжат получать эти данные в этом утверждении. Однако дальнейшее развитие функционала полномочий будет происходить в терминологии групп доступа, в связи с чем этим системам рекомендуется отказаться от использования systemAuthority и анализировать утверждения memberOfGroups. При регистрации в ЕСИА новых ИС, ориентированных на работу с ЮЛ, они будут иметь возможность зарегистрировать только системные группы. Данные о них будут передаваться в утверждении memberOfGroups.
<?xml version="1.0" encoding="UTF-8"?>
<!--TODO
Необходимо указать уникальный (в рамках поставщика идентификации) entityID сервис провайдера.
Рекомендуется, чтобы значение атрибута entityID соответствовало домену информационной системы.
Уникальный идентификатор системы в ЕСИА (entity_id) не должен содержать символов кириллицы. Например,
http://moscow.rt.ru
-->
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:esia="urn:esia:shibboleth:2.0:mdext"
entityID="http://moscow.rt.ru">
<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
<!--TODO
Сюда необходимо вставить сертификат электронной подписи X509 сервис провайдера
формата DER в кодировке Base64
-->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data>
<ds:X509Certificate>
<!--TODO
Сюда необходимо вставить сертификат ключа электронной подписи X509
сервис провайдера формата DER в кодировке Base64
-->
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<!--TODO
Необходимо заполнить атрибуты вызова обработчика сервис провайдера (тег SingleLogoutService),
отвечающего за обработку событий завершения сессий (logout):
- Location - endpoint обработчика событий сервис провайдера, отвечающего за обработку
сообщений от поставщика идентификации о том, что пользователь инициировал событие завершения сессии
пользователя;
- ResponseLocation - endpoint URL обработчика событий сервис провайдера, отвечающего за
обработку сообщений от поставщика идентификации об успешном выполнении операции завершения сессии
пользователя.
-->
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="endpoint URL" ResponseLocation="endpoint URL"/>
<!--TODO
Необходимо заполнить атрибут Location тега AssertionConsumerService, определяющий endpoint
обработчика событий сервис провайдера, отвечающего за обработку ответа от поставщика идентификации на
AuthnRequest запрос сервис провайдера.
-->
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="endpoint URL" index="0" isDefault="true"/>
</md:SPSSODescriptor>
<md:AttributeAuthorityDescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol
urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Attribute NameFormat="urn:mace:shibboleth:1.0:nameIdentifier" Name="transientId"><!--
Сессионный идентификатор запроса сервис провайдера--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="authToken" Name="urn:mace:dir:attribute:authToken"><!--Идентификатор сессии поставщика
идентификации--></saml:Attribute>
<!--TODO
Далее следует список дополнительных атрибутов пользователя, которые могут быть включены в ответ
поставщика идентификации на AuthnRequest запрос сервис провайдера.
Необходимо оставить только те атрибуты, которые необходимы ИС.
-->
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="userId" Name="urn:mace:dir:attribute:userId"><!--Уникальный идентификатор пользователя в
рамках поставщика идентификации--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="authnMethod" Name="urn:esia:authnMethod"><!--Метод аутентификации с помощью которого
пользователь прошел аутентификацию--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="globalRole" Name="urn:esia:globalRole"><!--Роль под которой аутентифицировался
пользователь--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="lastName" Name="urn:mace:dir:attribute:lastName"><!--Фамилия пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="firstName" Name="urn:mace:dir:attribute:firstName"><!--Имя пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="middleName" Name="urn:mace:dir:attribute:middleName"><!--Отчество пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personINN" Name="urn:esia:personINN"><!--ИНН пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personSNILS" Name="urn:esia:personSNILS"><!--СНИЛС пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personOGRN" Name="urn:esia:personOGRN"><!--ОГРНИП пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personEMail" Name="urn:esia:personEMail"><!--Электронный адрес пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="assuranceLevel" Name="urn:esia:assuranceLevel"><!--Уровень достоверности идентификации
пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="birthDate" Name="urn:esia:birthDate"><!--Дата рождения пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="gender" Name="urn:esia:gender"><!--Пол пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="memberOfGroups" Name="urn:esia:memberOfGroups"><!--Принадлежность пользователя к группам
доступа--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="systemAuthority" Name="urn:esia:systemAuthority"><!--Полномочия должностного лица--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personCitizenship" Name="urn:esia:personCitizenship"><!--Гражданство пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personMobilePhone" Name="urn:esia:personMobilePhone"><!--Номер мобильного телефона
пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="personTrusted" Name="urn:esia:personTrusted"><!--Подтвержденная или неподтвержденная
учетная запись пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="principalAddresses" Name="urn:esia:principalAddresses"><!--Адреса пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="principalContacts" Name="urn:esia:principalContacts"><!--Контактные данные пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="principalDocuments" Name="urn:esia:principalDocuments"><!--Документы пользователя--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgType" Name="urn:esia:orgType"><!--Тип организации пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgName" Name="urn:esia:orgName"><!--Имя организации пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgOGRN" Name="urn:esia:orgOGRN"><!--ОГРН организации пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgINN" Name="urn:esia:orgINN"><!--ИНН организации пользователя--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgPosition" Name="urn:esia:orgPosition"><!--Должность пользователя в организации--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgAddresses" Name="urn:esia:orgAddresses"><!--Адрес организации--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgBranchKPP" Name="urn:esia:orgBranchKPP"><!--КПП филиала--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgContacts" Name="urn:esia:orgContacts"><!--Телефон и Email организации--
></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgOid" Name="urn:esia:orgOid"><!--Идентификатор организации--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgKPP" Name="urn:esia:orgKPP"><!--КПП организации--></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgLegalForm" Name="urn:esia:orgLegalForm"><!--Организационно-правовая форма организации-
-></saml:Attribute>
<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
friendlyName="orgShortName" Name="urn:esia:orgShortName"><!--Краткое наименование организации--
></saml:Attribute>
</md:AttributeAuthorityDescriptor>
<md:Organization>
<!--TODO
Необходимо заполнить описание организации, к которой относится интегрируемая с ЕСИА ИС:
- OrganizationName - имя организации;
- OrganizationDisplayName - имя организации, которая может отображаться пользователям при
проведении процедуры аутентификации;
- OrganizationURL - URL web-сайт компании.
-->
<md:OrganizationName xml:lang="ru">ОАО "Ростелеком"</md:OrganizationName>
<md:OrganizationDisplayName xml:lang="ru">Ростелеком</md:OrganizationDisplayName>
<md:OrganizationURL xml:lang="en">http://www.rt.ru</md:OrganizationURL>
</md:Organization>
<!--TODO
Необходимо заполнить атрибуты организации, к которой относится интегрируемая с ЕСИА информационная
система:
- Company - имя организации, которая осуществляет эксплуатацию ИС;
- EmailAddress - электронная почта эксплуатации ИС.
-->
<md:ContactPerson contactType="technical">
<md:Company>ОАО "Ростелеком"</md:Company>
<md:EmailAddress>support@rt.ru</md:EmailAddress>
</md:ContactPerson>
<!--*********-->
<!--EXTENSIONS-->
<!--*********-->
<md:Extensions>
<!--TODO
Далее следует список поддерживаемых поставщиком услуг глобальных ролей пользователей, а также
поддерживаемые типы организаций (для роли должностное лицо организации).
Необходимо оставить только те роли и типы организации, которые поддерживаются поставщиком
услуг.
Примечание. В случае некорректной обработки тега <md:Extensions> вашей реализацией поставщика
услуг, данный тег можно закомментировать.
-->
<!--TODO
В случае, если ИС не поддерживает работу с ролью "Должностное лицо организации", данный тег не
обязателен.
В случае, если ИС поддерживает глобальную роль "Должностное лицо организации", необходимо также
указать, работу с должностными лицами каких типов организации ИС поддерживает.
В случае, если ИС поддерживает глобальную роль "Должностное лицо организации" (этот случай
включает отсутствие тега SupportedGlobalRoles), но тег SupportedOrgTypes отсутствует - ЕСИА будет
считать, что ИС поддерживает все типы организации.
-->
<!--В случае отсутствия тега SupportedGlobalRoles, ЕСИА будет считать, что ИС поддерживает все
глобальные роли-->
<esia:SupportedGlobalRoles>
<esia:GlobalRole ID="P"></esia:GlobalRole> <!-- Физическое лицо -->
<esia:GlobalRole ID="E"> <!-- Должностное лицо организации -->
<esia:SupportedOrgTypes>
<esia:OrgType ID="L"/> <!-- Юридическое лицо -->
<esia:OrgType ID="B"/> <!-- Индивидуальный предприниматель-->
<esia:OrgType ID="A"/> <!-- Орган исполнительной власти -->
</esia:SupportedOrgTypes>
</esia:GlobalRole>
</esia:SupportedGlobalRoles>
<esia:SupportedAuthnMethods>
<esia:AuthnMethod ID="PWD"/> <!-- Авторизация по паролю -->
<esia:AuthnMethod ID="DS"/> <!-- Авторизация по КЭП -->
</esia:SupportedAuthnMethods>
<esia:SupportedAccTypes>
<esia:AccType ID="T"/> <!-- Авторизация только подтвержденных УЗ -->
<esia:AccType ID="L"/> <!-- Авторизация упрощенных УЗ, но включая подтвержденные -->
</esia:SupportedAccTypes>
</md:Extensions>
</md:EntityDescriptor>
А.7 Рекомендации по указанию URL-адресов и выбору идентификатора поставщика услуг
Все URL-адреса в метаданных для продуктивной среды не должны содержать IP адреса - обязательно указание доменного имени портала информационной системы.
1. Правильно для Единого портала государственных услуг (функций):
ResponseLocation="http://www.gosuslugi.ru/pgu/saml/LogoutServiceHTTPRedirectResponse"
Location="https://www.gosuslugi.ru/pgu/saml/LogoutServiceHTTPRedirect"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/> <md:AssertionConsumerService
Location="https://www.gosuslugi.ru/pgu/saml/SAMLAssertionConsumer"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" isDefault="true" index="0"/>
2. Неправильно для Единого портала государственных услуг (функций):
ResponseLocation="http://109.207.1.97/pgu/saml/LogoutServiceHTTPRedirectResponse"
Location="https://109.207.1.97/pgu/saml/LogoutServiceHTTPRedirect"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/> <md:AssertionConsumerService
Location="https://109.207.1.97/pgu/saml/SAMLAssertionConsumer"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" isDefault="true" index="0"/>
При выборе идентификатора поставщика услуг (entityID) в продуктивной среде рекомендуется руководствоваться следующими принципами:
1. Поле EntityID должно однозначно соответствовать URL портала информационной системы, которая интегрируется с ИС ЕСИА. Примеры:
- Единый портал государственных услуг (функций): entityID="http://www.gosuslugi.ru";
- Российская общественная инициатива: entityID="https://www.roi.ru".
2. Указанный в поле entityID URL не должен содержать IP адрес - обязательно указание доменного имени портала информационной системы. Примеры:
- Единый портал государственных услуг (функций): entityID="http://www.gosuslugi.ru";
- Некорректный пример: entityID="http://109.207.1.97".
3. Указанный в поле entityID URL не должен содержать символов кириллицы.
А.8 Примеры кода на языке Java по использованию OpenSAML
public class Resource extends HttpServlet {
private static SamlConsumer consumer = new SamlConsumer();
public void doGet(HttpServletRequest request, HttpServletResponse response)
{
requestMessage = consumer.buildRequestMessage();
response.sendRedirect(requestMessage);
}
public void doPost(HttpServletRequest request, HttpServletResponse response)
{
responseMessage = request.getParameter("SAMLResponse").toString();
result = consumer.processResponseMessage(responseMessage);
}
}
// issuerUrl - это url сервис-провайдера, который генерирует сообщение <authnRequest>
String issuerUrl = "http://localhost:8080/saml-demo/resource";
IssuerBuilder issuerBuilder = new IssuerBuilder();
Issuer issuer = issuerBuilder.buildObject("urn:oasis:names:tc:SAML:2.0:assertion","Issuer","samlp");
issuer.setValue(issuerUrl);
// создание запроса <AutnRequest>
DateTime issueInstant = new DateTime();
AuthnRequestBuilder authRequestBuilder = new AuthnRequestBuilder();
AuthnRequest authRequest = authRequestBuilder.buildObject("urn:oasis:names:tc:SAML:2.0:protocol",
"AuthnRequest", "samlp");
authRequest.setForceAuthn(new Boolean(false));
authRequest.setIsPassive(new Boolean(false));
authRequest.setIssueInstant(issueInstant);
authRequest.setProtocolBinding("urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST");
authRequest.setAssertionConsumerServiceURL(issuerUrl);
authRequest.setIssuer(issuer);
authRequest.setID(aRandomId);
authRequest.setVersion(SAMLVersion.VERSION_20);
Сообщение <AuthnRequest> может содержать и другие элементы, такие как <NameIDPolicy>, <RequestedAuthnContext>. Эти элементы создаются и добавляются в <AuthnRequest> аналогичным образом.
Сгенерированный запрос <AuthnRequest> должен быть преобразован (marshaled) с использованием "org.opensaml.xml.io.Marshaller" и должен быть закодирован в кодировке Base64 в URL с использованием org.opensaml.xml.util.Base64.
Для считывания ответа <Response>, например, из сервлета, ответ извлекается из структуры "HttpServletRequest":
responseMessage = request.getParameter("SAMLResponse").toString();
Извлеченное сообщение "responseMessage" необходимо преобразовать (unmarshal) и извлечь сообщение <Response>:
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
documentBuilderFactory.setNamespaceAware(true);
DocumentBuilder docBuilder = documentBuilderFactory.newDocumentBuilder();
Document document = docBuilder.parse(new ByteArrayInputStream(authReqStr.trim().getBytes()));
Element element = document.getDocumentElement();
UnmarshallerFactory unmarshallerFactory = Configuration.getUnmarshallerFactory();
Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(element);
Response response = (Response) unmarshaller.unmarshall(element);
Далее с извлеченным SAML 2.0 Response message можно выполнять операции. Например, извлечем Subject's Name Id и сертификат:
String subject = response.getAssertions().get(0).getSubject().getNameID().getValue();
String certificate =
response.getSignature().getKeyInfo().getX509Datas().get(0).getX509Certificates().get(0).getValue();
<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_f634a1edd5a52c852641c0943475edd7" IssueInstant="2012-03-01T06:30:00.307Z" Version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://esia-
portal1.test.gosuslugi.ru/idp/shibboleth</saml2:Issuer>
<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/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_f634a1edd5a52c852641c0943475edd7">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>6p7pdI3FulCoSG2kZbGOtW1GCag=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-
format:transient">_a8e8800fa174f41782184cbbd21ee05f</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData Address="127.0.0.1" InResponseTo="_34efa5b7-47e6-
41bb-b51b-fcb57b7a3f87" NotOnOrAfter="2012-03-01T06:35:00.307Z" Recipient="https://atc-
504:7002/oiosaml/saml/SAMLAssertionConsumer"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2012-03-01T06:30:00.307Z" NotOnOrAfter="2012-03-01T06:35:00.307Z">
<saml2:AudienceRestriction>
<saml2:Audience>sia_test</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2012-03-01T06:30:00.182Z"
SessionIndex="211f42f443924066aec4d5bc8740bce17a93ba3358d9e7003333db957540116b">
<saml2:SubjectLocality Address="127.0.0.1"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</
saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="personSNILS" Name="urn:esia:personSNILS"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">000-000-000 00</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="userId" Name="urn:mace:dir:attribute:userId"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">2006101</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="snils" Name="urn:mace:dir:attribute:snils"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">000-000-000 00</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="authnMethod" Name="urn:esia:authnMethod"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">PWD</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="principalStatus"
Name="urn:mace:dir:attribute:principalStatus" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">A</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="globalRole" Name="urn:esia:globalRole"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">P</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="personEMail" Name="urn:esia:personEMail"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">sdf@ddd.ru</saml2:AttributeValue>
</saml2:Attribute>
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">SNILS</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="personType" Name="urn:esia:personType"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">R</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="authToken" Name="urn:mace:dir:attribute:authToken"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">b0db6fd1-d674-47bb-8f22-9f8291e59255</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="userName" Name="urn:esia:userName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">000-000-000 00</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="middleName" Name="urn:mace:dir:attribute:middleName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">Дмитриевич</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="attachedToOrg" Name="urn:esia:attachedToOrg"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">1</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="firstName" Name="urn:mace:dir:attribute:firstName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">Дмитрий</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="lastName" Name="urn:mace:dir:attribute:lastName"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">Дмитриев</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="portalVersion"
Name="urn:mace:dir:attribute:portalVersion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-
format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">P</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="userType" Name="urn:mace:dir:attribute:userType"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">P</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>
СЕРВИСЫ ЕСИА НА БАЗЕ ПОДХОДА REST
Б.1 Общие сведения о программном интерфейсе ЕСИА
В рамках развития ЕСИА реализован прикладной программный интерфейс на базе архитектурного стиля "Representational State Transfer" (REST). Он позволяет интегрированным с ЕСИА информационным системам получать доступ к хранящимся в ЕСИА ресурсам, т.е. данным (например, о пользователях или других информационных системах), а также выполнять ряд операций.
Вызов прикладного программного интерфейса возможен только теми интегрированными с ЕСИА системами, которые имеют на это соответствующие полномочия. Контроль доступа к ресурсам ЕСИА осуществляет сервис авторизации ЕСИА, реализующий модель контроля доступа, основанную на спецификациях OAuth 2.0 (см. Приложение В).
Для обозначения ресурсов используются специальные идентификаторы. Сами ресурсы организованы иерархически, уровни разделены косой чертой - "/". Ресурсы более "низкого" уровня являются составными частями "родительского уровня":
В ЕСИА используется два типа ресурсов:
- документ содержит информацию об отдельном объекте в базе данных, который характеризуется некоторыми полями и значениями. Например, при доступе к документу об организации сервис возвращает наименование организации, ее тип, ОГРН и др. Кроме того, в документе могут содержаться ссылки на связанные ресурсы: так, в документе об организации размещаются указатели на ресурсы (документы) по ее сотрудникам;
- коллекция представляет собой список некоторых ресурсов, например, документов. Перечень организаций, сотрудников отдельной организации - примеры коллекций. Ресурсы, которые включены в коллекцию, снабжены собственными идентификаторами (uri). Обычно для обозначения коллекции используются множественные существительные (orgs, sbjs и др.).
Для вызова сервиса ЕСИА, позволяющего получить доступ к защищенному ресурсу, система-клиент должна направить в https-адрес программного интерфейса ЕСИА запрос. Для этого (в зависимости от типа запроса) используются методы GET или POST. В каждом запросе должен быть указан идентификатор ресурса, к которому запрашивается доступ. Кроме того, в запрос на вызов REST-API должен быть добавлен следующий header:
Authorization: Bearer <access token>
<access token> - маркер доступа, предварительно полученный у сервиса авторизации ЕСИА. Срок действия маркера доступа различен для каждой информационной системы и настраивается Администратором в Технологическом портале ЕСИА. Он не должен истечь на момент вызова. Маркер доступа должен быть выдан системе-клиенту на <scope>, позволяющий получить запрашиваемый защищенный ресурс. Пример запроса на получение сведений об организации с идентификатором 1000000000:
GET /rs/orgs/1000000000 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
В случае успешной проверки запроса программный интерфейс возвращает данные о защищенном ресурсе. При невозможности выполнить запрос возвращается код ошибки.
При вызове сервиса могут быть заданы параметры запроса (query), которые оформляются стандартным способом. Следующий запрос позволит получить первые 15 организаций из соответствующей коллекции orgs:
GET /rs/orgs?pageIndex=0&pageSize=15 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
При вызове сервиса может быть указана конкретная схема предоставления данных об объекте. Для этого необходимо дать ссылку на соответствующую схему в заголовке запроса (с помощью ACCEPT). Например:
Authorization: Bearer 75b2c7cbd9db403489c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: application/json; schema="https://esia-portal1.test.gosuslugi.ru/rs/model/prn/Person-1"\r\n
Данный запрос позволяет получить сведения о пользователе с идентификатором 402, сформированные согласно схеме Person-1. Это означает, что по мере развития ЕСИА может быть изменен передаваемый атрибутный состав данных о пользователе, в результате чего появляются новые схемы - Person-2, Person-3 и т.д. В связи с этим для получения неизменного состава атрибутов рекомендуется в запросе указывать конкретную схему. Если в качестве схемы указана схема /model/prn/Person без явного указания версии, то возвращается последняя версия. Если схема не указана вообще, то также возвращается последняя версия схемы.
В ответе на корректный запрос выдается JSON-документ, который представляет собой набор пар ключ/значение или массив значений. В заголовке (headers) ответа содержатся следующие данные:
1. Ссылки (links) на связанные ресурсы. Например, если в запросе указан ресурс с данными конкретного пользователя (prns/402), то ссылки будут содержать ресурсы с его контактными данными, документами, адресами, транспортными средствами, а также на "родительский" ресурс с перечнем всех пользователей в системе.
2. Тип предоставляемых данных (Content-Type) с указанием схемы предоставляемых данных. Например, если запрашиваются данные о пользователе в схеме Person-1, то будет указано следующее значение: Content-Type: [application/json; q=.2; schema="https://esia-portal1.test.gosuslugi.ru/rs/model/prn/Person-1"]
Пример раздела headers (разрывы строк даны для удобства чтения):
[<https://esia-portal1.test.gosuslugi.ru/rs/prns/402/docs>;rel=documents;schema="https://esia-
portal1.test.gosuslugi.ru/rs/model/docs/Documents-1",
<https://esia-portal1.test.gosuslugi.ru/rs/prns/402/addrs>;rel=addresses;schema="https://esia-
portal1.test.gosuslugi.ru/rs/model/addrs/Addresses-1",
<https://esia-portal1.test.gosuslugi.ru/rs/prns/402/ctts>;rel=contacts;schema="https://esia-
portal1.test.gosuslugi.ru/rs/model/ctts/Contacts-1",
<https://esia-portal1.test.gosuslugi.ru/rs/prns/>;rel=parent;schema="https://esia-
portal1.test.gosuslugi.ru/rs/model/prns/Persons-1"]
Date: [Tue, 26 Nov 2013 10:04:24 GMT]
Transfer-Encoding: [chunked]
Location: [http://esia-portal1.test.gosuslugi.ru/rs/prns/402]
server: [grizzly/2.2.16]
Content-Type: [application/json; q=.2; schema="https://esia-
portal1.test.gosuslugi.ru/rs/model/prn/Person-1"]
Содержательная часть ответа на запрос содержится в разделе body. Пример возвращаемых данных (разрывы строк даны для удобства чтения) о физическом лице:
"stateFacts": ["Identifiable"],
"firstName":"Петр",
"lastName":"Петров",
"birthDate": "19.03.1996",
"gender":"M",
"trusted":"true",
"citizenship":"RUS",
"snils":"111-111-111 11",
"updatedOn":"1385460263"
}
Каждое описание объекта или коллекции содержит параметр stateFacts, указывающий на некоторые факты о предоставляемых сведениях. Возможны следующие значения stateFacts:
- Identifiable - имеет идентификатор (например, это конкретный контакт или документ);
- hasSize - имеет размер (например, для коллекции указывает на число элементов коллекции);
- FirstPage - первая страница списка;
- LastPage - последняя страница списка;
- Paginated - постраничный список;
- EntityRoot - корневой объект;
- ReadOnly - объект только для чтения.
Параметр stateFacts позволяет, в частности, производить разделение выводимых результатов по страницам. Следующий ответ представляет собой первую страницу некоторого перечня (фрагмент, разрывы строки даны для удобства чтения):
"stateFacts": ["Paginated","FirstPage"],
"elements":[
"https://esia-portal1.test.gosuslugi.ru/rs/prns/400",
"https://esia-portal1.test.gosuslugi.ru/rs/prns/401"
],
"pageSize":"2",
"pageIndex":"1"
}
Из данного ответа видно, что на каждой странице отображается по 2 элемента.
Для ряда операций поддерживается возможность встраивания (embedding) связанных данных. Для этого в запросе соответствующего ресурса необходимо указывать параметр "embed", а в качестве его значения - сущность, которую требуется включить в ответ запроса. Например, при запросе следующего ресурса будут отображаться ссылки на контакты пользователя 100000:
https://esia-portal1.test.gosuslugi.ru/rs/prns/100000/ctts
Однако указание параметра "embed" позволяет получить данные о контактах непосредственно в ответе на следующий запрос:
https://esia-portal1.test.gosuslugi.ru/rs/prns/100000/ctts?embed=(elements)
В этом случае запрос данного ресурса будет возвращать ответ (фрагмент, разрывы строки даны для удобства чтения):
"stateFacts": ["hasSize"],
"elements": [
{
"stateFacts": [
"Identifiable"
],
"id": 194,
"type": "MBT",
"vrfStu": "VERIFIED",
"value": "+7(910)1234567"
}
],
"size": 1
}
В данном случае на месте ссылок на связанные элементы встраиваются данные контактов.
При встраивании сохраняется возможность получать схемы возвращаемых ресурсов, например:
https://esia-portal1.test.gosuslugi.ru/rs/prns/100000/ctts?embed=(elements-1)
В этом случае данные об элементах будут возвращаться согласно первой схеме.
Также возможно встраивание нескольких ресурсов в запросе, например:
https://esia-portal1.test.gosuslugi.ru/rs/orgs/100000/emps?embed=(elements.person)
В этом случае в ответе вместо ссылок на сотрудников организации будут передаваться персональные данные сотрудников организации: ФИО, отчество, дата и место рождения, пол и т.д. Набор данных зависит от информации, указанной в профиле сотрудника.
При встраивании нескольких ресурсов также возможно указание на версии, например:
https://esia-portal1.test.gosuslugi.ru/rs/orgs/100000/emps?embed=(elements-1.person-1)
Перечень ссылок, которые могут быть встроены:
- - контактные данные (contacts);
- - транспортные средства (vehicles);
- - организации, к которым принадлежит физическое лицо (organizations);
- - контактные данные (contacts);
- - транспортные средства (vehicles);
- данные о сотрудниках организации:
- - данные о сотруднике как физическом лице (person).
- данные по ссылкам, отображаемым в содержании ответа в разделе "elements" (возможность встраивания elements есть везде, где параметр stateFacts имеет значение "hasSize").
Далее приведены описания следующих операций программного интерфейса ЕСИА:
- предоставление персональных данных пользователей;
- проверка факта удаления учетной записи пользователя ЕСИА;
- предоставление сведений о вхождении пользователя в группы и организации;
- предоставление данных из профиля организации;
- предоставление списка участников группы или организации;
- предоставление сведений о вхождении пользователей в группы;
- управление данными организации;
- предоставление сведений о субъекте.
Б.2 Предоставление персональных данных пользователей
Для получения персональных данных о пользователях система-клиент должна направить в https-адрес REST-API системы ЕСИА <29> запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Иерархия идентификаторов этих ресурсов в ЕСИА имеет следующий вид:
--------------------------------
<29> В тестовой среде сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/
/rs/prns/{oid}/{collection_name}/{collection_entity_id},
/esia-rs/api/public/{version}/prns/{oid}/{collection_name}/{collection_entity_id},
- {version} - версия API верификации, возможные значения:
- v1 - первая версия, по умолчанию,
- prns - перечень (коллекция) пользователей, зарегистрированных в ЕСИА;
- {oid} - внутренний идентификатор объекта, в том числе пользователя, в ЕСИА;
- {collection_name} - ссылка на перечень (коллекцию) типов данных, указанных пользователем с данным oid, возможные значения:
- addrs - адреса, получение адреса временной регистрации возможно только с версией API v2;
- docs - документы пользователя;
- orgs - организации, сотрудником которых является данный пользователь;
- vhls - транспортные средства пользователя.
- {collection_entity_id} - внутренний идентификатор элемента (например, контакта или документа) пользователя в ЕСИА.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (либо scope id_doc с параметрами, либо один или несколько scope, обеспечивающих доступ к персональным данным пользователя, с параметрами <30>).
--------------------------------
<30> Например, fullname, contacts, email (см. Приложение В.4). Все эти scope также позволяют получить данные о признаке подтвержденности учетной записи пользователя (атрибут <trusted>). При запросе у сервиса авторизации ЕСИА маркера доступа на указанные scope не нужно в качестве параметра указывать oid этого пользователя.
Пример запроса (вызов сервиса в среде разработки):
GET /rs/prns/6924 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 6.
Таблица 6 - Параметры ответа на запрос
о персональных данных пользователя
<rIdDoc> - идентификатор текущего документа пользователя; <firstName> - имя; <lastName> - фамилия; <middleName> - отчество; <birthDate> - дата рождения (в формате "ДД.ММ.ГГГГ"); <birthPlace> - место рождения пользователя; <gender> - пол; <trusted> - тип учетной записи (подтверждена ("true")/не подтверждена ("false")); <citizenship> - гражданство (идентификатор страны гражданства); <snils> - СНИЛС; <inn> - ИНН; <updatedOn> - дата последнего изменения учетной записи пользователя (задается как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 года); <verifying> - процесс проверки данных (true/false); <status> - статус УЗ (Registered - зарегистрирована/Deleted - удалена); <selfEmployed> - информация о самозанятом: - <confirmed> - значение "true" - признак самозанятого есть, "false" - признака самозанятого нет; - <confirmDate> - дата обновления статуса самозанятого; <fmsValid> - валидность документа в ФМС (false - документ неактуален, в таком случае, к параметрам добавляется fmsState; true - документ актуален); <fmsState> - статус документа в ФМС, может иметь значения: - "PERSON_NOT_FOUND" - по указанному в запросе СНИЛС пользователь в БД ИС МВД не найден; - "PASSPORT_NOT_FOUND" - в случае, если в полученном досье есть паспорт гражданина РФ и он имеет DOC_STATUS = 302 и в досье нет паспорта гражданина РФ с DOC_STATUS = 300; - "PASSPORT_INVALID" - в случае, если в полученном досье есть паспорт гражданина РФ и он имеет DOC_STATUS = 301 и его данные (серия, номер) совпадают с указанными в УЗ пользователя, при этом в досье нет паспорта гражданина РФ с DOC_STATUS = 300; - "AUTO_UPDATE_SUCCESS" - в случае успешного завершения автоматического обновления | |||
Перечень контактов физического лица (в виде ссылок на ресурс с указанием {ctt_id}, содержащий данные о каждом контакте) | |||
Сведения об отдельной записи в перечне контактов физического лица | <type> - тип записи, может иметь значения: - "MBT" - мобильный телефон; - "PHN" - домашний телефон; - "EML" - электронная почта. <vrfStu> - сведения о "подтвержденности" контактов, может иметь значения: - "NOT_VERIFIED" - не подтвержден; - "VERIFIED" - подтвержден. В настоящее время статус "VERIFIED" может быть только у мобильного телефона ("MBT") и адреса электронной почты ("EML"). <value> - значение контакта; <vrfValStu> - необязательный параметр, указывается в случае, если контакт находится в процессе подтверждения. Может принимать следующее значение: - "VERIFYING" - в процессе подтверждения. В настоящее время статус "VERIFYING" может быть только у мобильного телефона ("MBT") и адреса электронной почты ("EML"). <verifyingValue> - значение контакта, находящегося в процессе подтверждения. | ||
Перечень адресов физического лица (в виде ссылок на ресурс с указанием {addr_id}, содержащий данные о каждом адресе) | |||
Сведения об отдельной записи в перечне адресов физического лица | <type> - тип записи, может иметь значения: - "PLV" - адрес места проживания; - "PTA" - адрес временной регистрации; - "PRG" - адрес постоянной регистрации. <zipCode> - индекс; <countryId> - идентификатор страны; <addressStr> - адрес в виде строки (не включая дом, строение, корпус, номер квартиры); <building> - строение; <frame> - корпус; <house> - дом; <flat> - квартира; <fiasCode> - код КЛАДР; <region> - регион; <city> - город; <district> - внутригородской район; <area> - район; <settlement> - поселение; <additionArea> - доп. территория; <additionAreaStreet> - улица на доп. территории; <street> - улица. | ||
Перечень документов физического лица (в виде ссылок на ресурс с указанием {doc_id}, содержащий данные о каждом документе); | |||
Сведения об отдельной записи в перечне документов физического лица | <type> - тип записи, может иметь значения: - "RF_PASSPORT" - паспорт гражданина РФ; - "FID_DOC" - документ иностранного гражданина; - "RF_DRIVING_LICENSE" - водительское удостоверение. - "MLTR_ID" - военный билет; - "FRGN_PASS" - заграничный паспорт; - "MDCL_PLCY" - полис ОМС; - "RF_BRTH_CERT" - свидетельство о рождении - Россия; - "FID_BRTH_CERT" - свидетельство о рождении - другая страна; - "OLD_BRTH_CERT" - свидетельство о рождении - СССР. <vrfStu> - сведения о "подтвержденности" документов, может иметь значения: - "NOT_VERIFIED" - не подтвержден; - "VERIFIED" - подтвержден. <actNo> - номер актовой записи (для свидетельства о рождении РФ и СССР); <actDate> - дата актовой записи (только для свидетельства о рождении ребенка РФ); <series> - серия документа; <number> - номер документа; <issueDate> - дата выдачи документа; <issueId> - код подразделения; <issuedBy> - кем выдан; <expiryDate> - срок действия документа; <lastName> - фамилия (для заграничного паспорта); <firstName> - имя (для заграничного паспорта). <vrfValStu> - необязательный параметр, указывается в случае, если документ находится в процессе подтверждения. Может принимать следующее значение: - "VERIFYING" - в процессе подтверждения; - "VERIFICATION_FAILED" - ошибки проверки. "vrfReqId" - идентификатор заявки; <eTag> - тег изменяемого объекта; <fmsValid> - валидность документа в ФМС (false - документ неактуален, в таком случае, к параметрам добавляется fmsState; true - документ актуален); <fmsState> - статус документа в ФМС, может иметь значения: - "PERSON_NOT_FOUND" - по указанному в запросе СНИЛС пользователь в БД ИС МВД не найден; - "PASSPORT_NOT_FOUND" - в случае, если в полученном досье есть паспорт гражданина РФ и он имеет DOC_STATUS = 302 и в досье нет паспорта гражданина РФ с DOC_STATUS = 300; - "PASSPORT_INVALID" - в случае, если в полученном досье есть паспорт гражданина РФ и он имеет DOC_STATUS = 301 и его данные (серия, номер) совпадают с указанными в УЗ пользователя, при этом в досье нет паспорта гражданина РФ с DOC_STATUS = 300; - "AUTO_UPDATE_SUCCESS" - в случае успешного завершения автоматического обновления | ||
Перечень организаций, сотрудником которых является данное физическое лицо | Перечень организаций, сотрудником которых является физическое лицо с данным {oid} (в виде ссылок на ресурс с указанием {oid}, содержащий данные о каждой организации) | ||
Перечень детей физического лица (в виде ссылок на ресурс с указанием {kid_id}, содержащий данные о каждом ребенке) | |||
Сведения об отдельной записи в перечне детей физического лица | <firstName> - имя ребенка; <lastName> - фамилия ребенка; <middleName> - отчество ребенка; <birthDate> - дата рождения; <gender> - пол; <snils> - СНИЛС; <inn> - ИНН; <trusted> - признак подтвержденности данных о ребенке (подтверждены ("true")/не подтверждены ("false")); <updatedOn> - дата последнего изменения данных о ребенке (задается как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 года) | ||
Перечень документов ребенка данного физического лица (в виде ссылок на ресурс с указанием {doc_id}, содержащий данные о каждом документе) | |||
Сведения об отдельной записи в перечне документов ребенка физического лица | Документы ребенка описываются по аналогии с документами физического лица. Для детей предусмотрены следующие типы (<type>) документов: - "MDCL_PLCY" - полис ОМС; - "RF_BRTH_CERT" - свидетельство о рождении - Россия; - "FID_BRTH_CERT" - свидетельство о рождении - другая страна; - "OLD_BRTH_CERT" - свидетельство о рождении - СССР <31>. | ||
Перечень транспортных средств, которыми владеет данный пользователь | |||
prns/{oid}/vhls?embed=(vehi cles.elements) | Перечень транспортных средств с данными о каждом транспортном средстве | Перечень транспортных средств, которыми владеет данный пользователь, содержащий информацию о каждом транспортном средстве | |
<name> - имя автомобиля (например, марка или другое пользовательское описание); <numberPlate> - государственный регистрационный знак; <regCertificate> - данные свидетельства о государственной регистрации, включает в себя атрибуты: - <series> - серия свидетельства; - <number> - номер свидетельства. |
--------------------------------
<31> Для просмотра полных данных о ребенке с его документами можно использовать режим встраивания (embed). В этих целях необходимо сделать запрос методом GET по следующему адресу:
/prns/{oid}/kids/{kid_id}?embed=(documents.elements)
При отображении всех коллекций используется механизм paging.
Пример ответа на запрос контактных данных физического лица (фрагмент, разрывы строк даны для удобства чтения):
"stateFacts": ["Identifiable"],
"type":"MBT",
"vrfStu":"VERIFIED",
"value":"+7(777)7777777"
}
Пример ответа на запрос конкретного адреса физического лица (фрагмент, разрывы строк даны для удобства чтения):
"stateFacts":["Identifiable"],
"eTag": "672951A704B88A0063A35C3F49409152B087A49A",
"id": 21423,
"type": "PRG",
"region": "Воронежская Область",
"addressStr": "Воронежская область, Воронеж город, ПКрл Маяк-1 территория",
"frame": "5",
"fiasCode": "5bf5ddff-6353-4a3d-80c4-6fb27f00c6c1",
"city": "Воронеж Город",
"countryId": "RUS",
Пример ответа на запрос конкретного документа физического лица (фрагмент, разрывы строк даны для удобства чтения):
"stateFacts": ["Identifiable"],
"type":"RF_PASSPORT",
"vrfStu":"VERIFIED",
"series":"3333",
"number":"333333",
"issueDate":"1383249600",
"issueId":"333333"
}
Пример ответа на запрос конкретного транспортного средства физического лица (фрагмент, разрывы строк даны для удобства чтения):
"stateFacts": ["Identifiable"],
"name": "Хонда",
"numberPlate": "А133ОН177",
"regCertificate": {
"series": "77УЕ",
"number": "204623"
}
}
Пример ответа на запрос всех транспортных средств физического лица, полученный с использованием возможностей встраивания <32> (фрагмент, разрывы строк даны для удобства чтения):
--------------------------------
<32> Запрошенный ресурс: /prns/100000?embed=(vehicles.elements) или /prns/100000/vhls?embed=(vehicles.elements)
"stateFacts": ["Paginated"],
"size": 5,
"pageSize": 5,
"pageIndex": 2,
"totalSize": 12,
"eTag": "E6DAE96DADE1CA29F5C50979BBB7C8BF4422FD62",
"elements": [{
"stateFacts": ["Identifiable"],
"id": 6590,
"name": "TOYOTA",
"numberPlate": "А111АА136",
"regCertificate": {"series": "1234","number": "123456"},
"eTag": "F69EEA8910E298E97C8E6249A130A7195DFE7F1A"},
............. }
Для получения категорий самозанятого пользователя система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Иерархия идентификаторов этих ресурсов в ЕСИА имеет следующий вид:
- categories - коллекция категорий, имеющихся в ЕСИА;
- prns - перечень (коллекция) пользователей, зарегистрированных в ЕСИА;
- {oid} - внутренний идентификатор объекта, в том числе пользователя, в ЕСИА.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope self_employed).
Пример запроса (вызов сервиса в среде разработки):
GET /categories/prns/1077128402 HTTP/1.1\r\n
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE2MDAzNDE5NzEsInNjb3B
lIjoic2VsZl9lbXBsb3llZD9vaWQ9MTA3NzEyNzk1NSIsImlzcyI6Imh0dHA6XC9cL2VzaWEuZ29zdXNsdWdpLnJ1XC8iLCJ1cm
46ZXNpYTpzaWQiOiJjYWRhOTE5N2Q2MDAzZTVmZTI0MDIxOGMyODA1NDc1ZGM4YjIxNTFiZTQ0MGQ1YWQzMTQ3ODFiMDUxNGNmZ
WM2IiwidXJuOmVzaWE6c2JqX2lkIjoxMDc3MTI3OTU1LCJleHAiOjE2MDAzNDU1NzEsImlhdCI6MTYwMDM0MTk3MSwiY2xpZW50
X2lkIjoiUEdVIn0.VySaaGxci6XpwL7V0Df3yLIBENGP7R6ki9sQ4MqdHoc2ItkI4ObI7sClWNaaSQxE_vNXUqszYWUPde_vOWM
oNSbjSUbITPrXr9tgb6LuZbCpKSFxwnu8WAjqQfWfcssNWn9-
MxpAJHrEfVUu6eMpVfcME_qFDc4YtKVLmWQ8viPpL0E2gokn_E67EibHevnJY13H7GpKL0UYzNV40rr4O8Ai2zaGG8WZ3GM_ZRE
FMMbH3aW3mfoCSF_QDKqPiZI6OhhvNtgo6VKarverbFo4y1hqQD7p3KTSXjukoeQ2OYnNHQj9V01mJtxXrTxXIcnkyq8Fj60FCB
uX6bhtgwBQ9Q
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в Таблице 7.
Таблица 7 - Параметры ответа на запросы
о категориях самозанятого
Пример ответа с категориями самозанятого (разрывы строки даны для удобства чтения):
{
"stateFacts":[
"FirstPage",
"Paginated"
],
"size": 2,
"pageSize": 100,
"pageIndex": 1,
"elements":[
{
"parentName": "Ремонт",
"parentId": "1001",
"catName": "Сантехник",
"catId": "1005",
"catConfirm": "N",
"status": "OK",
"confirmDate": 1599078238000
},
{
"parentName": "Развлечения",
"parentId": "1121",
"catName": "Торговля фруктовой, ягодной, овощной продукцией, выращенной самостоятельно",
"catId": "44",
"catConfirm": "N",
"status": "OK",
"confirmDate": 1599077915000
}
]
}
Б.3 Проверка факта удаления учетной записи и связанных с ней персональных данных пользователя из ЕСИА
Вызов данной операции предоставляет интегрированным с ЕСИА информационным системам данные об удаленных пользователях в ЕСИА (идентификатор пользователя). Для получения перечня удаленных пользователей система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. В качестве этого ресурса используется стандартный идентификатор ресурса с персональными данными пользователей (/prns), возвращающий перечень зарегистрированных в системе пользователей (см. раздел Б.2). Специфика вызова данной операции состоит в том, что запрос должен содержать следующие параметры:
- <status> - статус пользователя, должен иметь значение "DELETED";
- <updatedSince> - дата, начиная с которой необходимо отобразить удаленных пользователей. Задается как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 года.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/tech_inf с параметрами).
Пример запроса (вызов сервиса в среде разработки):
GET /rs/prns?status=DELETED&updatedSince=1384218061 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
В качестве ответа передается перечень физических лиц, удаленных с указанной даты. Этот перечень представляет собой список ссылок на ресурс с указанием {oid}, содержащий идентификаторы всех удаленных физических лиц с указанной в запросе даты.
Б.4 Предоставление данных из профиля организации
Для получения данных об организациях система-клиент должна направить в https-адрес REST-API системы ЕСИА <33> запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Идентификатор этого ресурса в ЕСИА имеет следующий вид:
--------------------------------
<33> В тестовой среде сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs
/orgs/{orgOid}/{collection_name}/{collection_entity_id}, где:
- orgs - коллекция организаций, имеющихся в ЕСИА;
- orgOid - внутренний идентификатор организации в ЕСИА; для определения orgOid соответствующей организации необходимо использовать атрибут orgOid, передающийся в утверждениях SAML;
- {collection_name} - ссылка на перечень (коллекцию) типов данных организации с указанным oid, возможные значения:
- vhls - транспортные средства;
- {collection_entity_id} - внутренний идентификатор контакта, адреса, транспортного средства или филиала.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope в зависимости от полномочий системы).
Пример запроса (вызов сервиса в среде разработки):
GET /rs/orgs/1000000000 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 8.
Таблица 8 - Параметры ответа на запросы о данных организации
<shortName> - сокращенное наименование организации; <fullName> - полное наименование организации; <type> - тип организации. Для государственных организаций - "AGENCY", для юридических лиц - "LEGAL"; <ogrn> - ОГРН организации; <inn> - ИНН организации; <leg> - код организационно-правовой формы по общероссийскому классификатору организационно-правовых форм; <kpp> - КПП организации; <agencyTerRange> - территориальная принадлежность ОГВ (только для государственных организаций, код по справочнику "Субъекты Российской Федерации" (ССРФ), для Российской Федерации используется код 00; <agencyType> - тип ОГВ (только для государственных организаций) <34>; <staffCount> - количество сотрудников организации; <branchesCount> - количество филиалов организации (только для ЮЛ и ОГВ). | |||
Перечень филиалов организации (в виде ссылок на ресурс с указанием {branch_id}, содержащий данные о каждом филиале) | |||
<name> - имя филиала; <kpp> - КПП филиала; <leg> - код организационно-правовой формы по общероссийскому классификатору организационно-правовых форм; <staffCount> - количество сотрудников филиала. Для просмотра контактных данных и адресов филиала следует воспользоваться ресурсами /orgs/{orgOid}/brhs/{branch_id}/ctts и /orgs/{orgOid}/brhs/{branch_id}/addrs соответственно. Структура этих ресурсов аналогична ресурсам головной организации | |||
Перечень контактов организации (в виде ссылок на ресурс с указанием {ctt_id}, содержащий данные о каждом контакте) | |||
Сведения об отдельной записи в перечне контактов организации | <type> - тип записи, может иметь значения: - "OPH" - телефон; - "OFX" - факс; - "OEM" - электронная почта. <vrfStu> - сведения о "подтвержденности" контактов, может иметь значения: - "NOT_VERIFIED" - не подтвержден; - "VERIFIED" - подтвержден. <value> - значение контакта | ||
Перечень адресов организации (в виде ссылок на ресурс с указанием {addr_id}, содержащий данные о каждом адресе) | |||
<type> - тип записи, может иметь значения: - "OLG" - юридический адрес; - "OPS" - фактический адрес; <zipCode> - индекс; <countryId> - идентификатор страны; <addressStr> - адрес в виде строки (не включая дом, строение, корпус, номер квартиры); <building> - строение; <frame> - корпус; <house> - дом; <flat> - квартира; <fiasCode> - код ФИАС; <region> - регион; <city> - город; <district> - внутригородской район; <area> - район; <settlement> - поселение; <additionArea> - доп. территория; <additionAreaStreet> - улица на доп. территории; <street> - улица. | |||
Перечень транспортных средств, которыми владеет данная организация | |||
orgs/{orgOid}/vhls ?embed=(vehicles) | Перечень транспортных средств с данными о каждом транспортном средстве | Перечень транспортных средств, которыми владеет данная организация, содержащий информацию о каждом транспортном средстве | |
orgs/{orgOid}/vhls ?embed=(elements-1) | |||
<name> - имя автомобиля (например, марка или другое пользовательское описание); <numberPlate> - государственный регистрационный знак; <regCertificate> - данные свидетельства о государственной регистрации, включает в себя атрибуты: - <series> - серия свидетельства; - <number> - номер свидетельства. |
--------------------------------
<34> В настоящее время используются следующие коды:
10.FED - Федеральный орган исполнительной власти
11.REG - Орган исполнительной власти субъекта РФ
12.LCL - Орган местного самоуправления
13.PVD - Подведомственная организация федерального органа исполнительной власти
20.GOV - Государственное учреждение
21.MCL - Муниципальное учреждение
30.FND - Государственный внебюджетный фонд
31.PFN - Подведомственная организация государственного внебюджетного фонда
40.MFC - Многофункциональный центр
41.LEG - Законодательный (представительный) орган государственной власти субъекта Российской Федерации
Пример ответа с кратким наименованием организации (разрывы строки даны для удобства чтения):
"stateFacts": ["Identifiable"],
"shortName": "Банк"
}
Пример ответа с контактными данными об адресах организации при использовании возможностей встраивания <35> (разрывы строки даны для удобства чтения):
--------------------------------
<35> Запрос ресурса: /orgs/100000/addrs?embed=(elements)
"stateFacts": ["hasSize"],
"elements": [
{
"stateFacts": ["Identifiable"],
"id": 62,
"type": "OLG",
"region": "Москва Город",
"addressStr": "Москва Город, Ангарская улица",
"countryId": "RUS",
"zipCode": "125635",
"street": "Ангарская улица",
"house": "10",
"flat": "96"
}
],
"size": 1
}
Пример ответа на запрос всех транспортных средств организации, полученный с использованием возможностей встраивания <36> (фрагмент, разрывы строк даны для удобства чтения):
--------------------------------
<36> Запрошенный ресурс: /orgs/1000000000/vhls?embed=(vehicles) или /orgs/1000000000/vhls?embed=(elements-1)
"stateFacts": ["Paginated"],
"size": 5,
"pageSize": 5,
"pageIndex": 2,
"totalSize": 12,
"eTag": "E6DAE96DADE1CA29F5C50979BBB7C8BF4422FD62",
"elements": [{
"stateFacts": ["Identifiable"],
"id": 6590,
"name": "TOYOTA",
"numberPlate": "А111АА136",
"regCertificate": {"series": "1234","number": "123456"},
"eTag": "F69EEA8910E298E97C8E6249A130A7195DFE7F1A"},
.............
}
Для получения данных о категориях организации система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Идентификатор этого ресурса в ЕСИА имеет следующий вид:
- categories - коллекция категорий, имеющихся в ЕСИА;
- orgs - коллекция организаций, имеющихся в ЕСИА;
- orgOid - внутренний идентификатор организации в ЕСИА;
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope в зависимости от полномочий системы).
Пример запроса (вызов сервиса в среде разработки):
GET categories/orgs/1000364913 HTTP/1.1\r\n
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IkdPU1QzNDEwXzIwMTJfMjU2In0.eyJuYmYiOjE1OTk
1NTQ1MDEsInNjb3BlIjoib3BlbmlkIGNhdGVnb3JpZXM_b2lkPTEwMDAzNjQ5MTMiLCJpc3MiOiJodHRwOlwvXC9lc2lhLmdvc3
VzbHVnaS5ydVwvIiwidXJuOmVzaWE6c2lkIjoiMWQ0OWQ5ZGMzY2FiZThhMjJjNDRhODdlODMyNzMzMDRlOWI1YjE1ODJkNTlkN
2E2N2VhZGJjODg5OWM5MjBjZSIsInVybjplc2lhOnNial9pZCI6MTAwMDM2NjU4NywiZXhwIjoxNTk5NTU4MTAxLCJpYXQiOjE1
OTk1NTQ1MDEsImNsaWVudF9pZCI6IlJBX1RPT0wifQ.eBzsv8_x6DG5kP-
D1Jx2ODUkYJlC71m6aCOum7Q6ufrnu110JrBs9HF1_iO_2GovSnfHH8VZ2U4RkF8wGR3_nA\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 9.
Таблица 9 - Параметры ответа на запросы
о данных организации
Пример ответа с категориями, которые являются подтверждаемыми и не
подтверждаемыми (разрывы строки даны для удобства чтения):
{
"stateFacts": [
"Paginated",
"FirstPage"
],
"size": 4,
"pageSize": 100,
"pageIndex": 1,
"elements": [
{
"parentName": "Тестовая родительская категория 1",
"parentId": "1",
"catName": "Категория 1",
"catId": "109",
"catConfirm": "N",
"status": "OK",
"confirmDate": 1594760400000
},
{
"parentName": "Тестовая родительская категория 2",
"parentId": "2",
"catName": "Иные организации",
"catId": "24",
"catConfirm": "N",
"status": "OK",
"confirmDate": 1593637200000
},
{
"parentName": "Тестовая родительская категория 2",
"parentId": "2",
"catName": "Банки (Банковские кредитные организации)",
"catId": "6",
"catConfirm": "Y",
"confirmOrgName": "Федеральная налоговая служба",
"confirmOrgOid": 1000298999,
"confirmOrgValueType": "OGRN",
"confirmOrgVal": "1047707030513",
"status": "OK",
"confirmDate": 1593464400000
},
{
"parentName": "Тестовая родительская категория 2",
"parentId": "2",
"catName": "Категория 2",
"catId": "67",
"catConfirm": "Y",
"confirmOrgName": "Федеральная налоговая служба",
"confirmOrgOid": 1000298999,
"confirmOrgValueType": "OGRN",
"confirmOrgVal": "1047707030513",
"status": "OK",
"confirmDate": 1593637200000
}
]
}
Б.5 Предоставление списка участников организации
Для получения данных об участниках организации система-клиент должна направить по в https-адрес REST-API системы ЕСИА <37> запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Идентификатор этого ресурса в ЕСИА имеет следующий вид для получения списка сотрудников организации необходимо использовать uri/orgs/{orgOid}/emps/{prn_oid}, где:
--------------------------------
<37> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs
- emps - перечень (коллекция) сотрудников организаций с данным {orgOid}; для определения orgOid соответствующей организации необходимо использовать атрибут orgOid, передающийся в утверждениях SAML;
- prn_oid - внутренний идентификатор физического лица в ЕСИА.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/org_emps с параметрами).
Пример запроса (вызов сервиса в среде разработки):
GET /rs/orgs/1000000000/emps HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в Таблице 10.
Таблица 10 - Параметры ответа на запрос
об участниках организации
Для просмотра перечня сотрудников филиала организации необходимо указать в запросе параметр brhOid и значение идентификатора соответствующего филиала. Пример ссылки, по которой будет возвращен перечень сотрудников филиала с идентификатором 1004082214:
https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000001/emps?brhOid=1004082214
При отображении всех коллекций (orgs, emps) используется механизм paging.
Пример ответа на запрос сведений о перечне сотрудников организации с идентификатором 1000000000 (фрагмент, разрывы строк даны для удобства чтения):
"stateFacts": ["hasSize"],
"elements":[
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/222896320",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/240612402",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/243280304",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/243280305",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/243280312",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/1000000008",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/1000000009",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000000/emps/1000000385"
],
"size":"8"
}
Пример ответа с контактными данными о сотрудниках организации при использовании возможности встраивания <38> (разрывы строки даны для удобства чтения):
--------------------------------
<38> Запрос ресурса: /orgs/100000/emps?embed=(elements.person)
"stateFacts": ["Paginated", "FirstPage", "LastPage"],
"elements": [
{
"stateFacts": ["Identifiable"],
"prnOid": 1000000125,
"orgOid": 100000,
"chief": false,
"corporateContact": "mail@example.com",
"person": {
"stateFacts": ["Identifiable"],
"firstName": "Петр",
"lastName": "Петров",
"middleName": "Петрович",
"gender": "M",
"updatedOn": 1387519441
}
},
{
"stateFacts": ["Identifiable"],
"prnOid": 1000004892,
"orgOid": 100000,
"position": "Руководитель",
"chief": true,
"person": {
"stateFacts": ["Identifiable"],
"firstName": "Иван",
"lastName": "Иванов",
"middleName": "Иванович",
"gender": "M",
"updatedOn": 1387466948
}
}
],
"pageSize": 100,
"pageIndex": 1
}
Б.6 Предоставление сведений о вхождении пользователя в группы
Для получения данных о вхождении пользователя в группы организации система-клиент должна направить по в https-адрес REST-API системы ЕСИА <39> запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные.
--------------------------------
<39> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу - scope http://esia.gosuslugi.ru/org_emps с параметрами. Для доступа к полному перечню групп, владельцем которых является данная организация, необходим scope http://esia.gosuslugi.ru/org_grps.
Пример запроса (вызов сервиса в среде разработки):
GET /rs/orgs/1000000000/grps HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Данные, которые ЕСИА возвращает в ответ на запрос, представлены в Таблице 11.
Таблица 11 - Параметры ответа на запрос о вхождении
сотрудников организации в группы
При запросе перечня групп, членом которых является данный сотрудник, отображается перечень ссылок в следующем формате:
/orgs/{orgOid}/emps/{prn_oid}/grps/{grp_id}/{it_sys_id}, где it_sys_id - мнемоника информационной системы, в рамках которой действует данная группа. Пример ссылки на группу:
http://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000224/emps/1000000105/grps/ORG_ADMIN/ESIA
Данная ссылка означает, что пользователь с идентификатором 1000000105 как сотрудник организации 1000000224 включен в группу администраторов профиля организации (ORG_ADMIN) системы ЕСИА (мнемоника ESIA). Выполнив запрос по данной ссылке, можно получить краткую информацию о группе, которая включает в себя:
- описание группы (description);
- признак того, что группа является системной (system);
- мнемоника системы-владельца группы (itSystem).
"stateFacts": [
"Identifiable"
],
"grp_id": "ORG_ADMIN",
"name": "Администраторы профиля организации",
"description": "Сотрудники организации, имеющие право приглашать сотрудников, а также включать
сотрудников в группы доступа",
"system": "true",
"itSystem": "ESIA"
}
Если группа не является системной и не привязана ни к какой системе, то ссылка на нее имеет следующий формат:
/orgs/{orgOid}/emps/{prn_oid}/grps/{grp_id}
В кратких данных об этой группе атрибут "system" будет иметь значение "false".
При запросе перечня групп, членом которых является данный сотрудник, имеется возможность получить только те группы, которые относятся к определенной информационной системе. Для этого необходимо добавить условие на отбор групп выбранной системы (itSystemName), равное мнемонике данной системы. Пример запроса на получение групп системы ЕСИА (ESIA), в которые включен сотрудник:
GET /rs/orgs/1000000224/emps/1000000105/grps?itSystemName=ESIA HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
Б.7 Управление данными организации
Программные интерфейсы на основе REST обеспечивают возможность управления данными организации для информационных систем этой организации. Обеспечена возможность:
- изменять данные профиля организации;
- управлять приглашениями должностным лицам, зарегистрированным в ЕСИА, на присоединение к учетной записи соответствующей организации;
- управлять служебными данными присоединенных сотрудников, а также блокировать и удалять должностных лиц организации;
- управлять полномочиями должностных лиц посредством изменения их членства в группах доступа;
- предоставлять и отзывать доступ к непубличным группам;
- добавлять и изменять данные филиалов организации.
Для осуществления данных операций система организации должна направить в https-адрес программного интерфейса ЕСИА запрос методом POST, PUT или DELETE. Данный запрос в общем виде включает в себя новые атрибуты организации. Кроме того, запрос должен включать в себя следующие данные:
- маркер доступа, выданный системе на scope (в зависимости от полномочий системы) с параметром org_oid, принимающим значение идентификатора организации;
- тег объекта - метка изменяемого объекта (эта метка указывается в заголовке "If-Match" и в ряде случаев в теле запроса в параметре "eTag");
Для получения информации о метке изменяемого объекта необходимо сделать стандартный запрос методом GET на получение изменяемого ресурса - конкретных данных организации (если последующий запрос делается на адрес контейнера, то требуется указывать тег контейнера).
Пример метки изменяемого объекта (выделено полужирным шрифтом):
"stateFacts": [
"Identifiable"
],
"eTag": "4C50511FD3F404974C9AC8AB9C15683378DC05F8" *,
"oid": 1000000001,
"shortName": "Тестовая организация",
"fullName": " Тестовая организация ",
"type": "LEGAL",
"ogrn": "1047702026701",
"inn": "0000000000",
"leg": "65142"
}
Б.7.1 Изменение данных профиля организации
Программный интерфейс позволяет выполнить следующие операции:
- задать (изменить) организационно-правовую форму организации;
- задать, изменить и удалить служебные контакты организации (адрес электронной почты, номер телефона и факса);
- задать, изменить и удалить почтовый адрес организации;
- задать, изменить и удалить транспортные средства организации.
Б.7.1.1 Редактирование организационно-правовой формы организации
Для изменения организационно-правовой формы организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА <40>. В заголовке запроса должен быть указан маркер доступа и тег объекта (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}). В тело запроса должны быть включены:
--------------------------------
<40> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}
- <eTag> - тег изменяемого объекта (данных организации);
- <leg> - новый код организационно-правовой формы по общероссийскому классификатору организационно-правовых форм.
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.HeKYMBlwx4LAE-dEnAw9cDLrky-
g5133Q827J-pOiNC6Zct-KrZerA3AE6MTaHMicgqJrJls4LBg
Content-Type: application/json
If-Match: "DC48A40EEEE25605ED940193398AF417EE752055"
Cache-Control: no-cache
{"eTag": "DC48A40EEEE25605ED940193398AF417EE752055",
"leg": "65142"}
В качестве ответа ЕСИА возвращает данные организации с измененной организационно-правовой формой.
Б.7.1.2 Редактирование контактов организации
Для добавления контакта организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА <41>. В заголовке запроса должен быть указан маркер доступа и тег контейнера с адресами (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/ctts). В тело запроса должны быть включены:
--------------------------------
<41> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/ctts
- <type> - тип добавляемого контакта, принимает значение "OEM" для адреса электронной почты, "OPH" - телефона, "OFX" - факса;
- <value> - значение контакта.
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/ctts HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.HeKYMBlwx4LAE-dEnAw9cDLrky-
g5133Q827J-pOiNC6Zct-KrZerA3AE6MTaHMicgqJrJls4LBg
Content-Type: application/json
If-Match: "DC48A40EEEE25605ED940193398AF417EE752055"
Cache-Control: no-cache
{"type": "OEM",
"value": "test@test.com"}
Для изменения контакта организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА <42>. В заголовке запроса должен быть указан маркер доступа и тег объекта (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/ctts/{ctt_id}). В тело запроса должны быть включены:
--------------------------------
<42> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/ctts/{ctt_id}
- <eTag> - тег изменяемого объекта (контакта);
- <type> - тип изменяемого контакта, принимает значение "OEM" для адреса электронной почты, "OPH" - телефона, "OFX" - факса;
- <value> - значение контакта.
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/ctts/58099 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.HeKYMBlwx4LAE-dEnAw9cDLrky-
g5133Q827J-pOiNC6Zct-KrZerA3AE6MTaHMicgqJrJls4LBg
Content-Type: application/json
If-Match: "011EAB0AB1B69D4178158841E8096AE5DD9A233C "
Cache-Control: no-cache
{ "eTag": "011EAB0AB1B69D4178158841E8096AE5DD9A233C",
"type": "OPH",
"value": "+7(999)9999888" }
Изменение контакта возможно и без указания в URL запроса идентификатора контакта, в этом случае контакт будет изменен, но ему будет присвоен другой идентификатор.
Для удаления контакта организации должен быть выполнен запрос методом DELETE на https-адрес программного интерфейса ЕСИА <43>. В заголовке запроса должен быть указан маркер доступа и тег удаляемого объекта.
--------------------------------
<43> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/ctts/{ctt_id}
Пример запроса (разрывы строки даны для удобства чтения):
DELETE /rs/orgs/1000000001/ctts/58099 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.HeKYMBlwx4LAE-dEnAw9cDLrky-
g5133Q827J-pOiNC6Zct-KrZerA3AE6MTaHMicgqJrJls4LBg
Content-Type: application/json
If-Match: "DC48A40EEEE25605ED940193398AF417EE752055"
Cache-Control: no-cache
Б.7.1.3 Редактирование почтового адреса организации
Для добавления почтового адреса организации необходимо сделать запрос методом POST на https-адрес программного интерфейса ЕСИА <44>. Заголовок запроса должен включать в себя маркер доступа и тег контейнера адресов (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/addrs).
--------------------------------
<44> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/addrs
Тело запроса должно включать следующие данные (указываются все данные, которые должны отображаться в адресе этого типа):
- тип адреса (type), принимает значение "OPS";
- строка адреса (addressStr), например, "Москва город, Тверская улица";
- идентификатор страны (countryId), для России - "RUS";
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/addrs HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0
Content-Type: application/json
If-Match: "DE3372D5A4E2499C38C24E03C1919C9CA97FCF78"
Cache-Control: no-cache
{
"type": "OPS",
"region": "Псковская Область",
"fiasCode": "5bf5ddff-6353-4a3d-80c4-6fb27f00c6c1",
"addressStr": "Псковская область, Невельский район, Невель город, Невель 1 поселок и(при)
станция(и)",
"city": "Невель Город",
"area": "Невельский Район",
"countryId": "RUS",
"zipCode": "182500",
"street": "Невель 1 Поселок и(при) станция(и)",
"house": "5",
"flat": "5"
}
Изменение адреса осуществляется по аналогии с добавлением, недопустимо делать запрос с указанием конкретного идентификатора адреса.
Для удаления почтового адреса организации необходимо сделать запрос методом DELETE на https-адрес программного интерфейса ЕСИА <45>. Заголовок запроса должен включать в себя маркер доступа и тег удаляемого адреса (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/addrs/{addr_id}).
--------------------------------
<45> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/addrs/{addr_id}
Пример запроса (разрывы строки даны для удобства чтения):
DELETE /rs/orgs/1000000001/addrs/13854 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0
Content-Type: application/json
If-Match: "DE3372D5A4E2499C38C24E03C1919C9CA97FCF78"
Cache-Control: no-cache
Б.7.1.4 Управление транспортными средствами организации
Для добавления записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST <46>. Заголовок запроса должен включать в себя маркер доступа, тег контейнера транспортных средств (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/vhls).
--------------------------------
<46> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/vhls
Тело запроса должно включать следующие данные:
- <name> - название транспортного средства;
- <numberPlate> - государственный номерной знак;
- <regCertificate> - данные свидетельства о регистрации:
POST /rs/orgs/1000000001/vhls HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Content-Type: application/json
If-Match: "3FEA16CB36AFC793234553C1C7CAAF89CD79A32D"
{
"name": "ВАЗ",
"numberPlate": "А133ОН199",
"regCertificate":{
"series": "1234",
"number": "123456"
}
}
Для изменения записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST <47>. Заголовок запроса должен включать в себя маркер доступа, тег записи транспортного средства (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/vhls/{vhl-id}).
--------------------------------
<47> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/vhls/{vhl_id}
Тело запроса должно включать следующие данные:
- <eTag> - тег записи транспортного средства;
- <name> - название транспортного средства;
- <numberPlate> - государственный номерной знак;
- <regCertificate> - данные свидетельства о регистрации:
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/vhls/1000037688 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
If-Match: "3FEA16CB36AFC793234553C1C7CAAF89CD79A32D"
{
"eTag": "3FEA16CB36AFC793234553C1C7CAAF89CD79A32D",
"name": "Новый ВАЗ",
"numberPlate": "А144ОН199",
"regCertificate":{
"series": "1234",
"number": "123456"
}
}
Для удаления записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE <48>. Заголовок запроса должен включать в себя маркер доступа, тег записи транспортного средства (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/vhls/{vhl-id}).
--------------------------------
<48> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/vhls/{vhl_id}
Пример запроса (разрывы строки даны для удобства чтения):
DELETE /rs/orgs/1000000001/vhls/1000037688 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Content-Type: application/json
If-Match: "F040CD4DD62478E6843177FF33BB6BA1AF8ECF8F"
Cache-Control: no-cache
Б.7.2 Управление приглашениями должностным лицам, зарегистрированным в ЕСИА, на присоединение к учетной записи соответствующей организации
Программный интерфейс ЕСИА позволяет выполнять следующие функции:
- просмотр отправленных, но не принятых приглашений;
- формирование нового приглашения;
- отзыв ранее отправленного приглашения.
Для просмотра отправленных приглашений необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом GET <49>. Заголовок запроса должен включать в себя маркер доступа. Пример запроса:
--------------------------------
<49> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/invts
GET /rs/orgs/1000000001/invts HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
В качестве ответа ЕСИА возвращает перечень приглашений на присоединение к данной организации. Пример ответа:
"stateFacts": [
"LastPage",
"Paginated",
"FirstPage"
],
"pageSize": 10,
"pageIndex": 1,
"elements": [
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000001/invts/671621",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000001/invts/671620",
"https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000001/invts/671600"
]
}
Для получения данных об отдельном приглашении необходимо выполнить запрос методом GET по адресу с данными конкретного приглашения. Каждое приглашение описывается следующими параметрами:
- <invtId> - идентификатор приглашения;
- <eTag> - тег записи приглашения;
- <email> - адрес, на который было отправлено приглашение;
- <firstName> - имя приглашаемого сотрудника;
- <lastName> - фамилия приглашаемого сотрудника;
- <middleName> - отчество приглашаемого сотрудника (необязательно);
- <snils> - СНИЛС приглашаемого сотрудника (необязательно);
- <status> - статус приглашения (принимает значение "A" (активно) и "I" (инициировано, но не отправлено));
- <createdOn> - дата отправления приглашения;
- <groups> - группа, в которую будет включен пользователь (указывается мнемоника группы) (необязательно).
"stateFacts": [
"Identifiable"
],
"eTag": "E4EFE25E314136A0EB0DC4EB68DF4B5C185D3E4E",
"invtId": 671600,
"email": "test@mail.ru",
"firstName": "Иван",
"lastName": "Иванов",
"middleName": "Владимирович",
"status": "A",
"createdOn": "23.10.2015",
"groups": [
"ORG_ADMIN"
]
}
Чтобы отправить приглашение, необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом PUT <50>. Заголовок запроса должен включать в себя маркер доступа, а тело запроса должно включать следующие данные:
--------------------------------
<50> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/invts
- <email> - адрес, на который отправлять приглашение;
- <firstName> - имя приглашаемого сотрудника;
- <lastName> - фамилия приглашаемого сотрудника;
- <middleName> - отчество приглашаемого сотрудника (необязательно);
- <snils> - СНИЛС приглашаемого сотрудника (необязательно).
Пример запроса (разрывы строки даны для удобства чтения):
PUT /rs/orgs/1000000001/invts HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDYyMTU2ND
Content-Type: application/json
Cache-Control: no-cache
{
"email": "test@yandex.ru",
"snils": "000-333-333 66",
"firstName": "Михаил",
"lastName": "Иванов",
"middleName": "Иванович"
}
Чтобы удалить приглашение, необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE <51>. Заголовок запроса должен включать в себя маркер доступа. Пример запроса:
--------------------------------
<51> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/invts/{invt_id}
DELETE /rs/orgs/1000000001/invts/671774 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDYyMTU2ND
Content-Type: application/json
Cache-Control: no-cache
Б.7.3 Управление служебными данными присоединенных сотрудников, а также блокировка и удаление должностных лиц организации
Для изменения данных сотрудника организации, в том числе - изменения признака блокировки - необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST <52>. Заголовок запроса должен включать в себя маркер доступа, тег данных сотрудника (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/emps/{emp_id}).
--------------------------------
<52> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/emps/{emp_id}
Тело запроса должно включать следующие данные (все параметры обязательны):
- <eTag> - тег данных сотрудника;
- <position> - должность сотрудника;
- <corporateContact> - адрес электронной почты сотрудника;
- <blocked> - признак блокировки ("false" - не заблокирован, "true" - не заблокирован).
Если какой-либо параметр не будет указан, то он будет очищен.
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/emps/1000000128 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDYyMTU2ND
Content-Type: application/json
If-Match: "523E509CBEB781E992EFC503CBC878AC67BAD414"
Cache-Control: no-cache
{
"eTag": "523E509CBEB781E992EFC503CBC878AC67BAD414",
"position": "должность",
"corporateContact": "test@example3.com",
"blocked": false
}
Для удаления сотрудника необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE <53>. Заголовок запроса должен включать в себя маркер доступа. Пример запроса:
--------------------------------
<53> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/emps/{emp_id}
DELETE /rs/orgs/1000000001/emps/1000000128 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Content-Type: application/json
Б.7.4 Управление полномочиями должностных лиц посредством изменения их членства в группах доступа
Чтобы включить сотрудника в группу, необходимо знать его идентификатор, мнемонику группы и мнемонику системы, к которой принадлежит данная группа.
Добавление сотрудника в группу осуществляется запросом методом PUT на следующий https-адрес программного интерфейса ЕСИА:
https://esia-portal1.test.gosuslugi.ru/rs/orgs/1000000001/emps/{emp_id}/grps/{grp_id}/{it_sys_id}
Параметр <it_sys_id> - мнемоника информационной системы, в рамках которой создана данная группа. Пример запроса:
PUT /rs/orgs/1000000001/emps/1000023747/grps/ORG_ADMIN/ESIA HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Данный запрос включает сотрудника с идентификатором 1000023747 в группу "Администраторы профиля организации", принадлежащей ЕСИА.
Для исключения сотрудника из группы нужно вызвать программный интерфейс ЕСИА по указанному выше адресу (адрес для добавления сотрудника в группу) методом DELETE. Пример запроса:
DELETE /rs/orgs/1000000001/emps/1000023747/grps/ORG_ADMIN/ESIA HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Б.7.5 Управление доступом к непубличным группам
Программный интерфейс позволяет предоставить другой организации доступ к непубличной группе (если организация, вызывающая сервис, является владельцем данной группы), а также отозвать доступ.
Пусть организация с идентификатором 1000000001 - владелец приватной группы RA.USR_CFM ("Операторы системы подтверждения личности"). С помощью программного интерфейса эта организация может:
- посмотреть перечень организаций, которым предоставлена данная группа;
- дать некоторой организации доступ к данной группе;
- отозвать у организации доступ к группе.
Для просмотра списка организаций, которым предоставлен доступ к указанной группе, необходимо выполнить запрос методом GET в адрес программного интерфейса ЕСИА <54>. В заголовке запроса должен быть указан маркер доступа. Имеется возможность вызвать этот сервис с функцией встраивания (embed), чтобы сразу был виден перечень организаций, которым предоставлен доступ. Пример запроса:
--------------------------------
<54> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/grps/{grp_id}/perms
GET /rs/orgs/1000000001/emps/1000023747/grps/RA.USR_CFM/perms?embed=(elements) HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Cache-Control: no-cache
Пример ответа, из которого видно, что доступ предоставлен четырем организациям (указаны их ОГРН и идентификаторы разрешений):
"stateFacts": [
"hasSize"
],
"size": 4,
"elements": [
{
"stateFacts": [
"Identifiable"
],
"permId": 732,
"ogrn": "1047707030513"
},
{
"stateFacts": [
"Identifiable"
],
"permId": 21,
"ogrn": "1023101651154"
},
{
"stateFacts": [
"Identifiable"
],
"permId": 104,
"ogrn": "1027700367507"
},
{
"stateFacts": [
"Identifiable"
],
"permId": 107,
"ogrn": "1027802761282"
}
]
}
Для добавления организации в этот перечень необходимо выполнить запрос методом POST в адрес этого же программного интерфейса ЕСИА <55>. В заголовке запроса должен быть указан маркер доступа. В теле запроса должны быть указаны параметры:
--------------------------------
<55> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/grps/{grp_id}/perms
- <rqCfm> - признак, определяющий, что включение в группу требует персонального согласования со стороны владельца группы (для этого он должен иметь значение "true").
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/grps/RA.USR_CFM/perms/ HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Content-Type: application/json
Cache-Control: no-cache
{ "ogrn": "1047796940465",
"rqCfm": false }
Для отзыва доступа необходимо выполнить запрос методом DELETE по адресу конкретного разрешения. Пример запроса:
DELETE/rs/orgs/1000000001/grps/RA.USR_CFM/perms/1103 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Cache-Control: no-cache
Б.7.6 Добавление и изменение данных филиалов организации
Программный интерфейс ЕСИА позволяет выполнить следующие операции:
- добавить филиал организации;
- изменить данные филиала организации.
Для добавления записи о филиале необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST <56>. Заголовок запроса должен включать в себя маркер доступа, тег контейнера филиалов (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/brhs).
--------------------------------
<56> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/brhs
Тело запроса должно включать следующие данные:
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/brhs HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
Content-Type: application/json
If-Match: "3FEA16CB36AFC793234553C1C7CAAF89CD79A32D"
{ "name": "Филиал КПП 111111112",
"kpp": "111111112" }
Для изменения записи о филиале - его названия или КПП - необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST <57>. Заголовок запроса должен включать в себя маркер доступа, тег записи филиала (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/{oid}/brhs/{brh-id}).
--------------------------------
<57> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs/{org_oid}/brhs/{brh_id}
Тело запроса должно включать следующие данные:
Пример запроса (разрывы строки даны для удобства чтения):
POST /rs/orgs/1000000001/brhs/1004083064 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlc
If-Match: "3FEA16CB36AFC793234553C1C7CAAF89CD79A32D"
{ "name": "Новый филиал",
"kpp": "111111113" }
Б.8 Предоставление списка измененных пользователей или организаций за период времени
Вызов данной операции предоставляет интегрированным с ЕСИА информационным системам данные об измененных пользователях или организаций в ЕСИА. Для получения перечня измененных пользователей или организаций система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. В качестве этого ресурса используется стандартный идентификатор ресурса с персональными данными пользователей (/prns), возвращающий перечень зарегистрированных в системе пользователей (см. раздел Б.2) или стандартный ресурс со списком организаций (/orgs), возвращающий коллекцию организаций (см. Б.4). Специфика вызова данной операции состоит в том, что запрос должен содержать следующий параметр:
- <updatedSince> - дата, начиная с которой необходимо отобразить измененных пользователей. Задается как количество секунд, прошедших с 00:00:00 UTC 1 января 1970 года.
В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/tech_inf).
Пример запроса списка измененных организаций (вызов сервиса в среде разработки):
GET /rs/prns?updatedSince=1384218061 HTTP/1.1\r\n
Authorization: Bearer 75b2c7cbb8da403491c224c9e431cef9\r\n
Host: esia-portal1.test.gosuslugi.ru\r\n
Accept: */*\r\n
\r\n
В качестве ответа передается перечень пользователей или организаций, обновленных с указанной даты. Этот перечень представляет собой список ссылок на ресурс с указанием {oid}, содержащий идентификаторы всех измененных пользователей или организаций с момента указанной в запросе даты.
Б.9 Импорт учетной записи пользователя
Программный интерфейс, основанный на архитектурном стиле REST, в целях обеспечения импорта в ЕСИА учетных записей других ИС, обеспечивает возможность проверки наличия учетной записи пользователя, а в случае ее отсутствия, регистрации пользователя в ЕСИА. Алгоритм, по которому производится импорт учетной записи, приводится на рисунке ниже (см. Рисунок 14).
Рисунок 14 - Обобщенный алгоритм импорта в ЕСИА
На рисунке 14 представлено слияние трех схем алгоритмов импорта: "Подтверждение учетной записи в ЕСИА", "Подтверждение УЗ с несовпадающими контактами" и "Механизм проверки паспортных данных в импорте".
Схема импорта "Подтверждение УЗ с несовпадающими контактами" представлена на схеме с помощью синего цвета, а схема импорта "Механизм проверки паспортных данных в импорте" представлена с помощью красного цвета.
Соответственно, черным цветом представлена схема импорта "Подтверждение учетной записи в ЕСИА".
Для импорта учетных записей система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом POST: https://esia.gosuslugi.ru/esia-rs/api/public/v2/prns/import (для продуктивной среды).
В запросе на импорт учетной записи передаются следующие данные пользователя:
Текстовая строка, содержащая не более 60 символов. | ||||
Текстовая строка, содержащая не более 60 символов. | ||||
Текстовая строка, содержащая не более 60 символов. Необязательно, в случае если отчество отсутствует в паспорте. | ||||
Текстовая строка, содержащая не более 700 символов. | ||||
Гражданство по классификатору ОКСМ | Используется трехбуквенный код страны, например, для России он должен принимать значение RUS. По умолчанию принимается значение "RUS". Обязателен в случае, если указанный документ отличен от паспорта РФ. | |||
- "M" - мужской; - "F" - женский. | ||||
- "MBT" - мобильный телефон (обязательный параметр); - "EML" - электронная почта (необязательный параметр). | ||||
- "+X(XXX)XXXXXXX" (для type = "MBT"); - текстовая строка в формате адреса электронной почты (для type = "EML"). | ||||
- "RF_PASSPORT" - паспорт гражданина РФ; - "FID_DOC" - документ иностранного гражданина, удостоверяющий личность на территории РФ; - "FRGN_PASS" - заграничный паспорт гражданина РФ. | ||||
Для паспорта гражданина РФ в формате XXXX. Для заграничного паспорта гражданина РФ в формате XX. Необязательный для документа иностранного гражданина. | ||||
Для паспорта гражданина РФ в формате XXXXXX. Для заграничного паспорта гражданина РФ в формате XXXXXXX. | ||||
latinLastName | Фамилия (латиницей) | Y/N | Только для заграничного паспорта гражданина РФ. Текстовая строка, содержащая не более 60 символов. | |
latinFirstName | Имя (латиницей) | Y/N | Только для заграничного паспорта гражданина РФ. Текстовая строка, содержащая не более 60 символов. | |
Только для паспорта гражданина РФ. Необязательный для документа иностранного гражданина и заграничного паспорта гражданина РФ. Строка, 6 символов. | ||||
Только для паспорта гражданина РФ. Необязательно для документа иностранного гражданина и заграничного паспорта гражданина РФ. Текстовая строка, содержащая не более 233 символа. | ||||
Формат: ДД.ММ.ГГГГ | ||||
expireDate | Дата окончания срока действия документа | Y/N | Только для заграничного паспорта гражданина РФ. Формат: ДД.ММ.ГГГГ | |
- "PLV" - адрес проживания; - "PRG" - адрес регистрации. | ||||
Текстовая строка, содержащая элементы адреса (перечисляются через разделитель ",", не более 2000 символов) | ||||
В формате XXX. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
Текстовая строка, содержащая не более 256 символов. | ||||
В запрос должен быть добавлен header (Authorization: Bearer) с ранее полученным маркером доступа, выданный на специальный scope (http://esia.gosuslugi.ru/ext_imp), позволяющий осуществлять автоматический импорт учетной записи пользователя. Данный маркер выдается только доверенным системам, имеющим право импорта пользователей таким образом; выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента (Приложение В.3), т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА.
В заголовке (Header) запроса метода импорта, помимо параметра Authorization (маркер доступа, Bearer<пробел><тело маркера>), необходимо передавать два параметра:
- Request-Data - тело параметров запроса (JSON), закодированное в base64;
- Request-Data-Sign - подпись запроса - подписанное сертификатом ИС-потребителя (системы, направляющей запрос на импорт) тело (JSON) параметров запроса.
Request-Data-Sign - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от от JSON с параметрами запроса. Request-Data-Sign должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012.
Пример запроса (вызов сервиса в среде разработки):
POST https://esia.gosuslugi.ru/esia-rs/api/public/v2/prns/import HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE1OTYwMjI3NDM
sInNjb3BlIjoiaHR0cDpcL1wvZXNpYS5nb3N1c2x1Z2kucnVcL2V4dF9pbXAiLCJpc3MiOiJodHRwOlwvXC9lc2lhLm
dvc3VzbHVnaS5ydVwvIiwidXJuOmVzaWE6c2lkIjoiY2NjYTExZWUwOGY1MDM4NzE2NzY2ODMyNDdjNzU3ODAwNTFmO
DRhNGExMWQxMDY5YTEwNmIzNjUyZjgxNjUxNSIsInVybjplc2lhOnNial9pZCI6MTA3NzExNDA1NCwiZXhwIjoxNTk2
MDI0NTQzLCJpYXQiOjE1OTYwMjI3NDMsImNsaWVudF9pZCI6IlRFU1RfU1lTIn0.ZG4e0Hs_hHwubfYLc94ph1bPaof
3opfeLjw8GczXfI-
CKD683KFvPE_mqGo0WjgtarM4Cd1zRU_FitqXQl4DsmZW94aVHjfyS6ti4ERtEwby3ifQfY_8qefnzIpZ2EtlAbGNaj
7jWpdJlhKQcigBKi_60eOinrUYwcEy1EdnRKIHDyrrydfh-
MN3ZQSEx8aMYMm3IATPrktJPZ8LryD2wlkWq3PuxFAxFLEaLo0r-
F8FRU1hPlNyUrTCRp6vNmlLO_TVe2l28gRdcxZJKAdHggXmRXVceT7cMGUOY4b2VnTID3G_w7FuVIjURQZy46HQ3X5t
H9IiGfoqi2dhD5y3AQ
Request-Data-Sign:
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIDJTCCAg0CBFhKg5U
wDQYJKoZIhvcNAQELBQAwVzELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzENMAsGA1UECgwEVGVzdDENMAsGA1
UECwwEVGVzdDEZMBcGA1UEAwwQVGVzdCBSZXN0IFN5c3RlbTAeFw0xNjEyMDkxMDEyMzdaFw0xNzEyMDkxMDEyMzdaM
FcxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZNb3Njb3cxDTALBgNVBAoMBFRlc3QxDTALBgNVBAsMBFRlc3QxGTAXBgNV
BAMMEFRlc3QgUmVzdCBTeXN0ZW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCByEsM2_R1BrtltyJ15Aw
CW_tChh2euZC3FEqWDY6TFAlVyy9yO4qM_5P1WruplhA9dCCbft5JFsz4n_nE7lMMRaI34tqTyyo24xzX_VrhgTIi05
mt1Y5dbldfEiPVNT3aUCjFlbFzDXoUbc8nfQizkPa_CHGO0MBhuVuQWOVzw3FufAlExDjNPUoRRvaYoBWOK_3SnyS7_
88xJn-_yQQVwu0TQkSuqpOsylfBM-
Wq10U5x4bJ2NSeL71AzZjCL_mh1daQTQxEwBlVLuMlc5srMyw_QHQ1McsNrqrnx3zhFFNLS5Sk_LrSxqxOsC4sgBw1o
udVayUUvGbqe_nxu7P3AgMBAAEwDQYJKoZIhvcNAQELBQADggEBABxK0C1NjQMyvtJvZNRyM21GwQOklaBZuqRErJmp
LAR7auYLbZnwEdt1I8KEJBQW6pTb99rnQs-T-
qZiChh0PYlbCxXGeVCXk5dJWSiGE_SdrjWvSOH83iUA2Lv8Pi3NlVW2GcNOlFySlzE9HvGYJTIr5I_X-dw64-
2NYETLIYPQ7HWwAEwy09ucL9LMjGKYBe5FrwiulAyD20-lnIpYtXdLSpflKangPlPd1xmxEBXMQUmoKg7dTE-
q2gYfZLNUKsAezrattHGHTPRnqwWQHmwly_rXXodlgcNxeilT_dvc0o_JfkNmqGCc09RXSx1BWSWGynLeBBjYMy9VN8
XYQpQAADGCAfUwggHxAgEBMF8wVzELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzENMAsGA1UECgwEVGVzdDENM
AsGA1UECwwEVGVzdDEZMBcGA1UEAwwQVGVzdCBSZXN0IFN5c3RlbQIEWEqDlTANBglghkgBZQMEAgEFAKBpMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyMDE1NTA1NVowLwYJKoZIhvcNAQkEMSIEIOp
wKJnoLommyNRoKDDlWVsWuBdYfowQ4byOiN-
gSPe2MA0GCSqGSIb3DQEBAQUABIIBADlNWxdZeqGBq8_4WqRs9H4SLde_Sukc1AG6hNj1cbTqxzthzzm1n_JQEZOTYa
P9bQdTEhOvKZXxFXC_JjPBMQauZPJc1eOR5DDB_7X4MAgGpMQbhpTQz3Sg7acJuJdWuYxL92BDk4qyzuwgJdQJplVJi
ckBvC78XeJVo1w4_jx5CVEn3pUIPdKxib6da0evB6CsxD98JcsvWZ3u-
H3LQ0_ApUOUHeF84r3AZ5mtILYj2w6o8rMAmsTDe7CAUXvDUAp9o5cTPk57rDNaW96d5J3SUtmZdx2nGBS41kJYWJND
iqyfHJ7X4nZVOS0glbT_JnaXtxrZTWp9BJo6NKJaagQAAAAAAAA
Request-Data:
ew0KICAiZmlyc3ROYW1lIjoiw5DCmMOQwrLDkMKww5DCvcOQwr7DkMKyIiwNCiAgImxhc3ROYW1lIjoiw5DCmMOQwrL
DkMKww5DCvSIsDQogICJtaWRkbGVOYW1lIjoiw5DCmMOQwrLDkMKww5DCvcOQwr7DkMKyw5DCuMORwociLA0KICAiYm
lydGhEYXRlIjoiMDEuMDEuMTk5OSIsDQogICJiaXJ0aFBsYWNlIjoiw5DCnMOQwr7DkcKBw5DCusOQwrLDkMKwIiwNC
iAgImdlbmRlciI6Ik0iLA0KICAic25pbHMiOiIwMDAtMDAwLTAwMCAwNyIsDQogICJjb250YWN0cyI6IHsNCiAgICAi
ZWxlbWVudHMiOiBbDQogICAgICB7DQogICAgICAgICJ0eXBlIjogIk1CVCIsDQogICAgICAgICJ2YWx1ZSI6ICIrNyg
5OTkpOTk5OTk5OSINCiAgICAgIH0sDQogICAgICB7DQogICAgICAgICJ0eXBlIjogIkVNTCIsDQogICAgICAgICJ2YW
x1ZSI6ICJ0ZXN0QHRlc3QudHMiDQogICAgICB9DQogICAgXQ0KICB9LA0KICAiZG9jdW1lbnRzIjogew0KICAgICJlb
GVtZW50cyI6IFsNCiAgICAgIHsNCiAgICAgICAgInR5cGUiOiJSRl9QQVNTUE9SVCIsDQogICAgICAgICJzZXJpZXMi
OiIyMjIyIiwNCiAgICAgICAgIm51bWJlciI6Ijg4OTk5OSIsDQogICAgICAgICJpc3N1ZUlkIjoiMTExMDAxIiwNCiA
gICAgICAgImlzc3VlZEJ5Ijoiw5DCoMOQwqPDkMKSw5DClCDDkMKzLsOQwpzDkMK-
w5HCgcOQwrrDkMKyw5HCiyIsDQogICAgICAgICJpc3N1ZURhdGUiOiIxOC4wMy4yMDE2Ig0KICAgICAgfQ0KICAgIF0
NCiAgfSwNCiAgImFkZHJlc3NlcyI6ew0KICAgICJlbGVtZW50cyI6IFsNCiAgICAgIHsNCiAgICAgICJ0eXBlIjogIl
BMViIsDQogICAgICAiYWRkcmVzc1N0ciI6IsOQwprDkMK1w5DCvMOQwrXDkcKAw5DCvsOQwrLDkcKBw5DCusOQwrDDk
cKPIMOQwp7DkMKxw5DCu8OQwrDDkcKBw5HCgsORwowsIMOQwqLDkMKww5HCiMORwoLDkMKww5DCs8OQwr7DkMK7w5HC
jMORwoHDkMK6w5DCuMOQwrkgw5DCoMOQwrDDkMK5w5DCvsOQwr0sIMOQwqjDkMK1w5HCgMOQwrXDkMKzw5DCtcORwog
gw5DCn8OQwr7DkcKBw5DCtcOQwrvDkMK-w5DCuiDDkMKzw5DCvsORwoDDkMK-
w5DCtMORwoHDkMK6w5DCvsOQwrPDkMK-
ICAgICDDkcKCw5DCuMOQwr_DkMKwIiwNCiAgICAgICJjb3VudHJ5SWQiOiAiUlVTIiwNCiAgICAgICJ6aXBDb2RlIjo
gIjM5NDAwMCIsDQogICAgICAicmVnaW9uIjogIsOQwprDkMK1w5DCvMOQwrXDkcKAw5DCvsOQwrLDkcKBw5DCusOQwr
DDkcKPIMOQwp7DkMKxw5DCu8OQwrDDkcKBw5HCgsORwowiLA0KICAgICAgImFyZWEiOiAiw5DCosOQwrDDkcKIw5HCg
sOQwrDDkMKzw5DCvsOQwrvDkcKMw5HCgcOQwrrDkMK4w5DCuSDDkMKgw5DCsMOQwrnDkMK-
w5DCvSIsDQogICAgICAiY2l0eSI6ICLDkMKow5DCtcORwoDDkMK1w5DCs8OQwrXDkcKIIMOQwp_DkMK-
w5HCgcOQwrXDkMK7w5DCvsOQwrogw5DCs8OQwr7DkcKAw5DCvsOQwrTDkcKBw5DCusOQwr7DkMKzw5DCviDDkcKCw5D
CuMOQwr_DkMKwIiwNCiAgICAgICJkaXN0cmljdCI6ICLDkMK9w5DCtcORwoIiLA0KICAgICAgInNldHRsZW1lbnQiOi
Aiw5DCo8ORwoHDkcKCw5HCjC3DkMKQw5DCvcOQwrfDkMKww5HCgSDDkMKfw5DCvsORwoHDkMK1w5DCu8OQwr7DkMK6I
iwNCiAgICAgICJzdHJlZXQiOiAiw5DCocOQwr7DkMKyw5DCtcORwoLDkcKBw5DCusOQwrDDkcKPIMOQwqPDkMK7w5DC
uMORwobDkMKwIiwNCiAgICAgICJhZGRpdGlvbkFyZWEiOiAiw5DCoMOQwrXDkMKzw5DCuMOQwr7DkMK9IMOQwqHDkMK
ww5DCtMOQwr7DkMKyw5DCvsOQwrUgw5DCvcOQwrXDkMK6w5DCvsOQwrwtw5DCtSDDkcKCw5DCvsOQwrLDkMKww5HCgM
OQwrjDkcKJw5DCtcORwoHDkcKCw5DCssOQwr4iLA0KICAgICAgImFkZGl0aW9uQXJlYVN0cmVldCI6ICLDkMKiw5DCt
cORwoHDkcKCIiwNCiAgICAgICJob3VzZSI6ICI4Ni8xIiwNCiAgICAgICJidWlsZGluZyI6ICJlIiwNCiAgICAgICJm
cmFtZSI6ICIyMDTDkcKDIiwNCiAgICAgICJmbGF0IjogIsOQwr_DkMK-
w5DCvC40MTkiLA0KICAgICAgImZpYXNDb2RlIjogIjc3LTAtMDAwLTAwMC0wMDAtMDAwLTQyMzYtMDAwMC0wMDAiDQo
NCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIF0NCiAgfQ0KfQ
Cache-Control: no-cache
Content-Length: 1476
Host: esia-portal1.test.gosuslugi.ru
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
"firstName":"Иванов",
"lastName":"Иван",
"middleName":"Иванович",
"birthDate":"01.01.1999",
"birthPlace":"Москва",
"gender":"M",
"snils":"000-000-000 07",
"contacts": {
"elements": [
{
"type": "MBT",
"value": "+7(999)9999999"
},
{
"type": "EML",
"value": "test@test.ts"
}
]
},
"documents": {
"elements": [
{
"type":"RF_PASSPORT",
"series":"2222",
"number":"889999",
"issueId":"111001",
"issuedBy":"РУВД г.Москвы",
"issueDate":"18.03.2016"
}
]
},
"addresses":{
"elements": [
{
"type": "PLV",
"addressStr": "Кемеровская область, Таштагольский район, Шерегеш поселок городского
типа, Усть-Анзас поселок, Советская улица",
"countryId": "RUS",
"zipCode": "652975",
"region": "Кемеровская Область",
"area": "Таштагольский Район",
"city": "Шерегеш Поселок городского типа",
"settlement": "Усть-Анзас Поселок",
"house": "Дом 19",
"fiasCode": "5bf5ddff-6353-4a3d-80c4-6fb27f00c6c1"
}
]
}
}
По полученным данным в ЕСИА выполняется поиск учетной записи. В зависимости от того, найдена в ЕСИА учетная запись, удовлетворяющая полученным данным, или нет, операция импорта может завершиться одним из следующих результатов:
- пользователь уже зарегистрирован в ЕСИА (подтвержденная учетная запись найдена по СНИЛС, данные паспорта и телефона совпадают);
- некоторые атрибуты не совпадают (учетная запись найдена по СНИЛС, но не все атрибуты совпадают);
- пользователь ЕСИА успешно подтвержден (найдена стандартная или готовая к подтверждению учетная запись по СНИЛС, данные паспорта и телефона совпадают, найденная учетная запись успешно подтверждена);
- пользователь ЕСИА успешно переподтвержден (найдена УЗ, подтвержденная через Почту России, данные паспорта и телефона совпадают, найденная учетная запись успешно переподтверждена);
- создана заявка на подтверждение упрощенной учетной записи (найдена упрощенная учетная запись по одному или нескольким контактам, создана заявка на запуск проверок данных в ведомствах и подтверждение, получен номер заявки на подтверждение);
- создана заявка на регистрацию (не найдена учетная запись пользователя, в том числе упрощенная, создана заявка на регистрацию, получен номер заявки на регистрацию).
В ответе передаются следующие параметры:
Может быть возвращен в виде значений: - 0 или 1 - выполнен импорт учетной записи; - 2 - создана заявка на импорт (регистрацию) учетной записи; - 3 - создана заявка на импорт (подтверждение) учетной записи; - код ошибки, варианты приведены в Таблице 12. | |||
Описание для кодов успешного импорта учетной записи в ЕСИА (code = 0, 1 или 2) и для code = ESIA-03200. | |||
message | Текстовое описание кода ошибки выполнения операции | Описание для кодов ошибок при импорте учетной записи в ЕСИА (за исключением кода ESIA-03200) Варианты ошибок приведены в Таблица 12 |
Условия отображения параметров "description" и "message"
1. Параметр "description" отображается при успешном завершении операции импорта, либо при завершении с кодом ошибки ESIA-03200.
Пример ответа на запрос (пользователь уже зарегистрирован в ЕСИА, учетная запись уже подтверждена ранее):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"0", "description":"Person already has trusted account in ESIA"}
2. Параметр "message" отображается при завершении операции импорта ошибкой. Пример ответа на запрос (пользователь указал неверное количество символов в поле "Номер" паспорта РФ):
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 26 Apr 2021 06:54:13 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"ESIA-033102", "message": "Номер паспорта должен состоять из 6 цифр"}
Далее приводятся варианты ответов сервиса, при завершении операции импорта.
Пример ответа на запрос (пользователь уже зарегистрирован в ЕСИА, учетная запись уже подтверждена ранее):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"1", "description":"Person already has trusted account in ESIA"}
Пример ответа на запрос (учетная запись пользователя успешно переподтверждена в ЕСИА):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"1", "description":"Person successfully reconfirmed as trusted in ESIA"}
Пример ответа на запрос (запрос на регистрацию успешно отправлен, создана заявка на регистрацию):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"requestId":"AAAAF3A1379F965664CB56FCE55BD8CCA2F38368985607E75E23", "code":"2",
"description":"Request to register person as trusted in ESIA has been accepted
successfully."}
Пример ответа на запрос (найдена упрощенная учетная запись, создана заявка на подтверждение):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"requestId":"AAAAF3A1379F965664CB56FCE55BD8CCA2F38368985607E75E23", "code":"3",
"description":"Request to conform simplified person as trusted in ESIA has been accepted
successfully."}
Пример ответа на запрос (ошибка импорта, некоторые атрибуты запроса не совпадают с учетной записью в ЕСИА - требуется корректировка параметров запроса или учетной записи в ЕСИА):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"ESIA-03200", "description":"Import account error. Person have to check entered
data or fill in the data in his account in ESIA."}
В таблице ниже представлены коды ответов от сервиса импорта.
Таблица 12 - Коды и описание ошибок от сервиса импорта
Система, используя имеющийся идентификатор заявки на регистрацию пользователя, может узнать статус заявки, а также причину ошибки (при ее наличии). Для получения данных о ходе выполнения проверок система должна выполнить запрос методом GET в https-адрес REST-API системы ЕСИА <58>. Запрос также должен содержать маркер доступа системы на скоуп ext_imp. Пример запроса:
--------------------------------
<58> В среде разработки сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/reqs/{requestId}, где requestId - уникальный идентификатор заявки на проверку данных пользователя.
GET https://esia-portal1.test.gosuslugi.ru/rs/reqs/
AAAA5F79379F965664CB739F5BDC6FD8E24797A576A4F056322D
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6M
В качестве ответа ЕСИА возвращает json с параметрами, указанными в Таблице 13.
на запрос о статусе проверки
данных пользователя
Пример ответа на запрос о статусе выполнения заявки (успешная регистрация учетной записи при импорте в ЕСИА):
{"stateFacts":["Identifiable"],"status":"SUCCEEDED","personOid":1000352622}
Пример ответа на запрос о статусе выполнения заявки (регистрация учетной записи при импорте в ЕСИА не выполнена - ошибка при проверке ФИО, СНИЛС и даты рождения в ПФР России):
"stateFacts":["Identifiable"],
"status": "VALIDATION_FAILED",
"flowDetails":
[
{
"name":"raRegistrationEndorsement",
"status":"S"
},
{
"name": "validateSnils",
"status": "F",
"error":{"code": "ESIA-910001",
"message": "Пенсионный фонд Российской Федерации не подтвердил существование
СНИЛС с указанными реквизитами"}
},
{
"name": "sendSMS",
"status": "C"
}
],
"errorStatusInfo":
{
"code": "ESIA-910001",
"message": "Пенсионный фонд Российской Федерации не подтвердил существование СНИЛС с
указанными реквизитами"
}
}
Пример ответа на запрос о статусе выполнения заявки (регистрация учетной записи при импорте в ЕСИА выполнена с ошибкой - ошибка при проверке паспортных данных в МВД России):
"stateFacts":["Identifiable"],
"status": "VALIDATION_FAILED",
"flowDetails":
[
{
"name": "validateRfPassport",
"status": "F",
"error":{"code": "ESIA-910100",
"message": "В автоматическом режиме не удалось произвести проверку
вашего паспорта."}
}
],
"errorStatusInfo":
{
"code": "ESIA-910100",
"message": "В автоматическом режиме не удалось произвести проверку вашего
паспорта."
}
}
В таблице 14 представлены коды ответов на запрос о статусе выполнения заявки.
Б.9.2 Модернизированный сервис импорта учетных записей пользователя из внешних информационных систем
Обновленный алгоритм, по которому производится импорт учетной записи, отображен на Рисунок 14, представленный в разделе Б.9 Импорт учетной записи пользователя.
Данный алгоритм включается настройкой на стороне ЕСИА для конкретных ИС по решению Минкомсвязи России, согласованному с ЦБ РФ. ИС, для которых данный механизм включен, обязаны предупреждать пользователя о возможном сбросе пароля и замене телефона. Рекомендуемый текст:
"Если мы найдем учетную запись на Госуслугах и номер телефона в ней не совпадет с выбранным, мы обновим номер и пришлем на него СМС с новым паролем для входа."
Обновленный механизм проверки паспортных данных в импорте представлен также на Рисунок 14.
В таблице ниже представлены новые коды ответов от сервиса импорта.
ошибок от сервиса импорта
ESIA-039604 | Паспортные данные на проверке. Повторите попытку позже (обычно это занимает час, в редких случаях до трех дней). | Запущена проверка паспорта на Госуслугах Проверка займет менее часа, в редких случаях до 3 дней. Повторите попытку позже. | |
ESIA-039605 | Обновите паспортные данные в банке и продолжите регистрацию. | Паспортные данные в банке неактуальны Учетная запись на Госуслугах содержит более новые паспортные данные. Обновите паспортные данные в офисе банка и повторите попытку на следующий день. | |
ESIA-039606 | Паспортные данные отправлены на проверку. Повторите попытку позже (обычно это занимает час, в редких случаях до трех дней). | Заявка уже обрабатывается Идет проверка паспорта на Госуслугах. Она занимает до 3 дней. Повторите попытку позже. | |
ESIA-039607 | Обнаружена УЗ, для которой не удалось сопоставить указанные в ИС данные | Паспортные данные из банка не найдены в МВД Обратитесь в ближайший офис банка: мы проверим и при необходимости обновим данные паспорта (ФИО, серия, номер) в вашем профиле. | |
ESIA-039608 | По данным МВД паспорт из ИС числится как не актуальный | Паспортные данные неактуальны Если вы меняли паспорт - обратитесь в ближайший офис банка: мы обновим сведения в профиле. Если ваши данные верны - воспользуйтесь онлайн-сервисом МВД <*>, или обратитесь в ближайшее отделение МВД, чтобы сообщить о проблеме. |
--------------------------------
<*> Рекомендуется ссылка на инструкцию:
Для того, чтобы воспользоваться онлайн-сервисом МВД России, необходимо:
1) перейти по ссылке http://сервисы.гувм.мвд.рф/info-service.htm?sid=2000;
2) заполнить серию и номер паспорта, а также код с картинки и нажать кнопку "Отправить запрос";
3) убедиться, что Ваш паспорт числится в базе недействительным;
4) нажать кнопку "Сообщить об ошибке";
5) в поле "Описание ошибки" сообщить о проблеме.
При проверке паспортных данных сервисом МВД получена ошибка. Паспорт (указать - серию паспорта, номер паспорта, дату выдачи и код подразделения) на имя (указать - Фамилия Имя Отчество), дата рождения (указать дату рождения) признан недействительным (причина). Прошу провести корректировку в базе.
6) заполнить адрес электронной почты, ФИО и нажать кнопку "Отправить";
7) ответ придет на указанную электронную почту в течение 30 дней.
Б.10 Сервис подтверждения операций по регистрации УЗ через интеграционный модуль ЕПГУ
Для регистрации учетной записи необходимо выполнить отправку запроса метода POST: https://esia.gosuslugi.ru/esia-rs/api/public/v2/prns/import/REST_API/0 (для продуктивной среды).
Входные параметры запроса описаны в приложении Б.9 Импорт учетной записи пользователя.
Пример запроса (вызов сервиса в среде разработки):
POST https://esia.gosuslugi.ru/esia-rs/api/public/v2/prns/import/REST_API/0 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IkdPU1QzNDEwIn0.eyJzY29wZSI6Imh0dHA
6XC9cL2VzaWEuZ29zdXNsdWdpLnJ1XC9leHRfaW1wIiwiaXNzIjoiaHR0cDpcL1wvZXNpYS5nb3N1c2x1Z2kucnVcLy
IsInVybjplc2lhOnNpZCI6IjQwYjBmNzhhLWY0ZmItNDhiYS1iNjFhLTI3M2NmOTNiZDdmYiIsInVybjplc2lhOnNia
l9pZCI6MTAwMDAwMDAwMiwiZXhwIjoxNTU5OTgzNzUyLCJpYXQiOjE1NTk4OTczNTIsImNsaWVudF9pZCI6IlRFU1Rf
U1lTIn0.V4RffDdsEEQDhBaZ4VJ-tT9dmdWgC5qOU-ZxlVtf0dSQsSBILwOFpQI18s-
nMStgDGlnnUSR4sgtX4RMW5TITQ
Cache-Control: no-cache
Content-Length: 1476
Host: esia-portal1.test.gosulsugi.ru
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
{
"snils": "000-000-000 01",
"contacts": {
"elements": [
{
"type": "MBT",
"value": "+7(900)0000000"
}
]
},
"firstName": "Иванов",
"lastName": "Иван",
"middleName": "Иванович",
"gender": "M",
"trusted": "true",
"birthDate": "01.01.1990",
"birthPlace": "Воронеж",
"citizenship": "RUS",
"documents": {
"elements": [
{
"issueDate": "18.03.2016",
"issueId": "725453",
"issuedBy": "РУВД г.Москвы",
"number": "111111",
"series": "1000",
"type": "RF_PASSPORT"
}
]
}
}
В запрос должен быть добавлен header (Authorization: Bearer) с ранее полученным маркером доступа, выданный на специальный scope (http://esia.gosuslugi.ru/ext_imp), позволяющий осуществлять автоматический импорт учетной записи пользователя. Данный маркер выдается только доверенным системам, имеющим право импорта пользователей таким образом; выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента, т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА.
Также запрос должен быть подписан электронной подписью системы, которая импортирует учетную запись в ЕСИА (Request-Data-Sign), и содержать тело запроса, закодированное в формате URL-Safe Base64 (Request-Data).
По персональным данным, указанным в запросе, выполняется поиск Учетной записи в ЕСИА. В зависимости от того, найдена в ЕСИА учетная запись, удовлетворяющая полученным данным, или нет, операция импорта может завершиться одним из следующих результатов:
Пример ответа на запрос (пользователь уже зарегистрирован в ЕСИА, учетная запись уже подтверждена ранее):
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"0", "description":"Person already has trusted account in ESIA"}
Пример ответа на запрос (запрос на регистрацию успешно отправлен, создана заявка на регистрацию):
X-Powered-By: Servlet/3.0 JSP/2.2
{
"requestId": "AAAA1D6E3E9F965664CB2F7F7C2CDEE19DCD83922B5E71CFB8B3",
"code": "2",
"description": "Request to register person as trusted in ESIA has been accepted
successfully."
}
В ответе передаются следующие параметры:
requestId | Код заявки на регистрацию | Возвращается в случае создания заявки на регистрацию. | |
code | Код завершения операции | Может быть возвращен в виде значений: - 0 или 1 - выполнена регистрация учетной записи; - 2 - создана заявка на регистрацию учетной записи; - код ошибки, варианты приведены в Таблице 12. | |
description | Текстовое описание кода завершения операции | Описание для кодов успешного импорта учетной записи в ЕСИА (code = 0, 1 или 2) и для code = ESIA-03200 | |
message | Текстовое описание кода ошибки выполнения операции | Варианты ошибок приведены в Таблице 12 |
В случае создания заявки на регистрацию, пользователю на номер мобильного телефона, указанного в запросе, будет отправлен СМС-код подтверждения. Полученный код необходимо отправить в ЕСИА. Для этого требуется выполнить отправку запроса метода POST: https://esia.gosuslugi.ru/esia-rs/api/public/v2/confirmation/compare (для продуктивной среды).
В запросе на подтверждение кода (из СМС) передаются следующие данные:
requestId | Код заявки на регистрацию | Возвращается в случае создания заявки на регистрацию. | |
Code | Код подтверждения, отправленный пользователю на номер мобильного телефона. | Направляется пользователю, в случае создания заявки на регистрацию. |
Пример запроса (вызов сервиса в среде разработки):
"requestId": "AAAA8DC2359F965664CB21FEFBDD922BA0BD8DAAEE6727EB980A",
"code": "2783"
}
По полученным данным в ЕСИА выполняется проверка кода подтверждения. В ответе передаются следующие параметры:
requestId | Код заявки на регистрацию | |
createdTime | Время создания запроса | |
mobile | Номер мобильного | |
status | Статус выполнения операции | |
confirmationWay | Признака подтверждения | |
availableAttemptsCount | Оставшееся количество попыток ввода кода подтверждения. | |
maxInputAttemptsCount | Максимальное количество ввода подтверждения. | |
periodsForNextGeneration | Интервал времени между переотправкой СМС. | |
resendCount | Количество попыток по переотправке СМС с кодом подтверждения. | |
timeToLive | Срок жизни кода подтверждения. |
Пример ответа в случае если код подтверждения указан правильно:
"requestId":"AAAA0EF8369F965664CB48D753590B7269A3CF453DD0554E4DBA",
"createdTime":1557766520905,
"mobile":"79000000000",
"status":"OK",
"confirmationWay":"REST_API",
"availableAttemptsCount":5,
"maxInputAttemptsCount":5,
"periodsForNextGeneration":[
60000,
60000,
60000
],
"resendCount":1,
"timeToLive":86400000
}
В таблице ниже перечислены возможные статусы (поле: status) выполнения операции:
OK | Код подтверждения указан верно | |
WAIT | Код подтверждения указан не верно | |
NOT_FOUND | Информация о данном коде подтверждения не найдена | |
TOO_FAST_RESEND | Невозможно выполнить переотправку СМС с кодом подтверждением. С момента отправки последнего СМС прошло слишком мало времени (Параметр: periodsForNextGeneration) | |
RESEND_LIMIT_IS_REACHED | Повторная переотправка СМС невозможна (Параметр: resendCount) | |
EXPIRED | Истек срок жизни кода подтверждения (Параметр: timeToLive) |
Для возможности переотправки кода подтверждения пользователю, требуется выполнить отправку запроса метода POST: https://esia.gosuslugi.ru/esia-rs/api/public/v2/confirmation/resend/requestId (для продуктивной среды). В запросе необходимо указывать код заявки на регистрацию (Параметр: requestId).
Б.11 Управление изображением (аватаром) в профиле пользователя
Программные интерфейсы на основе REST обеспечивают возможность управления изображением (аватаром) пользователя. Обеспечена возможность:
- получать изображение (аватар) пользователя по OID;
- получать исходное изображение (аватар) пользователя по OID.
Для осуществления данных операций система организации должна направить в https-адрес программного интерфейса ЕСИА запрос методом GET.
Б.11.1 Получение сжатого изображения (аватара) пользователя по OID
Для получения сжатого круглого изображения (аватара) должен быть выполнен запрос методом GET на https-адрес программного интерфейса ЕСИА <59>. Заголовок данного запроса должен включать в себя маркер доступа, выданный системе для работы с аватаром пользователя (usr_avt?oid={p.prn_oid}). Выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента (Приложение В.3), т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА. При авторизации необходимо указать в заголовке - Authorization с полученным токеном.
--------------------------------
<59> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/esia-rs/api/public/v1/pso/{prn_oid}/avt/circle
В качестве ответа ЕСИА возвращает маленькое круглое изображение, использующееся на странице авторизации и в профиле ЕСИА, или ошибку при отсутствии изображения.
GET http://esia-portal1.test.gosuslugi.ru/esia-rs/api/public/v1/pso/1000299282/avt/circle
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE1MjgyMDg1MzE
sInNjb3BlIjoib3BlbmlkIHVzcl9hdnQ_b2lkPTEwMDAyOTkyODIiLCJpc3MiOiJodHRwOlwvXC9lc2lhLmdvc3VzbH
VnaS5ydVwvIiwidXJuOmVzaWE6c2lkIjoiMDI4Zjk0NWI5MjEwN2ZiMjc5MTE4YTM1OGM2M2ZiNDRhMzdjOGZiOTAyM
jA1OGQxZjlhMjdiNjIzMDg5ZjQ3YSIsInVybjplc2lhOnNial9pZCI6MTAwMDI5OTI4MiwiZXhwIjoxNTI4MjEyMTMx
LCJpYXQiOjE1MjgyMDg1MzEsImNsaWVudF9pZCI6IlRFU1RfU1lTIn0.Lqv8Zm9J8sGEHJmGppY_zWXGn_KaQcWeERx
k53C-BkXAVxsMboEXwVcnmva5hRuSuo_wcVwf3rY_DQ_9OHgd3vZ3o-iEFciDJxVVAMz2sV9HQXvUz0HfT-
VAMIwfsWUMurKeV7uCPYgr1rjaqsRivzIgMc0eo0jlZMrM2ohUJTWVKZZqzT-
IxCBjyVoUwcPafBmkAmy0vtlRVj1LjgBZg5BNeXvUCv819cc4S0e9q1-e6AEjZIHTNyEVo1nq_la8iem-
UVVPRmjszyffrlJSzSkDvds3809wYbfzk8ckA2b-95acNDtsN8esDdGbBg6c-xMpfmyNpALSlc1uPkmkg
"url": "/0/0/0/0/0/113/33/424e0939-3055-4945-b510-0650ea2c97aa.png"
}
Полученное изображение располагается по ссылке:
https://esia-portal1.test.gosuslugi.ru/useravatar/{ссылка_на_изображение}, например:
https://esia-portal1.test.gosuslugi.ru/useravatar/0/0/0/0/0/113/33/424e0939-3055-4945-b510-0650ea2c97aa.png
Пример ответа в случае, если аватар не найден:
"code": "ESIA-040404",
"message": "ValidationCommonErrorEnum.avatar.notfound"
}
Б.11.2 Получение исходного изображения (аватара) пользователя по OID
Для получения исходного квадратного изображения (аватара) должен быть выполнен запрос методом GET на https-адрес программного интерфейса ЕСИА <60>. Заголовок данного запроса должен включать в себя маркер доступа, выданный системе для работы с аватаром пользователя (usr_avt?oid={p.prn_oid}). Выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента (Приложение В.3), т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА. При авторизации необходимо указать в заголовке - Authorization с полученным токеном.
--------------------------------
<60> Сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/esia-rs/api/public/v1/pso/{prn_oid}/avt/square
В качестве ответа ЕСИА возвращает квадратное исходное изображение пользователя или ошибку при отсутствии изображения.
GET http://esia-portal1.test.gosuslugi.ru/esia-rs/api/public/v1/pso/1000299282/avt/square
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE1MjgyMDg1MzE
sInNjb3BlIjoib3BlbmlkIHVzcl9hdnQ_b2lkPTEwMDAyOTkyODIiLCJpc3MiOiJodHRwOlwvXC9lc2lhLmdvc3VzbH
VnaS5ydVwvIiwidXJuOmVzaWE6c2lkIjoiMDI4Zjk0NWI5MjEwN2ZiMjc5MTE4YTM1OGM2M2ZiNDRhMzdjOGZiOTAyM
jA1OGQxZjlhMjdiNjIzMDg5ZjQ3YSIsInVybjplc2lhOnNial9pZCI6MTAwMDI5OTI4MiwiZXhwIjoxNTI4MjEyMTMx
LCJpYXQiOjE1MjgyMDg1MzEsImNsaWVudF9pZCI6IlRFU1RfU1lTIn0.Lqv8Zm9J8sGEHJmGppY_zWXGn_KaQcWeERx
k53C-BkXAVxsMboEXwVcnmva5hRuSuo_wcVwf3rY_DQ_9OHgd3vZ3o-iEFciDJxVVAMz2sV9HQXvUz0HfT-
VAMIwfsWUMurKeV7uCPYgr1rjaqsRivzIgMc0eo0jlZMrM2ohUJTWVKZZqzT-
IxCBjyVoUwcPafBmkAmy0vtlRVj1LjgBZg5BNeXvUCv819cc4S0e9q1-e6AEjZIHTNyEVo1nq_la8iem-
UVVPRmjszyffrlJSzSkDvds3809wYbfzk8ckA2b-95acNDtsN8esDdGbBg6c-xMpfmyNpALSlc1uPkmkg
"url": "/0/0/0/0/0/113/33/424e0939-3055-4945-b510-0650ea2c97aa.png"
}
Полученное изображение располагается по ссылке:
https://esia-portal1.test.gosuslugi.ru/useravatar/{ссылка_на_изображение}, например:
https://esia-portal1.test.gosuslugi.ru/useravatar/0/0/0/0/0/113/33/424e0939-3055-4945-b510-0650ea2c97aa.png
Пример ответа в случае, если исходный аватар не найден:
"code": "ESIA-040404",
"message": "ValidationCommonErrorEnum.avatar.notfound"
}
Б.12 Сервис управления внешними ИС центрами обслуживания организаций
Б.12.1 Сервис REST API управления ЦО
Методы для работы с ЦО организации:
1. Создание центра обслуживания.
2. Изменение данных центра обслуживания.
3. Удаление центра обслуживания.
URL: esia-rs/api/public/v1/orgs/{org_oid}/rcs
На вход сервис должен получать объект, описывающий центр обслуживания, который необходимо добавить к организации.
org_oid - идентификатор организации, в которой добавляется ЦО;
address - структурированный адрес места расположения ЦО в составе:
type - тип адреса - для ЦО всегда равен "RA";
addressStr - адрес, строковое представление - адрес без указания номера дома, корпуса, строения и квартиры;
countryId - 3-символьный код страны по справочнику ОКСМ;
fiasCode - ФИАС код (уровень 7...9) адреса места расположения ЦО;
region - название субъекта РФ согласно справочнику ССРФ;
district - внутригородской район;
settlement - населенный пункт;
additionArea - дополнительная территория;
additionAreaStreet - название улицы на дополнительной территории;
lng - долгота (геокоордината).
contact - контактная информация ЦО - номер(а) телефона(ов) и/или адрес(а) электронной почты;
features - возможности ЦО, перечисление "rcr", "reg", "del", "cfm", "rbi";
pdos - разрешения на отображение операций, перечисление "rcr", "reg", "del", "cfm", "rbi";
information - дополнительная информация;
opnModes - режим работы ЦО, перечисление: "WEEKENDS", "EARLY", "LATE";
1. WEEKENDS - работает по выходным;
2. EARLY - открыто с 8:00 утра;
3. LATE - Закрывается позже 19:00 вечера.
4. WEEKENDS, EARLY - работает по выходным (открыто с 8:00 утра);
5. WEEKENDS, LATE - работает по выходным, закрывается позже 19:00 вечера;
6. EARLY, LATE - работает с 8:00 утра и закрывается позже 19:00 вечера;
7. WEEKENDS, EARLY, LATE - работает по выходным (работает с 8:00 утра и закрывается позже 19:00 вечера).
operationTime - время работы ЦО;
Тело запроса: application/json;charset=UTF-8
POST esia-rs/api/public/v1/orgs/1000000001/rcs HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDYyMTU2ND
Content-Type: application/json
Cache-Control: no-cache
{
"name" : "Клиентский центр в ОПС 143960",
"operationTime" : "пн. 11.00 - 20.00, вт. - пт. 09.00 - 20.00, сб. 09.00
- 18.00, вс. - вых.",
"information" : "Необходим паспорт и номер СНИЛС",
"features" : [ "rcr", "reg", "del" ],
"address" : {
"type" : "RA",
"addressStr" : "Кемеровская Область, Таштагольский Район, Шерегеш
Поселок городского типа",
"countryId" : "RUS",
"zipCode" : "123104",
"region" : "Кемеровская Область",
"area" : "Регион Садовое неком-е товарищество",
"city" : "Шерегеш Поселок городского типа",
"district" : "нет",
"settlement" : "Усть-Анзас Поселок",
"street" : "Советская Улица",
"additionAreaStreet": "ект",
"house" : "86/1",
"building" : "е",
"frame" : "204у",
"flat" : "пом.419",
"fiasCode" : "2604e353-b9dd-4542-a8bf-020c8f982797",
"lat": 55.757911,
"lng": 37.600681
},
"contact" : {
"type" : "RAC",
"value" : "8-800-550-07-70"
},
"opnModes" : [ "LATE", "WEEKENDS", "EARLY" ],
"raTypeId" : 8
}
"oid": "1000000234", // идентификатор созданного ЦО
"message": "Success|Fail"
}
"code": "ESIA-038000",
"message": "организация не найдена"
}
Перечень возможных возвращаемых ошибок:
org_ra?org_oid={p.org_oid}&mode=w
Изменение данных центра обслуживания
URL: esia-rs/api/public/v1/orgs/{org_oid}/rcs/{ra_oid}
На вход сервис должен получать объект, описывающий центр обслуживания, данные которого необходимо изменить.
org_oid - идентификатор организации,
address - структурированный адрес места расположения ЦО в составе:
type - тип адреса - для ЦО всегда равен "RA";
addressStr - адрес, строковое представление - адрес без указания номера дома, корпуса, строения и квартиры;
countryId - 3-символьный код страны по справочнику ОКСМ;
fiasCode - код ФИАС (уровень 7...9) адреса места расположения ЦО
region - название субъекта РФ согласно справочнику ССРФ;
district - внутригородской район;
settlement - населенный пункт;
additionArea - дополнительная территория;
additionAreaStreet - название улицы на дополнительной территории;
lng - долгота (геокоордината).
contact - контактная информация ЦО - номер(а) телефона(ов) и/или адрес(а) электронной почты;
features - услуги ЦО, перечисление "rcr", "reg", "del", "cfm", "rbi";
pdos - разрешения на отображение операций, перечисление "rcr", "reg", "del", "cfm", "rbi";
information - дополнительная информация;
opnModes - режим работы ЦО, перечисление "WEEKENDS", "EARLY", "LATE";
operationTime - время работы ЦО;
PUT esia-rs/api/public/v1/orgs/1000000001/rcs/1000000234 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDYyMTU2ND
Content-Type: application/json
Cache-Control: no-cache
{
"name" : "Клиентский центр в ОПС 143960",
"operationTime" : "пн. 11.00 - 20.00, вт. - пт. 09.00 - 20.00, сб. 09.00
- 18.00, вс. - вых.",
"information" : "Необходим паспорт и номер СНИЛС",
"features" : [ "rcr", "reg", "del" ],
"address" : {
"type" : "RA",
"addressStr" : "Кемеровская Область, Таштагольский Район, Шерегеш
Поселок городского типа",
"countryId" : "RUS",
"zipCode" : "123104",
"region" : "Кемеровская Область",
"area" : "Регион Садовое неком-е товарищество",
"city" : "Шерегеш Поселок городского типа",
"district" : "нет",
"settlement" : "Усть-Анзас Поселок",
"street" : "Советская Улица",
"additionAreaStreet" : "ект",
"house" : "86/1",
"building" : "ё",
"frame" : "204у",
"flat" : "пом.419",
"fiasCode" : "2604e353-b9dd-4542-a8bf-020c8f982797",
"lat": 55.757911,
"lng": 37.600681
},
"contact" : {
"type" : "RAC",
"value" : "8-800-550-07-70"
},
"opnModes" : [ "LATE", "WEEKENDS", "EARLY" ],
"raTypeId" : 8
}
"oid": "1000000234", // идентификатор измененного ЦО
"message": "Success|Fail" //Fail в случае какой-то непредвиденной ошибки
}
"code": "ESIA-038000",
"message": "организация не найдена"
}
Перечень возможных возвращаемых ошибок:
org_ra?org_oid={p.org_oid}&mode=w
URL: esia-rs/api/public/v1/orgs/{org_oid}/rcs/{ra_oid}
На вход сервис должен получать объект, описывающий центр обслуживания, который необходимо удалить из организации.
org_oid - идентификатор организации, из которой нужно удалить ЦО;
DELETE esia-rs/api/public/v1/orgs/1000000001/rcs/1000000234 HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDY
yMTU2ND
Content-Type: application/json
Cache-Control: no-cache
"oid": "1000000234", // идентификатор удаленного ЦО
"message": "Success|Fail" // Fail в случае какой-то непредвиденной ошибки
}
"code": "ESIA-038000",
"message": "организация не найдена"
}
Перечень возможных возвращаемых ошибок:
org_ra?org_oid={p.org_oid}&mode=w
Б.12.2 Сервис REST API безусловного добавления сотрудников в организацию
Возможно присоединение к организации только подтвержденных УЗ сотрудников.
Осуществляется поиск присоединяемого сотрудника по СНИЛС (из перечня в теле запроса) с последующей проверкой на совпадение ФИО (из тела запроса и найденной УЗ).
URL: esia-rs/api/public/v1/orgs/{org_oid}/invts/force
На вход сервис должен получать коллекцию объектов, описывающих УЗ пользователей, которых необходимо добавить в организацию без отправки приглашения на e-mail.
org_oid - идентификатор организации, в которую нужно добавлять УЗ пользователей;
По умолчанию, максимальное количество пользователей в одном запросе 100.
POST esia-rs/api/public/v1/orgs/1000000001/invts/force HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDY
yMTU2ND
Content-Type: application/json
Cache-Control: no-cache
[
{
"snils": "000-000-000 01",
"firstName": "Михаил",
"lastName": "Иванов",
"middleName": "Иванович"
},
{
"snils": "000-000-000 01",
"firstName": "Петр",
"lastName": "Петров",
"middleName": "Петрович"
},
{
"snils": "000-000-0 01",
"firstName": "Вадим",
"lastName": "Вадимов",
"middleName": "Вадимович"
},
{
"snils": "000-000-000 99",
"firstName": "Николай",
"lastName": "Николаев",
"middleName": "Николаевич"
}
]
Данные в ответе с результатом будут отсортированы в том же порядке, как и при запросе.
"message": "Success|Partial success|Fail",
"results": [
{ "snils":"000-000-000 01", "message": "Success"},
{ "snils":"000-000-000 02", "message": "Success"},
{ "snils":"000-000-0 01", "message": "ESIA-036101"},
// ... ответ будет отсортирован в том же порядке, как и при запросе
{ "snils":"000-000-000 99", "message": "Success"}
]
}
Перечень возможных возвращаемых ошибок:
Неверная контрольная сумма СНИЛС | |
Пользователь, учетная запись которого найдена по указанному в запросе СНИЛС, не является сотрудником организации, org_oid которой указан в запросе |
org_invts_force?org_oid={p.org_oid}&mode=w
Б.12.3 Сервис REST API получения списка ЦО организации
Методы для работы с ЦО организации:
Просмотр перечня ЦО организации с параметрами
rs/api/public/v1/orgs/{org_oid}/rcs?embed=(elements.address,elements.contact)&wpdo
=true
Список должен выводиться постранично.
org_oid - идентификатор организации
pageIndex - номер текущей страницы списка
wpdo - параметр, добавляющий в ответ значение pdos - разрешения на отображение операций;
rs/api/public/v1/orgs/1000000001/rcs?embed=(elements.address,elements.contact)&pag
eSize=3&wpdo HTTP/1.1
Content-Type: application/json
Authorization: Bearer
eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0
Content-Type: application/json
Cache-Control: no-cache
"stateFacts": [
"FirstPage",
"Paginated"
],
"pageSize": 3,
"pageIndex": 1,
"totalSize": 5,
"elements": [
{
"stateFacts": [
"Identifiable"
],
"oid": 1000327280,
"name": "Москва город, Тверской бульвар 20",
"active": true,
"blocked": false,
"operationTime": "10:00 - 20:00",
"information": "{}",
"features": [
"del"
],
"address": {
"stateFacts": [
"Identifiable"
],
"id": 18442,
"type": "RA",
"addressStr": "Москва город, Тверской бульвар",
"fiasCode": "0c5b2444-70a0-4932-980c-b4dc0d3f02b5",
"countryId": "RUS",
"house": "20",
"zipCode": "125009",
"building": "1",
"street": "Тверской Бульвар",
"lat": 55.761045,
"lng": 37.602344,
"region": "Москва Город",
"fiasCode2": "0c5b2444-70a0-4932-980c-b4dc0d3f02b5",
"eTag": "10AA54C325DE25D0FAB7FDE1250DEB843148D007"
},
"contact": {
"stateFacts": [
"Identifiable"
],
"id": 14244862,
"type": "RAC",
"vrfStu": "false",
"value": "899999999",
"eTag": "67EE505F77FDEB8DD8E7E82558CC34C61651FA62"
},
"pdos": [
"del"
],
"eTag": "03227235143A38A08D9969348FB7AACEDBACB9C9"
},
{
"stateFacts": [
"Identifiable"
],
"oid": 1000327281,
"name": "Москва город, Тверской бульвар 27 с6",
"active": true,
"blocked": false,
"operationTime": "8:00 - 18:00",
"information": "{}",
"features": [
"rcr"
],
"address": {
"stateFacts": [
"Identifiable"
],
"id": 18443,
"type": "RA",
"addressStr": "Москва город, Тверской бульвар",
"fiasCode": "0c5b2444-70a0-4932-980c-b4dc0d3f02b5",
"countryId": "RUS",
"house": "27",
"zipCode": "123104",
"building": "6",
"street": "Тверской Бульвар",
"lat": 55.763404,
"lng": 37.60273,
"region": "Москва Город",
"fiasCode2": "2604e353-b9dd-4542-a8bf-020c8f982797",
"eTag": "3EBD14C4F4682AEF8A57655E56696C7DCB464CDD"
},
"contact": {
"stateFacts": [
"Identifiable"
],
"id": 14244861,
"type": "RAC",
"vrfStu": "false",
"value": "894565655",
"eTag": "616657BADBCBB1E3750AA1B12DE3B2D35D80F2DE"
},
"pdos": [
"rcr"
],
"eTag": "596525D1667B9AD2EDCA1A5714E359EA266ED0B2"
},
{
"stateFacts": [
"Identifiable"
],
"oid": 1000327282,
"name": "Леонтьевский Переулок 2/26",
"active": true,
"blocked": false,
"operationTime": "8:00 - 20:00",
"information": "{}",
"features": [
"cfm"
],
"address": {
"stateFacts": [
"Identifiable"
],
"id": 18444,
"type": "RA",
"addressStr": "Москва город, Леонтьевский переулок",
"fiasCode": "0c5b2444-70a0-4932-980c-b4dc0d3f02b5",
"countryId": "RUS",
"house": "2/26",
"zipCode": "125009",
"building": "2",
"street": "Леонтьевский Переулок",
"lat": 55.757911,
"lng": 37.600681,
"region": "Москва Город",
"fiasCode2": "6d703385-d883-488f-9c39-fca4cc82abb8",
"eTag": "1955CFFD980B039E0842E0163E977F248662963C"
},
"contact": {
"stateFacts": [
"Identifiable"
],
"id": 14244860,
"type": "RAC",
"vrfStu": "false",
"value": "8965461556",
"eTag": "E4D0DFDA96194E9DE0F34C3428F4B9070A51F2F5"
},
"pdos": [
"cfm"
],
"eTag": "7B701FD975C5466BDA0F92E3C2BEF0C5D5FDB178"
}
]
}
Перечень возможных возвращаемых ошибок:
URL: esia-rs/api/public/v1/orgs/{org_oid}/rcs/find
Список должен выводиться постранично.
org_oid - идентификатор организации
pageIndex - номер текущей страницы списка (по умолчанию принимается как = 1)
pageSize - количество элементов (ЦО) списка на странице (по умолчанию принимается как = 100)
embed - необязательный параметр, но для того, чтобы получить в ответе данные о найденном ЦО, необходимо, чтобы он был = (elements.address,elements.contact)
wpdo - параметр, добавляющий в ответ значение pdos - разрешения на отображение операций;
features - услуги ЦО, перечисление "rcr", "reg", "del", "cfm", "rbi";
opnModes - режим работы ЦО, перечисление "WEEKENDS", "EARLY", "LATE";
1. WEEKENDS - работает по выходным;
2. EARLY - открыто с 8:00 утра;
3. LATE - Закрывается позже 19:00 вечера;
4. WEEKENDS, EARLY - работает по выходным (открыто с 8:00 утра);
5. WEEKENDS, LATE - работает по выходным, закрывается позже 19:00 вечера;
6. EARLY, LATE - работает с 8:00 утра и закрывается позже 19:00 вечера;
7. WEEKENDS, EARLY, LATE - работает по выходным (работает с 8:00 утра и закрывается позже 19:00 вечера).
name - название ЦО, возможно указание неполного названия (поиск по совпадению части имени).
rs/api/public/v1/orgs/1000000001/rcs/find?embed=(elements.address,elements.contact
)&wpdo=true HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGci0iJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAi0jE0NDY
yMTU2ND
Content-Type: application/json
Cache-Control: no-cache
{
"features": ["del"],
"opnModes": ["LATE", "WEEKENDS"],
"name": "Тверской бульвар 20"
}
"stateFacts": [
"FirstPage",
"Paginated",
"LastPage"
],
"size": 1,
"pageSize": 100,
"pageIndex": 1,
"elements": [
{
"stateFacts": [
"Identifiable"
],
"oid": 1000327280,
"name": "Москва город, Тверской бульвар 20",
"active": true,
"blocked": false,
"operationTime": "10:00 - 20:00",
"information": "{}",
"features": [
"del"
],
"address": {
"stateFacts": [
"Identifiable"
],
"id": 18442,
"type": "RA",
"addressStr": "Москва город, Тверской бульвар",
"fiasCode": "0c5b2444-70a0-4932-980c-b4dc0d3f02b5",
"countryId": "RUS",
"house": "20",
"zipCode": "125009",
"building": "1",
"street": "Тверской Бульвар",
"lat": 55.761045,
"lng": 37.602344,
"region": "Москва Город",
"fiasCode2": "2604e353-b9dd-4542-a8bf-020c8f982797",
"eTag": "10AA54C325DE25D0FAB7FDE1250DEB843148D007"
},
"contact": {
"stateFacts": [
"Identifiable"
],
"id": 14244862,
"type": "RAC",
"vrfStu": "false",
"value": "899999999",
"eTag": "67EE505F77FDEB8DD8E7E82558CC34C61651FA62"
},
"pdos": [
"del"
],
"opnModes": [
"LATE",
"WEEKENDS",
"EARLY"
],
"eTag": "A52ABED7388EB183F11E3DF9B8535234964AD9B8"
}
]
}
Перечень возможных возвращаемых ошибок:
Б.12.4 Сервис REST API прикрепления сотрудников к ЦО
Возможно присоединение к ЦО только подтвержденных УЗ сотрудников организации.
Поиск УЗ осуществляется по СНИЛС только в подтвержденных УЗ.
URL: esia-rs/api/public/v1/orgs/{org_oid}/rcs/{rc_oid}/invts/force
На вход сервис должен получать коллекцию объектов, описывающих УЗ пользователей, которых необходимо прикрепить к ЦО.
По умолчанию, максимальное количество пользователей в одном запросе 100.
org_oid - идентификатор организации, к ЦО которой прикрепляется пользователь;
rc_oid - идентификатор ЦО, к которому нужно прикрепить УЗ пользователя;
POST esia-rs/api/public/v1/orgs/1000000001/rcs/1000000234/invts/force HTTP/1.1
Host: esia-portal1.test.gosuslugi.ru
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0eyJleHAiOjE0NDY
yMTU2ND
Content-Type: application/json
Cache-Control: no-cache
[
{
"snils": "000-000-000 01",
"firstName": "Михаил",
"lastName": "Иванов",
"middleName": "Иванович"
},
{
"snils": "000-000-000 01",
"firstName": "Петр",
"lastName": "Петров",
"middleName": "Петрович"
},
{
"snils": "000-000-0 01",
"firstName": "Вадим",
"lastName": "Вадимов",
"middleName": "Вадимович"
},
{
"snils": "000-000-000 99",
"firstName": "Николай",
"lastName": "Николаев",
"middleName": "Николаевич"
}
]
Ответ с результатом будет отсортирован в том же порядке, как и при запросе.
"oid ": "1000000234", // идентификатор ЦО в который добавлялись
пользователи
"message": "Success|Partial success|Fail",
"results": [
{ "snils":"000-000-000 01", "message": "Success"},
{ "snils":"000-000-000 02", "message": "Success"},
{ "snils":"000-000-0 01", "message": "ESIA-036101"},
// ... ответ будет отсортирован в том же порядке, как и при запросе
{ "snils":"000-000-000 99", "message": "Success"}
]
}
Перечень возможных возвращаемых ошибок:
Пользователь, учетная запись которого найдена по указанному в запросе СНИЛС, не является сотрудником организации, org_oid которой указан в запросе |
org_invts_force?org_oid={p.org_oid}&mode=w
Б.13 Сервис получения маркера доступа по идентификационному ключу
Для получения внешней ИС или приложением маркера доступа к API услуг ЕПГУ в обмен на выданный идентификационный ключ (api-key) используется метод REST API ЕСИА GET /orgs/ext-app/{UUID}/tkn.
- идентификационный ключ - уникальный идентификатор формата UUID, сформированный соответствующим сервисом ЕСИА в привязке на сотрудника организации и ИС информационной системы вендора, зарегистрированной в ЕСИА;
- маркер доступа - маркер доступа, формируемый OAuth2.0 ЕСИА (описание структуры - согласно подразделу "В.5 Сведения о структуре и проверке маркера доступа" настоящего документа) и выдаваемый на скоупы (scope), необходимые и достаточные для доступа к API услуг ЕПГУ (перечень требуемых скоупов указывается службой эксплутации ЕСИА в соответствующей конфигурационной настройке ЕСИА).
- URL запроса метода: https://<базовый адрес среды ЕСИА>/api/public/v1/orgs/ext-app/{UUID}/tkn
- - UUID - идентификационный ключ (указывается как in-url);
- - signature - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 - подписанный параметр UUID сертификатом организации, на сотрудника которой был выдан (сформирован) идентификационный ключ;
- выходные параметры метода - JSON с параметром "accessTkn" - маркер доступа к API услуг ЕПГУ.
GET /esia-rs/api/public/v1/orgs/ext-app/73535141-e8ae-4abb-ae03-
e5d7cd3fbef1/tkn?signature=MIIKeQYJKoZIhvcNAQcCoIIKajCCCmYCAQExDjAMBggqhQMHAQECAgUAMDMGCSqGSIb3
DQEHAaAmBCQ3MzUzNTE0MS1lOGFlLTRhYmItYWUwMy1lNWQ3Y2QzZmJlZjGgggftMIIH6TCCB5agAwIBAgIQYD6SAA2r3oZ
OyLA4syCgLjAKBggqhQMHAQEDAjCCAT8xGDAWBgUqhQNkARINMTAyNzcwMDE5ODc2NzEaMBgGCCqFAwOBAwEBEgwwMDc3MD
cwNDkzODgxCzAJBgNVBAYTAlJVMSkwJwYDVQQIDCA3OCDQodCw0L3QutGCLdCf0LXRgtC10YDQsdGD0YDQszEmMCQGA1UEB
wwd0KHQsNC90LrRgi3Qn9C10YLQtdGA0LHRg9GA0LMxWDBWBgNVBAkMTzE5MTAwMiwg0LMuINCh0LDQvdC60YIt0J%2FQtd
GC0LXRgNCx0YPRgNCzLCDRg9C7LiDQlNC%2B0YHRgtC%2B0LXQstGB0LrQvtCz0L4g0LQuMTUxJjAkBgNVBAoMHdCf0JDQn
iAi0KDQvtGB0YLQtdC70LXQutC%2B0LwiMSUwIwYDVQQDDBzQotC10YHRgtC%2B0LLRi9C5INCj0KYg0KDQotCaMB4XDTE5
MTEyMjA4NDIyOFoXDTIwMTEyMjA4NTIyOFowggGHMTQwMgYJKoZIhvcNAQkBFiV0ZXN0QHRlc3QudGVzdDxtYWlsdG86dGV
zdEB0ZXN0LnRlc3Q%2BMRowGAYIKoUDA4EDAQESDDAwNzcyODEzMTU4NzEWMBQGBSqFA2QDEgs3NjYyNDU2NjAzMzEYMBYG
BSqFA2QBEg0xMTE3Nzk5MDA0MzMzMSEwHwYDVQQMDBjQoNGD0LrQvtCy0L7QtNC40YLQtdC70YwxIDAeBgNVBAoMF9Ce0JD
QniA80KDQvtGB0L3QsNC90L4%2BMRUwEwYDVQQJDAzQnNC%2B0YHQutCy0LAxFTATBgNVBAcMDNCc0L7RgdC60LLQsDEcMB
oGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDELMAkGA1UEBhMCUlUxKjAoBgNVBCoMIdCi0LDRgtGM0Y%2FQvdCwINCQ0L3
QtNGA0LXQtdCy0L3QsDEVMBMGA1UEBAwM0KDQvtCz0L7QstCwMSAwHgYDVQQDDBfQntCQ0J4gPNCg0L7RgdC90LDQvdC%2B
PjBmMB8GCCqFAwcBAQEBMBMGByqFAwICJAAGCCqFAwcBAQICA0MABEA7R9s0yPHwRXySk0v0qFZ6NMrPsgIPBzhAIP1ujjZ
upVYpI3UaCGOa6uiy7Scj6DJgiiKI2sHmA7SEFSOvgstqo4IEGTCCBBUwDgYDVR0PAQH%2FBAQDAgTwMB0GA1UdDgQWBBQi
FrhcRjqGP7obev%2FofLFuK85JnzAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwUwYIKwYBBQUHAQEERzBFMEMGC
CsGAQUFBzAChjdodHRwOi8vY2VydGVucm9sbC50ZXN0Lmdvc3VzbHVnaS5ydS9jZHAvdGVzdF9jYV9ydGsuY2VyMB0GA1Ud
IAQWMBQwCAYGKoUDZHEBMAgGBiqFA2RxAjArBgNVHRAEJDAigA8yMDE5MTEyMjA4NDIyN1qBDzIwMjAxMTIyMDg0MjI3WjC
CARAGBSqFA2RwBIIBBTCCAQEMGtCa0YDQuNC%2F0YLQvtCf0YDQviBDU1AgNC4wDB3QmtGA0LjQv9GC0L7Qn9GA0L4g0KPQ
piB2LjIuMAxh0KHQtdGA0YLQuNGE0LjQutCw0YLRiyDRgdC%2B0L7RgtCy0LXRgtGB0YLQstC40Y8g0KTQodCRINCg0L7Rg
dGB0LjQuCDQodCkLzEyNC0zMzgwINC%2B0YIgMTEuMDUuMjAxOAxh0KHQtdGA0YLQuNGE0LjQutCw0YLRiyDRgdC%2B0L7R
gtCy0LXRgtGB0YLQstC40Y8g0KTQodCRINCg0L7RgdGB0LjQuCDQodCkLzEyOC0yOTgzINC%2B0YIgMTguMTEuMjAxNjAlB
gUqhQNkbwQcDBrQmtGA0LjQv9GC0L7Qn9GA0L4gQ1NQIDQuMDBlBgNVHR8EXjBcMFqgWKBWhlRodHRwOi8vY2VydGVucm9s
bC50ZXN0Lmdvc3VzbHVnaS5ydS9jZHAvNDgxMGFmMGY1ZGRjOTkyNDc2ZjdiZjBkZGE0YjdkMGRkOTRjZTFmNy5jcmwwggG
ABgNVHSMEggF3MIIBc4AUSBCvD13cmSR2978N2kt9DdlM4fehggFHpIIBQzCCAT8xGDAWBgUqhQNkARINMTAyNzcwMDE5OD
c2NzEaMBgGCCqFAwOBAwEBEgwwMDc3MDcwNDkzODgxCzAJBgNVBAYTAlJVMSkwJwYDVQQIDCA3OCDQodCw0L3QutGCLdCf0
LXRgtC10YDQsdGD0YDQszEmMCQGA1UEBwwd0KHQsNC90LrRgi3Qn9C10YLQtdGA0LHRg9GA0LMxWDBWBgNVBAkMTzE5MTAw
Miwg0LMuINCh0LDQvdC60YIt0J%2FQtdGC0LXRgNCx0YPRgNCzLCDRg9C7LiDQlNC%2B0YHRgtC%2B0LXQstGB0LrQvtCz0
L4g0LQuMTUxJjAkBgNVBAoMHdCf0JDQniAi0KDQvtGB0YLQtdC70LXQutC%2B0LwiMSUwIwYDVQQDDBzQotC10YHRgtC%2B
0LLRi9C5INCj0KYg0KDQotCaghByCwFWUAAQs%2BgRpGhL66%2F7MAoGCCqFAwcBAQMCA0EAVTneiC0PfzpcScCjesYiqPF
%2FBHrdR2KxZVF8rsbKuEfAzUyA5RZH%2F%2BHnOCaZ618ggut77IFu26wif0RffraxazGCAikwggIlAgEBMIIBVTCCAT8x
GDAWBgUqhQNkARINMTAyNzcwMDE5ODc2NzEaMBgGCCqFAwOBAwEBEgwwMDc3MDcwNDkzODgxCzAJBgNVBAYTAlJVMSkwJwY
DVQQIDCA3OCDQodCw0L3QutGCLdCf0LXRgtC10YDQsdGD0YDQszEmMCQGA1UEBwwd0KHQsNC90LrRgi3Qn9C10YLQtdGA0L
HRg9GA0LMxWDBWBgNVBAkMTzE5MTAwMiwg0LMuINCh0LDQvdC60YIt0J%2FQtdGC0LXRgNCx0YPRgNCzLCDRg9C7LiDQlNC
%2B0YHRgtC%2B0LXQstGB0LrQvtCz0L4g0LQuMTUxJjAkBgNVBAoMHdCf0JDQniAi0KDQvtGB0YLQtdC70LXQutC%2B0Lwi
MSUwIwYDVQQDDBzQotC10YHRgtC%2B0LLRi9C5INCj0KYg0KDQotCaAhBgPpIADavehk7IsDizIKAuMAwGCCqFAwcBAQICB
QCgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MTQxMzE5MjRaMC8GCSqGSIb3DQEJ
BDEiBCCHyDksc05aocKt9TfPMAkfINvAAcuRqCqJvS1MVUU1hTAMBggqhQMHAQEBAQUABEBYnLGLx04Y2ot7pxFrGBNEyrO
9XFiUyTLesheld8BHUEzm8VTTW7kuSFMRGmZjz%2B%2FVe86VakA1sY3BSiMe3sHS
Пример ответа на запрос метода:
HTTP/1.1 200 OK
{
"accessTkn":
"eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJzY29wZSI6Imh0dHA6XC9cL2
VzaWEuZ29zdXNsdWdpLnJ1XC9vcmdfZnVsP29yZ19vaWQ9MTA3NzEwMTI2NSBodHRwOlwvXC9lc2lhLmdvc3VzbHVnaS5yd
Vwvb3JnX2luZj9vcmdfb2lkPTEwNzcxMDEyNjUiLCJpc3MiOiJodHRwOlwvXC9lc2lhLmdvc3VzbHVnaS5ydVwvIiwidXJu
OmVzaWE6c2lkIjoiNDQ1N2FmNjktZmRhNS00Y2MyLTllYzMtNTE3NzhkYjEyMTA3IiwidXJuOmVzaWE6c2JqX2lkIjoxMDc
3MTE4Mzk2LCJleHAiOjE1OTQ3NDc2NDEsImlhdCI6MTU5NDczNjg0MSwiY2xpZW50X2lkIjoiMTIzNDU2NyJ9.kFQk89VpX
0A3qA6BZu7qqUJf5KnLtmeKaVvt8sn2v73peuIVnYpWL2kmAIKpZAE0vtrvcDSagEBVgXoExdtAkNCAUiGA41HJCJHBbn-
3fFDS3FNHB-9PaC3XclFx8Z04GPX5yt2CnBS_IsTcdvZxOOPuBz4IJYrsMi9R9cFad8Seff0h9OBPt-
kauTpe8gkHvmCVpLkNf5slEeK4rxCMUnBhXSA5RbWbC4yudO9rkhWcPQc-3WwMHrvkVZFRj9YlUe6sf-
fMf3QHn_pk2jcxZFaaMx-EEMPxOoJHy0sOOKzvIElpcWbwkgPCAg4fb5olMg6PUKhE3GThTXbZsJBFng"
}
Перечень возможных возвращаемых ошибок:
ЕСИА, ОСНОВАННЫЕ НА ПРОТОКОЛЕ OAUTH 2.0 И OPENID
CONNECT 1.0
OAuth 2.0 определяет протокол взаимодействия следующих сторон:
- владелец ресурса (resource owner) - сущность, которая может предоставить доступ к защищаемому ресурсу (например, конечный пользователь);
- система-клиент (client) - приложение, которое запрашивает доступ к защищаемому ресурсу от имени владельца ресурса;
- сервис авторизации (authorization server) - сервис, который выпускает для клиента маркеры доступа с разрешения владельца ресурса;
- поставщик ресурса (resource server) - сервис, на котором размещены защищаемые ресурсы и который может принимать запросы на доступ к защищаемым ресурсам и отвечать на эти запросы.
Модель контроля доступа, реализуемая сервисом авторизации ЕСИА, основана на использовании маркера доступа (security access token). Этот маркер несет информацию о подмножестве полномочий системы-клиента, о самой системе-клиенте, а также ряд служебных параметров. С точки зрения системы-клиента маркер доступа представляет собой набор символов. Системе-клиенту для получения доступа к защищенным ресурсам (т.е. делать успешные вызовы программного интерфейса), как правило, не требуется расшифровывать маркер доступа, достаточно лишь получать по определенным правилам и корректно использовать. В то же время в ЕСИА предусмотрены и "подписанные" маркеры доступа, которые можно проверить без обращения к ЕСИА.
В ЕСИА используются два способа получения маркера доступа:
1. Система-клиент получает маркер доступа в результате делегированного принятия решения сервисом авторизации на основании согласия владельца ресурса. В этом случае сервис авторизации выдает маркер доступа, если явным образом получает разрешение со стороны владельца ресурса. Например, система-клиент обратилась к сервису авторизации за маркером, позволяющим получить контактные данные пользователя. В этом случае сервис авторизации запрашивает у пользователя, согласен ли он предоставить данные системе-клиенту, и при позитивном решении выдает маркер доступа.
2. Система-клиент получает маркер доступа в результате решения сервиса авторизации на основании наличия у системы-клиента соответствующих полномочий. В этом случае система-клиент не должна получать явного разрешения от владельца ресурса - это разрешение было дано заранее, на стадии регистрации системы-клиента в сервисе авторизации. Такая модель контроля доступа реализуется, например, при взаимодействии информационных систем, если одна система желает получить идентификационные сведения о другой системе, для чего ей необходимо получить соответствующий маркер доступа.
Аутентификация пользователя, реализуемая с помощью модели OAuth 2.0 и расширения OpenID Connect, основана на использовании маркера идентификации (ID token). Этот маркер несет информацию об идентификационных данных пользователя, а также ряд служебных параметров.
В.2 Модель контроля на основе делегированного принятия решения
Данная модель контроля доступа используется в случаях, когда система-клиент при доступе к ресурсу должна получить разрешение на это действие со стороны владельца ресурса.
В общем виде схема взаимодействия выглядит следующим образом:
- система-клиент запрашивает у владельца ресурса разрешение на доступ к соответствующим ресурсам. Обычно этот запрос осуществляется не напрямую к владельцу ресурса, а опосредованно через сервис авторизации (который, в свою очередь, запрашивает разрешение у владельца ресурса), поскольку сам владелец ресурса не может выдать ни маркер доступа, ни авторизационный код;
- система-клиент получает разрешение на доступ (authorization grant) в виде авторизационного кода;
- система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;
- сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;
- система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;
- поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;
- система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;
- поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;
- система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;
- сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.
Схема взаимодействия представлена на рисунке 15.
После того, как система-клиент получила маркер доступа, она может неоднократно обращаться за получением соответствующего защищенного ресурса, пока не истечет срок действия этого маркера. Когда это произойдет, системе-клиенту потребуется получить новый маркер доступа.
Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).
Рисунок 15 - Общая схема взаимодействия при получении
маркера доступа с помощью авторизационного кода
Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя последний полученный ранее маркер обновления. Сервис авторизации проверяет валидность маркера обновления (что он является актуальным, не был отозван и что срок его действия не истек) и выдает новый маркер доступа и маркер обновления.
Особенности маркера обновления:
- имеет более длительный срок действия, чем у маркера доступа. Срок действия маркера обновления различен для каждой информационной системы и настраивается Администратором ИС в Технологическом портале ЕСИА;
- предъявляется исключительно при необходимости получить новый маркер доступа (таким образом, минимизируется риск перехвата);
- выдается сервисом авторизации одновременно с маркером доступа;
- может быть отозван владельцем ресурса.
Таким образом, наличие маркера обновления позволяет системе-клиенту получать новый маркер доступа даже тогда, когда пользователь (владелец ресурса) недоступен, при условии, что владелец ресурса явным образом не запретил доступ.
В.2.2 Получение авторизационного кода
Чтобы получить авторизационный код, система-клиент должна получить разрешение на доступ к защищенному ресурсу со стороны его владельца. В случае, когда владельцем является пользователь ЕСИА, система-клиент должна направить пользователя на страницу предоставления прав доступа в ЕСИА <61> (пользователь должен быть предварительно аутентифицирован в ЕСИА или система ЕСИА попросит его пройти идентификацию и аутентификацию).
--------------------------------
<61> Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac
Эта ссылка должна содержать следующие обязательные параметры:
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012;
- <redirect_uri> - ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на доступ к ресурсу;
- <scope> - область доступа, т.е. запрашиваемые права; например, если система-клиент запрашивает доступ к сведениям о сотрудниках организации, то scope должна иметь значение http://esia.gosuslugi.ru/org_emps (с необходимыми параметрами); если запрашивается scope id_doc <62> (данные о пользователе), то не нужно в качестве параметра указывать oid этого пользователя;
--------------------------------
<62> Либо один или несколько scope, обеспечивающих доступ к персональным данным пользователя.
- <response_type> - это тип ответа, который ожидается от ЕСИА, имеет значение code, если система-клиент должна получить авторизационный код;
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID;
- <timestamp> - время запроса авторизационного кода в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором (<state>);
- <access_type> - принимает значение "offline", если требуется иметь доступ к ресурсам и тогда, когда владелец не может быть вызван (в этом случае выпускается маркер обновления); значение "online" - доступ требуется только при наличии владельца.
Если в ходе авторизации не возникло ошибок, то ЕСИА осуществляет редирект пользователя по ссылке, указанной в redirect_uri, а также возвращает два обязательных параметра:
- <code> - значение авторизационного кода;
- <state> - значение параметра state, который был получен в запросе на авторизацию; система-клиент должна провести сравнение отправленного и полученного параметра state.
В случае ошибки сервис авторизации вернет в параметре error код ошибки (например, "access_denied") и перенаправит пользователя по адресу, указанному в redirect_uri. Перечень возможных ошибок приведен в таблице 16.
Таблица 16 - Список ошибок при получении маркеров доступа
В.2.3 Получение маркера доступа в обмен на авторизационный код
Когда авторизационный код получен, система-клиент может сформировать запрос методом POST на https-адрес ЕСИА для получения маркера доступа <63>. Один авторизационный код можно обменять на один маркер доступа. В тело запроса должны быть включены следующие сведения:
--------------------------------
<63> Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <code> - значение авторизационного кода, который был ранее получен от ЕСИА и который необходимо обменять на маркер доступа;
- <grant_type> - принимает значение "authorization_code", если авторизационный код обменивается на маркер доступа;
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012;
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID; этот набор символов должен отличаться от того, который использовался при получении авторизационного кода;
- <redirect_uri> - ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на доступ (то же самое значение, которое было указано в запросе на получение авторизационного кода);
- <scope> - область доступа, т.е. запрашиваемые права (то же самое значение, которое было указано в запросе на получение авторизационного кода);
- <timestamp> - время запроса маркера в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором (<state>);
- <token_type> - тип запрашиваемого маркера, в настоящее время ЕСИА поддерживает только значение "Bearer".
Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:
- <access_token> - маркер доступа для данного ресурса;
- <expires_in> - время, в течение которого истекает срок действия маркера (в секундах);
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса, генерируется по стандарту UUID (совпадает с идентификатором запроса);
- <token_type> - тип предоставленного маркера, в настоящее время ЕСИА поддерживает только значение "Bearer";
- <refresh_token> - маркер обновления для данного ресурса.
"access_token" :
"eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.eyJleHAiOjEzNTk1NDAxODcsInNjb3BlIj
oiaHR0cDpcL1wvZXNpYS5nb3N1c2x1Z2kucnVcL2VtcF9pbmY_b3JnX29pZD0xMDAwMDAwMzU3IiwiaXNzIjoiaHR0cDpcL1wvZXNpY
S5nb3N1c2x1Z2kucnUiLCJuYmYiOjEzNTk1MzY1ODcsInVybjplc2lhOnNpZCI6IjE2ZDdmOTNkLTZjZTgtNDE3OS04ZmFmLTdmZDQ2
ZDMyMDhhNiIsInVybjplc2lhOnNial9pZCI6MTAwMDAwMDM4NSwiY2xpZW50X2lkIjoiRVNJQSIsImlhdCI6MTM1OTUzNjU4N30",
"expires_in" : 3600,
"state" : "9be638a9-0e05-42e1-b4f8-a3e30457fbdd",
"token_type" : "Bearer",
"refresh_token" : "54039d1f-9917-43cd-961a-2729c891ef8c"
}
При невозможности выдачи маркера доступа возвращается код ошибки (Таблица 16).
В.2.4 Получение нового маркера доступа в обмен на маркер обновления
При использовании маркера доступа системам-клиентам рекомендуется сначала проверять, не истек ли срок его действия. Если маркер просрочен, то для успешного доступа к защищенному ресурсу потребуется предварительно получить новый маркер доступа с использованием маркера обновления. Для этого системе-клиенту следует сформировать запрос методом POST в адрес ЕСИА, имеющий структуру, аналогичную первичному запросу на получение маркера. Особенности значений параметров запроса:
- <refresh_token> - значение имеющегося у системы-клиента маркера обновления, который следует обменять на новый маркер доступа (указывается вместо <code>);
- <grant_type> - должно иметь значение "refresh_token", поскольку маркер обновления обменивается на маркер доступа.
Ответ на этот дается в формате JSON и имеет ту же структуру, как и при первичном предоставлении маркера доступа. В этом ответе содержится новый маркер обновления, который система-клиент должна хранить вместо уже использованного маркера обновления.
Перечень возможных ошибок приведен в Таблице 17.
Таблица 17 - Список ошибок при получении маркера
доступа в обмен на маркер обновления
expired_token | ESIA-007027: Срок действия маркера обновления истек | |
access_denied | ESIA-0070278: Маркер обновления скомпрометирован и отозван |
В.3 Модель контроля доступа на основе полномочий системы-клиента
Эта модель контроля предполагает, что система-клиент самостоятельно обращается к сервису авторизации и получает маркер доступа (client-side flow) на основании имеющихся (и зафиксированных в сервисе авторизации) полномочий системы-клиента. Данная модель контроля доступа предполагает, что система-клиент при доступе к защищенному ресурсу непосредственно получает разрешение (в форме маркера доступа) со стороны сервиса авторизации. В общем виде схема взаимодействия выглядит следующим образом:
- система-клиент обращается к сервису авторизации за выдачей маркера доступа, позволяющего получить доступ к защищенному ресурсу;
- сервис авторизации аутентифицирует систему-клиента и выдает маркер доступа;
- система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;
- поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу.
Данная модель контроля доступа проиллюстрирована на рисунке.
Рисунок 16 - Схема взаимодействия при реализации модели
контроля доступа на основе полномочий системы-клиента
Поскольку получение маркера доступа при использовании данной модели контроля не предполагает обращения к владельцу ресурса, то маркер обновления не применяется. Система-клиент после истечения срока действия маркера доступа может обратиться к сервису авторизации и получить новый маркер доступа.
В.3.2 Получение маркера доступа
Для получения маркера доступа система-клиент должна направить по https-адресу сервиса авторизации (ЕСИА) запрос методом POST. Запрос должен содержать следующие сведения:
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <response_type> - используемая модель контроля доступа; принимает значение "token", если происходит безусловное наделение системы-клиента полномочиями;
- <grant_type> - принимает значение "client_credentials", если используется модель контроля доступа на основе полномочий системы-клиента. В данной модели невозможно указывать пользовательские scope, необходимо указывать только scope организаций.
- <scope> - область доступа, т.е. запрашиваемые права; например, если система-клиент запрашивает доступ к данным ИНН организации, то scope должно иметь значение http://esia.gosuslugi.ru/org_inn с параметрами.
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID; этот набор символов должен отличаться от того, который использовался при получении авторизационного кода.
- <timestamp> - время запроса маркера в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором (<state>);
- <token_type> - тип запрашиваемого маркера, в настоящее время ЕСИА поддерживает только значение "Bearer";
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для формирования подписи сертификат должен быть зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012.
Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:
- <access_token> - маркер доступа для данного ресурса;
- <expires_in> - время, в течение которого истекает срок действия маркера (в секундах);
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса, генерируется по стандарту UUID (совпадает с идентификатором запроса);
- <token_type> - тип предоставленного маркера, в настоящее время ЕСИА поддерживает только значение "Bearer".
При невозможности выдачи маркера доступа возвращается код ошибки (Таблица 16).
В.4 Особенности указания области доступа (scope)
При запросе на получение маркера доступа система-клиент должна обязательно указывать соответствующий scope, т.е. область доступа (тип данных, к которым система-клиент намерена получить доступ).
В ЕСИА используются следующие типы scope:
1. Данные о пользователе. В системе предусмотрены следующие scope, позволяющие получить данные о пользователе (Таблица 18).
Таблица 18 - Предоставляемые ЕСИА наборы данных
о пользователе
Таблица 19 - Предоставляемые ЕСИА наборы данных
о детях пользователя
- имя; - отчество. | |||
- номер свидетельства; - дата выдачи свидетельства; - кем выдано свидетельство. | |||
Просмотр данных полиса обязательного медицинского страхования (ОМС) | - действителен до ОМС. |
Все указанные в таблице scope также позволяют получить данные о признаке подтвержденности учетной записи пользователя (атрибут <trusted> персональных данных физического лица).
Эти scope указываются в формате /scope?param1=value1¶m2=value2, где <param1> - название, а value1 - значение параметра. Может использоваться параметр:
- <oid> - внутренний идентификатор пользователя в ЕСИА (обязательный параметр).
При запросе у сервиса авторизации ЕСИА маркера доступа на scope id_doc или любого другого scope на получение данных о пользователе не нужно в качестве параметра указывать oid этого пользователя.
Принять решение о предоставлении данных о пользователе (т.е. о выдаче соответствующего маркера) может исключительно сам пользователь.
Scope "id_doc" и "foreign_passport_doc" позволяют получить Гражданство пользователя.
Для получения информации об организациях, в которые включен пользователь (скоуп usr_org), система должна выполнить запрос методом GET в https-адрес REST-API системы ЕСИА: https://esia.gosuslugi.ru/rs/prns/{prn_oid}/roles. Запрос также должен содержать маркер доступа системы, выданный на скоуп usr_org:
GET https://esia.gosuslugi.ru/rs/prns/{prn_oid}/roles
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6M
Информация возвращается в развернутом виде, т.е. к данному REST-API уже применен механизм встраивания (embedding) связанных данных:
- <oid> - идентификатор организации;
- <fullName> - полное наименование организации;
- <shortName> - краткое наименование организации;
- <type> - тип организации ("BUSINESS" - ИП, "LEGAL" - ЮЛ, "AGENCY" - ОГВ);
- <branchName> - наименование филиала;
- <branchOid> - уникальный идентификатор филиала;
- <chief> - сведения о том, является ли сотрудник руководителем организации (в этом случае имеет значение "true") или нет ("false");
- <admin> - проверка наличия сотрудника в группе доступа "Администраторы профиля организации", мнемоника группы: ORG_ADMIN ("true" - сотрудник имеет доступ или "false" - сотрудник не имеет доступа);
- <email> - служебная электронная почта сотрудника;
- <phone> - служебный номер телефона сотрудника;
- <active> - признак блокировки сотрудника ("true" - сотрудник не заблокирован или "false" - сотрудник заблокирован).
"stateFacts": [
"hasSize"
],
"size": 5,
"elements": [
{"oid": 107712993, "prnOid": 1000366587, "fullName": "Индивидуальный Предприниматель Юки Асуна Юи", "shortName": "ИП Юки А. Ю.",...},
{
"oid": 1000364913,
"prnOid": 1000366587,
"fullName": "Центр Госуслуг Района Раменки",
"shortName": "Центр госуслуг Района Раменки",
"ogrn": "1023601587965",
"type": "AGENCY",
"chief": true,
"admin": true,
"active": true,
"hasRightOfSubstitution": true,
"hasApprovalTabAccess": true,
"isLiquidated": false
},
{"oid": 1077121212, "prnOid": 1000366587, "fullName": "Организация -1758361669", "shortName": "ОРГАНИЗАЦИЯ -1758361669",...},
{"oid": 1000322321, "prnOid": 1000366587, "fullName": "Пао \"Ростелеком\"", "shortName": "ПАО \"Ростелеком\"",...},
{"oid": 1000000001, "prnOid": 1000366587, "fullName": "Организация -783988581", "shortName": "ОРГАНИЗАЦИЯ -783988581",...}
]
}
2. Данные об организации. В системе предусмотрены следующие scope, позволяющие получить данные об организации (Таблица 20).
Таблица 20 - Предоставляемые ЕСИА наборы данных
об организации
Эти scope указываются в формате /scope?param1=value1¶m2=value2, где <param1> - название, а value1 - значение параметра. Должен использоваться параметр:
- <org_oid> - внутренний идентификатор организации в ЕСИА.
scope="http://esia.gosuslugi.ru/org_emps?org_oid=1000000357"
Наличие маркера с таким scope позволяет получить информацию о сотрудниках.
3. Данные для идентификации и аутентификации пользователя (openid). Этот scope используется в целях проведения аутентификации пользователя и получения маркера идентификации (см. Приложение В.6 и В.7). Он не параметризуется, т.к. до аутентификации у системы-клиента отсутствует информация об идентификаторе пользователя.
Также для усиленной биометрической аутентификации дополнительно используется scope "bio" совместно со scope "openid". Подробно о процессе удаленной биометрической аутентификации указано в Приложении В.8.
4. Комплексные данные о пользователе (ext_auth_result), доступные в результате усиленной биометрической аутентификации (см. Приложение В.8). По данному scope доступен следующий набор личных данных пользователя:
- реквизиты документа, удостоверяющего личность;
5. Технологическая информация (http://esia.gosuslugi.ru/tech_inf), в том числе - о перечне удаленных пользователей. Для получения данных об удаленных пользователях этот scope должен иметь вид: http://esia.gosuslugi.ru/tech_inf?stu=DELETED. Получение маркера доступа на этот scope должно происходить посредством модели контроля доступа на основе полномочий системы-клиента (см. Приложение В.3).
6. Доступ к сервису ЕПГУ для ИС ГОСБАР (gosbar/gosbar_org). Для получения данных о пользователе, сторонний ресурс (на котором размещена поисково-навигационная система "Госбар") при вызове Gosbar.init должен получать пользовательский access token, со scope gosbar (для пользователей ЕСИА - физических лиц) или gosbar_org?org_oid (для пользователей ЕСИА - юридических лиц).
7. Перечень scope для предоставления доступа к API ЕПГУ:
- http://sf.gosuslugi.ru/europrotocol - оформление извещения о ДТП в форме электронного документа. Этот scope позволяет создавать, редактировать, просматривать, подписывать и регистрировать извещение о ДТП в форме электронного документа;
- https://lk.gosuslugi.ru/api-order - подача заявлений с использованием программного интерфейса портала госуслуг;
- https://lk.gosuslugi.ru/api-geps - получение писем (госпочта) с использованием программного интерфеса портала госуслуг.
В.5 Сведения о структуре и проверке маркера доступа
Используемый ЕСИА маркер состоит из трех частей:
1. Заголовок (header), в котором содержится общая информация о типе маркера, в том числе об использованных в ходе его формирования криптографических операциях.
2. Набор утверждений (payload/claim set) с содержательными сведениями о маркере.
3. Подпись (signature), которая удостоверяет, что маркер "выдан" ЕСИА и не был изменен при передаче.
Части маркера разделены точкой, так что он имеет вид:
Маркер передается в виде строки в формате Base64url <64>.
--------------------------------
<64> Подробнее см. в: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02#appendix-B
Каждая часть маркера содержит набор утверждений (claims) трех типов:
Заголовок (header) содержит описание свойств используемого маркера:
1. Алгоритм шифрования ("alg", стандартное обозначение); в настоящее время в ЕСИА поддерживается алгоритм электронной подписи ГОСТ Р 34.10-2012 (соответствует значению "GOST3410_2012_512"). <65>
--------------------------------
<65> Подробнее см. РП Технологического портала ЕСИА, п. 3.1.1 и п. 3.1.2: http://digital.gov.ru/ru/documents/6190/
2. Глобальный тип маркера ("typ", стандартное обозначение), который в ЕСИА всегда имеет значение "JWT" (JSON Web Token);
3. ЕСИА - специфический тип маркера и его версия ("sbt" и "ver" соответственно, приватное обозначение), что необходимо для использования в ЕСИА нескольких типов маркера; для маркера доступа - "access".
Например, заголовок маркера доступа в ЕСИА будет иметь следующий вид:
{"alg":"GOST3410_2012_512","typ":"JWT","ver":0,"sbt":"access"}
Сообщение (payload) включает в себя содержательные утверждения о субъекте. В случае, если система проводит аутентификацию пользователя с использованием механизма SAML, системе нет необходимости разбираться в формате payload маркера доступа. Однако если система проводит аутентификацию пользователя с использованием REST, ей необходимо извлечь необходимую информацию из сообщения маркера (payload) и проверить подпись ЕСИА.
Сообщение включает в себя содержательные утверждения о маркере доступа и субъекте:
- время прекращения действия ("exp") - в секундах с 1 января 1970 г. 00:00:00 GMT;
- время начала действия ("nbf") - в секундах с 1 января 1970 г. 00:00:00 GMT, т.е. маркер нельзя обрабатывать до наступления указанного времени;
- время выдачи ("iat") - в секундах с 1 января 1970 г. 00:00:00 GMT;
- организация, выпустившая маркер ("iss"), для маркеров ЕСИА всегда имеет определенное значение, которое совпадает с полем "субъект" используемого сертификата ЕСИА (http://субъект);
- адресат маркера ("client_id") - утверждение, ограничивающее системы/приложения ("аудитория"), которые могут использовать этот маркер. Для обозначения адресата в ЕСИА используется мнемоника данной ИС, зарегистрированной в ЕСИА. Соответственно, использовать маркер могут только системы с этой мнемоникой.
- идентификатор маркера ("urn:esia:sid") - набор случайных символов, имеющий вид 128-битного идентификатора, сгенерированного по стандарту UUID.
- идентификатор субъекта ("urn:esia:sbj_id"), в качестве значения указывается oid, этот идентификатор уникален для каждого субъекта, зарегистрированного в ЕСИА;
- область доступа ("scope"), в качестве значения - название области, к которой предоставляется доступ (например, "id_doc").
3. Данные о наличии делегирования полномочий ("urn: esia:authority"):
- дата истечения срока действия доверенности ("expired");
- идентификатор доверенности в ЕСИА ("id").
Пример сообщения (payload) маркера доступа в ЕСИА:
"nbf": 1537889904,
"urn:esia:authority": {
"expired": "16.09.2018",
"id": "1020"
},
"scope": "http://esia.gosuslugi.ru/usr_sec?mode=w&oid=1000299526
http://esia.gosuslugi.ru/usr_inf?mode=w&oid=1000299526 openid
http://esia.gosuslugi.ru/org_inf?org_oid=1000000001",
"iss": "http://esia.gosuslugi.ru/",
"urn:esia:sid": "dfa8dfe4e2cbad40fcfc974a9bcd445b570c2c90c22612047a940c56afa2c463",
"urn:esia:sbj_id": 1000299526,
"exp": 1537893504,
"iat": 1537889904,
"client_id": "PROFILE"
}
Подпись (signature) маркера осуществляется по тому алгоритму, который указывается в параметре "alg" маркера. Подпись вычисляется от двух предыдущих частей маркера (HEADER.PAYLOAD).
Системе-клиенту, использующей механизмы REST и OAuth 2.0 для аутентификации пользователей, рекомендуется осуществлять проверку маркера доступа, используя данные о его подписи. В общем виде эта процедура включает в себя следующие шаги <66>:
--------------------------------
<66> Подробнее см.: http://tools.ietf.org/pdf/draft-jones-json-web-token-10.pdf, http://tools.ietf.org/pdf/draft-ietf-jose-json-web-signature-02.pdf, http://tools.ietf.org/pdf/draft-ietf-jose-json-web-encryption-02.pdf
1. Осуществление base64url-декодирования первых двух частей маркера. В header указан алгоритм шифрования (параметр alg).
2. Третья часть маркера доступа представляет собой подпись в кодировке UTF-8 от значений первых двух частей маркера доступа (HEADER.PAYLOAD). Необходимо осуществить проверку данной электронной подписи с использованием сертификата ключа проверки электронной подписи ЕСИА.
3. Проверка времени выдачи, начала и прекращения маркера.
4. Проверка организации, выпустившей маркер, а также адресата маркера.
В.6 Использование OpenID Connect 1.0 для аутентификации пользователя
В общем виде схема аутентификация с использованием OpenID Connect 1.0 выглядит следующим образом:
- система-клиент готовит запрос на аутентификацию пользователя с необходимыми параметрами;
- система-клиент отправляет запрос на аутентификацию в адрес сервиса авторизации ЕСИА;
- сервис авторизации аутентифицирует пользователя;
- сервис авторизации получает согласие пользователя на проведение аутентификации в данной системе;
- сервис авторизации перенаправляет пользователя обратно в систему-клиент и передает авторизационный код;
- система-клиент формирует запрос с использованием авторизационного кода на получения маркера идентификации;
- система-клиент получает ответ, содержащий необходимый маркер идентификации;
- система-клиент проводит валидацию маркера идентификации и извлекает из маркера идентификатор пользователя.
Далее более детально рассмотрены формируемые системой-клиентом запросы и получаемые ей ответы от ЕСИА.
В.6.2 Получение авторизационного кода
В.6.2.1 Стандартный режим запроса авторизационного кода
Чтобы получить авторизационный код, система-клиент должна получить разрешение на проведение аутентификации пользователя <67>. Для этого система-клиент должна направить пользователя на страницу предоставления прав доступа в ЕСИА.
--------------------------------
<67> Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac
Эта ссылка должна содержать следующие обязательные параметры:
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений следующих параметров HTTP-запроса: scope, timestamp, client_id, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012.
- <redirect_uri> - ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на проведение аутентификации;
- <scope> - область доступа, т.е. запрашиваемые права; для проведения аутентификации пользователя scope должен иметь значение openid. Если системе потребуется получение дополнительных данных о пользователе (например, детальная информация о пользователе), то могут быть указаны дополнительные scope через пробел;
- <response_type> - это тип ответа, который ожидается от ЕСИА, имеет значение code, поскольку система-клиент должна получить авторизационный код;
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID;
- <timestamp> - время запроса авторизационного кода в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором (<state>).
Если в ходе аутентификации не возникло ошибок, то ЕСИА осуществляет редирект пользователя по ссылке, указанной в redirect_uri, а также возвращает два обязательных параметра:
- <code> - значение авторизационного кода;
- <state> - значение параметра state, который был получен в запросе на аутентификацию; система-клиент должна провести сравнение отправленного и полученного параметра state.
В.6.2.2 Проверка наличия аутентификации в фоновом режиме
Механизм бесшовной аутентификации предназначен для проведения автоматической аутентификации пользователя в ЕСИА при переходе в web-браузере на страницу информационной системы, интегрированной с сервисом авторизации ЕСИА (OAuth2.0). Данный механизм, основанный на OpenID Connect 1.0, использует функцию фоновой проверки наличия у пользователя авторизационной сессии в ЕСИА.
Для обеспечения сквозной (без явных действий пользовтеля) аутентификации и авторизации в ЕСИА реализован механизм, предоставляющий внешним ИС-потребителям интерфейс и функции прямой передачи сессии пользователя ЕСИА по технологии SSO.
Работоспособность механизма бесшовной аутентификации поддерживается в следующих браузерах согласно разделу 1.3 "Поддерживаемые браузеры" документации МР ЕСИА версии 2.54:
Функция фоновой проверки доступна к использованию отдельно от механизма бесшовной аутентификации, но при наличии разрешения у ИС-потребителя на использование механизма бесшовной аутентификации (см. ниже подраздел "Предоставление доступа к функциям механизма бесшовной аутентификации").
На странице авторизации ЕСИА разработан JS-плагин, точкой входа для которого является ссылка на сервис/ас (ЕСИА) с входными параметрами, передаваемыми JS-плагину внешней ИС.
JS-плагин реализован на основе функциональности проверки наличия аутентификации в фоновом режиме и имеет интерфейс в виде метода check(), предназначенный для передачи внешними ИС-потребителями параметров авторизации, используемых данным JS-плагином для проверки наличия аутентификации пользователя в ЕСИА:
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений следующих параметров HTTP-запроса: scope, timestamp, client_id, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА;
- <redirect_uri> - ссылка, по которой должен быть направлен пользователь после того, как даст разрешение на проведение аутентификации;
- <scope> - область доступа, т.е. запрашиваемые права; для проведения аутентификации пользователя scope должен иметь значение openid. Если системе потребуется получение дополнительных данных о пользователе (например, детальная информация о пользователе), то могут быть указаны дополнительные scope через пробел;
- <response_type> - это тип ответа, который ожидается от ЕСИА, имеет значение code, поскольку система-клиент должна получить авторизационный код;
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID;
- <timestamp> - время запроса авторизационного кода в формате yyyy.MM.dd HH:mm:ss Z
- <prompt>=<none> - возможность фоновой проверки информационной системой, интегрированной с ЕСИА, наличия у пользователя сессии в ЕСИА.
Если в ходе аутентификации не возникло ошибок, то ЕСИА осуществляет перенаправление пользователя по ссылке, указанной в параметре запроса на аутентификацию redirect_uri, а также возвращает два обязательных параметра:
- <code> - значение авторизационного кода;
- <state> - значение параметра state, который был получен в запросе на аутентификацию; система-клиент должна провести сравнение отправленного и полученного параметра state.
https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac?timestamp=2015.11.27+13%3A03%3A52+%2B0300&scope=
openid&client_secret=MIIFpgYJKoZIhvcNAQcCoIIFlzCCBZMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGgggNpMI
IDZTCCAk2gAwIBAgIECgPdVzANBgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJSVTEPMA0GA1UECBMGTW9zY293MQ8wDQYDVQQHEwZNb
3Njb3cxEDAOBgNVBAoTB0NvbXBhbnkxDzANBgNVBAsTBlN5c3RlbTEPMA0GA1UEAxMGU3lzdGVtMB4XDTE1MTAyOTE0MTUxMFoXDTE2
MDEyNzE0MTUxMFowYzELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2NvdzEPMA0GA1UEBxMGTW9zY293MRAwDgYDVQQKEwdDb21wYW5
5MQ8wDQYDVQQLEwZTeXN0ZW0xDzANBgNVBAMTBlN5c3RlbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhCeBbYRs89aP
Lf0TIytSufxmZsrgWVy2a0uOi8dyp-
vw6h3cqNh219WNNlyv0gYpiM8hNs6y7vKrQ2k83aur1b9a2RQ1LX0w1xAW55PHBsTS6I3FNLfLzPl0WIjiFEaqJl98--
L4BkR2Bk_CHroffMvUU5fqVPEfP4PFYD2oflBOoMBmXeemn0-xyZcnZ00WAvvRSfAYOaFp189EUV9QmVgvrKkc81Pqkx49dHH0KHFH-
s1uvZIkCcgnmdXBco5eeDg7EP9XbJuVp4uge9jDLBMw4SqzWQVUNmDJ0Vu5dWJUF8m5Z_TKEQ0nPVY9f7aqSJpiF-
N98TMgurGQzRJCECAwEAAaMhMB8wHQYDVR0OBBYEFMdZZfnOLJt2NkqTsqQq8biljqhRMA0GCSqGSIb3DQEBCwUAA4IBAQBMznNVeP4
E3fgWU4ZK9D2f78ONF330mE9xCLCDByDTMTMyCP6TEuMkDUYZ8UHQbohftwI6SP-0wjvYUe0qfjPu6IzID3n-
YM9642GHpzR0aR1ZXp8FM2p2GG5bQ3bGIE8Aa98SLXQzz6fOcYh3IvE-
YKHXEAGOgrx0Uh6xcTW7hZySEC74o9kn0atqp_L2p7dHnsjA-coKerKgbN5jJCwz6y0O_LBUKCAaffZ89BU-
5qrV_v1XnniF756h2Szk4KczSDex3IFXEUrntEpTWH1YhKNtwzvaMC92xSOgunpNo8lx4s9oNIobOKJEvKr1pR_caBgioy8SLLWecpS
ocb9BMYICATCCAf0CAQEwazBjMQswCQYDVQQGEwJSVTEPMA0GA1UECBMGTW9zY293MQ8wDQYDVQQHEwZNb3Njb3cxEDAOBgNVBAoTB0
NvbXBhbnkxDzANBgNVBAsTBlN5c3RlbTEPMA0GA1UEAxMGU3lzdGVtAgQKA91XMA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDM
QsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTI3MTAwMzUyWjAvBgkqhkiG9w0BCQQxIgQgu-JPaWt-
aHVLaF13Qudx5znqCAwpTPfdsv7scyfLMwYwDQYJKoZIhvcNAQEBBQAEggEAMQL3Uso76eQQPQ3DzewTUZujGwOi25WZyAYuQCxYlI-
liFOIQ74U2s5EPS-rK2EFVkgRPOjHIJ4lEcR8O1ObSowevI63a-4Tk4KF70-h0kLano93sixH0WmeAJpFoj8-
JpsMhJ_EJJwLtOpUvlbrWTQtk3d9F-
3vXdh6sXo91QtPzol_o3DkpS93mk5bYWBP92nHPvSfbadtBrtjWahq7UA3WUrQHCaLuIrsS0TRitya-Jv-0GJds-
hgEST2xlhbFz7eMgZmlTHsVrBCZngdO-
6jSIQVt4p99vD6uMhLKmIFrvNsOE1myaZL2AweumcyAZmS8Tb3tX953un_5CvVdw&response_type=code&redirect_uri=https%
3A%2F%2Fesia-portal1.test.gosuslugi.ru%2Faas%2Foauth2%2Ftest%2FoauthCallback.xhtml&state=f21125b6-60e2-
4edc-a0ab-e7da2d31708f&prompt=none&client_id=TESTSYS
В зависимости от наличия в ЕСИА авторизационной сессии пользователя и выданных им разрешений внешней ИС результатом обработки ЕСИА такого запроса может быть один из следующих вариантов:
- при отсутствии активной сессии пользователя будет возвращен ответ с сообщением о необходимости авторизации пользователя в ЕСИА;
Пример ответа с описанием его атрибутов:
{"error_description":"ESIA-007017:+OAuthErrorEnum.loginRequired","state":"25a40796-9d52-ff81-
18e1-87b85627129c","error": "login_required"}
error_description - номер (ESIA-007017) с мнемоникой ошибки (OAuthErrorEnum.loginRequired);
state - значение параметра state, который был получен в запросе на аутентификацию; система-клиент должна провести сравнение отправленного и полученного параметра state (d1802583-8733-337a-8058-60991fe8d715);
error - наименование ошибки (login_required, означает - пользователь не имеет активной сессии).
- при обнаружении активной сессии пользователя, но отсутствии выданных для данной ИС разрешений пользователя, будет возвращен ответ с сообщением о необходимости запроса разрешений пользователя на доступ к его данным в ЕСИА;
Пример ответа с описанием его атрибутов:
{"error_description":"ESIA-007018:+OAuthErrorEnum.interactionRequired","state":"45a35778-3a52-
gg5218w563b84657722c","error":"interactionRequired"}
error_description - номер (ESIA-007018) с мнемоникой ошибки (OAuthErrorEnum.interactionRequired);
state - значение параметра state, который был получен в запросе на аутентификацию; система-клиент должна провести сравнение отправленного и полученного параметра state (efa12233-ft83-267a-5s58-29041fe8d715);
error - наименование ошибки (interaction_required, означает - отсутствие у пользователя выданных разрешений для ИС).
- при обнаружении активной сессии и выданных разрешений пользователя для данной ИС будет возвращен авторизационный код, предназначенный для дальнейшего обмена ИС-потребителем на маркер идентификации или маркер доступа.
Предоставление доступа к функциям механизма бесшовной аутентификации.
Получение доступа к функциям механизма бесшовной аутентификации осуществляется путем обращения организации - владельца ИС в службу эксплуатации ЕСИА с запросом на добавление для ИС организации признака-разрешения "sauth".
В случае отсутствия у ИС-потребителя указанного разрешения попытка использования функций механизма бесшовной аутентификации или функции проверки наличия аутентификации в фоновом режиме будет приводить к возврату ответа с сообщением о необходимости авторизации пользователя в ЕСИА.
В.6.2.3 Вызов страницы аутентификации пользователя ЕСИА в новом всплывающем окне браузера
Механизм аутентификации, основанный на OpenID Connect 1.0, обеспечивает возможность вызова интегрированной системой страницы аутентификации пользователя в новом всплывающем окне браузера (в виде popup).
Для реализации этой возможности вызывающая ЕСИА система должна использовать параметр display запроса на проведение аутентификации со значением "popup". Пример запроса:
https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac?timestamp=2015.11.27+13%3A03%3A52+%2B0300&scope=
&client_secret=MIIFpgYJKoZIhvcNAQcCoIIFlzCCBZMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGgggNpMIIDZTCC
Ak2gAwIBAgIECgPdVzANBgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJSVTEPMA0GA1UECBMGTW9zY293MQ8wDQYDVQQHEwZNb3Njb3c
xEDAOBgNVBAoTB0NvbXBhbnkxDzANBgNVBAsTBlN5c3RlbTEPMA0GA1UEAxMGU3lzdGVtMB4XDTE1MTAyOTE0MTUxMFoXDTE2MDEyNz
E0MTUxMFowYzELMAkGA1UEBhMCUlUxDzANBgNVBAgTBk1vc2NvdzEPMA0GA1UEBxMGTW9zY293MRAwDgYDVQQKEwdDb21wYW55MQ8wD
QYDVQQLEwZTeXN0ZW0xDzANBgNVBAMTBlN5c3RlbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhCeBbYRs89aPLf0TIy
tSufxmZsrgWVy2a0uOi8dyp-
vw6h3cqNh219WNNlyv0gYpiM8hNs6y7vKrQ2k83aur1b9a2RQ1LX0w1xAW55PHBsTS6I3FNLfLzPl0WIjiFEaqJl98--
L4BkR2Bk_CHroffMvUU5fqVPEfP4PFYD2oflBOoMBmXeemn0-xyZcnZ00WAvvRSfAYOaFp189EUV9QmVgvrKkc81Pqkx49dHH0KHFH-
s1uvZIkCcgnmdXBco5eeDg7EP9XbJuVp4uge9jDLBMw4SqzWQVUNmDJ0Vu5dWJUF8m5Z_TKEQ0nPVY9f7aqSJpiF-
N98TMgurGQzRJCECAwEAAaMhMB8wHQYDVR0OBBYEFMdZZfnOLJt2NkqTsqQq8biljqhRMA0GCSqGSIb3DQEBCwUAA4IBAQBMznNVeP4
E3fgWU4ZK9D2f78ONF330mE9xCLCDByDTMTMyCP6TEuMkDUYZ8UHQbohftwI6SP-0wjvYUe0qfjPu6IzID3n-
YM9642GHpzR0aR1ZXp8FM2p2GG5bQ3bGIE8Aa98SLXQzz6fOcYh3IvE-
YKHXEAGOgrx0Uh6xcTW7hZySEC74o9kn0atqp_L2p7dHnsjA-coKerKgbN5jJCwz6y0O_LBUKCAaffZ89BU-
5qrV_v1XnniF756h2Szk4KczSDex3IFXEUrntEpTWH1YhKNtwzvaMC92xSOgunpNo8lx4s9oNIobOKJEvKr1pR_caBgioy8SLLWecpS
ocb9BMYICATCCAf0CAQEwazBjMQswCQYDVQQGEwJSVTEPMA0GA1UECBMGTW9zY293MQ8wDQYDVQQHEwZNb3Njb3cxEDAOBgNVBAoTB0
NvbXBhbnkxDzANBgNVBAsTBlN5c3RlbTEPMA0GA1UEAxMGU3lzdGVtAgQKA91XMA0GCWCGSAFlAwQCAQUAoGkwGAYJKoZIhvcNAQkDM
QsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTI3MTAwMzUyWjAvBgkqhkiG9w0BCQQxIgQgu-JPaWt-
aHVLaF13Qudx5znqCAwpTPfdsv7scyfLMwYwDQYJKoZIhvcNAQEBBQAEggEAMQL3Uso76eQQPQ3DzewTUZujGwOi25WZyAYuQCxYlI-
liFOIQ74U2s5EPS-rK2EFVkgRPOjHIJ4lEcR8O1ObSowevI63a-4Tk4KF70-h0kLano93sixH0WmeAJpFoj8-
JpsMhJ_EJJwLtOpUvlbrWTQtk3d9F-
3vXdh6sXo91QtPzol_o3DkpS93mk5bYWBP92nHPvSfbadtBrtjWahq7UA3WUrQHCaLuIrsS0TRitya-Jv-0GJds-
hgEST2xlhbFz7eMgZmlTHsVrBCZngdO-
6jSIQVt4p99vD6uMhLKmIFrvNsOE1myaZL2AweumcyAZmS8Tb3tX953un_5CvVdw&response_type=code&redirect_uri=https%
3A%2F%2Fesia-portal1.test.gosuslugi.ru%2Faas%2Foauth2%2Ftest%2FoauthCallback.xhtml&state=f21125b6-60e2-
4edc-a0ab-e7da2d31708f&display=popup&client_id=TESTSYS
Кроме того, система должна обеспечить открытие страницы аутентификации во всплывающем окне, рекомендуемый размер - 800 x 600. Пример фрагмента javascript для открытия страницы во всплывающем окне:
var h = 600;
var left = ($(window).width()/2)-(w/2);
var top = ($(window).height()/2)-(h/2);
var popup = window.open("request_url", "Request popup", "width=" + w + ",height=" + h + ",top=" + top +
",left=" + left + ",location=1,status=0,menubar=0,resizable=0,scrollbars=0");
В данном скрипте request_url должен быть заменен на URL, вызывающий аутентификацию пользователя в ЕСИА. Иными словами, этот request_url должен обеспечивать перенаправление пользователя на страницу предоставления прав доступа в ЕСИА, т.е. выполнение запроса на проведение аутентификации со значением "popup", указанного выше.
После успешной аутентификации ЕСИА возвращает результат аутентификации в открытое окно браузера. Системе, в свою очередь, нужно обеспечить исполнение собственной логики для закрытия всплывающего окна и передачи результатов аутентификации в основную веб-страницу системы (из которой было первоначально открыто всплывающее окно).
В.6.3 Получение маркера идентификации в обмен на авторизационный код
Когда авторизационный код получен, система-клиент может сформировать запрос методом POST в адрес ЕСИА для получения маркера идентификации <68>. Один авторизационный код можно обменять на один маркер идентификации. В тело запроса должны быть включены следующие сведения:
--------------------------------
<68> Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te
- <client_id> - идентификатор системы-клиента (мнемоника системы в ЕСИА, указанная прописными буквами);
- <code> - значение авторизационного кода, который был ранее получен от ЕСИА и который необходимо обменять на маркер идентификации;
- <grant_type> - принимает значение "authorization_code", если авторизационный код обменивается на маркер идентификации;
- <client_secret> - подпись запроса в формате PKCS#7 detached signature в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope, timestamp, clientId, state (без разделителей). <client_secret> должен быть закодирован в формате base64 url safe. Используемый для проверки подписи сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан к учетной записи системы-клиента в ЕСИА. ЕСИА поддерживает сертификаты в формате X.509. ЕСИА поддерживает алгоритм формирования электронной подписи ГОСТ Р 34.10-2012 и алгоритм криптографического хэширования ГОСТ Р 34.11-2012.
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса (необходимо для защиты от перехвата), генерируется по стандарту UUID; этот набор символов должен отличаться от того, который использовался при получении авторизационного кода;
- <redirect_uri> - ссылка, по которой должен быть направлен пользователь после аутентификации (то же самое значение, которое было указано в запросе на получение авторизационного кода);
- <scope> - область доступа, т.е. запрашиваемые права (то же самое значение, которое было указано в запросе на получение авторизационного кода);
- <timestamp> - время запроса маркера в формате yyyy.MM.dd HH:mm:ss Z (например, 2013.01.25 14:36:11 +0400), необходимое для фиксации начала временного промежутка, в течение которого будет валиден запрос с данным идентификатором (<state>);
- <token_type> - тип запрашиваемого маркера, в настоящее время ЕСИА поддерживает только значение "Bearer".
Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:
- <id_token> - маркер идентификации;
- <access_token> - маркер доступа для данного ресурса (если он запрашивался);
- <expires_in> - время, в течение которого истекает срок действия маркера (в секундах);
- <state> - набор случайных символов, имеющий вид 128-битного идентификатора запроса, генерируется по стандарту UUID (совпадает с идентификатором запроса);
- <token_type> - тип предоставленного маркера, в настоящее время ЕСИА поддерживает только значение "Bearer".
"id_token":
"eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWI
iOiAiMjQ4Mjg5zYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzE
xMjgxOTcwLAogImlhdCI6IDEzMTEyODA5NzfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6qp6IcmD3
HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJNqeGpe-
gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7TpdQyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0
YzFC6g6EJbOEoRoSK5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4XUVrWOLrLl0nx7RkKU8NXNHq
-rvKMzqg",
"expires_in" : 3600,
"state" : "9be638a9-0e05-42e1-b4f8-a3e30457fbdd",
"token_type" : "Bearer",
}
При невозможности выдачи маркера доступа возвращается код ошибки.
В.6.4 Проверка маркера идентификации
После получения маркера идентификации система-клиент должна произвести валидацию маркера идентификации, которая включает в себя следующие проверки:
1. Проверка идентификатора (мнемоники) ЕСИА, содержащейся в маркере идентификации.
2. Проверка идентификатора (мнемоники) системы-клиента, т.е. именно система-клиент должна быть указана в качестве адресата маркера идентификации.
3. Проверка подписи маркера идентификации (с использованием указанного в маркере алгоритма).
4. Текущее время должно быть не позднее чем время прекращения срока действия маркера идентификации.
После валидации маркера идентификации система-клиент считает пользователя аутентифицированным. Для получения дополнительных данных о пользователе следует использовать идентификатор пользователя, извлеченный из маркера идентификации, и соответствующие программные интерфейсы ЕСИА (требующие, в свою очередь, маркера доступа).
Детальные сведения о маркере идентификации представлены в Приложении В.7.
В.6.5 Выход из системы (логаут)
Для осуществления выхода из системы пользователь должен быть перенаправлен по специальной ссылке с соблюдением следующих требований:
- протокол запроса должен быть https;
- путь в HTTP-запросе должен быть равен /idp/ext/Logout (При завершении сессии требуется обязательно выполнять отправку запроса Logout);
- запрос должен иметь параметр (query param) с именем client_id, содержащий мнемонику обращающейся системы, зарегистрированной в ЕСИА;
- запрос может иметь параметр (query param) с именем redirect_url, содержащий адрес, на который пользователь будет перенаправлен после успешного логаута.
https://esia.gosuslugi.ru/idp/ext/Logout?client_id=ESIA&redirect_url=https://esia.gosuslugi.ru/registra
tion/
В ЕСИА для интегрированной системы может быть определен параметр system.siteUrl, содержащий URL-адрес системы, на который будет возвращен пользователь после логаута. Redirect_url должен быть подстрокой system.siteUrl.
При обработке запроса производятся следующие проверки:
1. Проверка, что передан обязательный параметр client_id. Если он не передан, то возвращается HTTP-код "400 Bad Request".
2. Проверка, что система с мнемоникой, указанной в параметре client_id, зарегистрирована в ЕСИА. Если система не зарегистрирована, то возвращается HTTP-код "403 Forbidden".
После успешного выполнения этих проверок ЕСИА определяет URL переадресации после успешного логаута:
- Если для системы в настройках ЕСИА не задан параметр system.siteUrl, то запрос после логаута будет направлен на сайт ЕСИА.
- Если в запросе не задан параметр redirect_url, то запрос после логаута будет направлен по адресу, заданному в system.siteUrl.
- Если параметры redirect_url и system.siteUrl не соответствуют друг другу (redirect_url должен быть подстрокой system.siteUrl), то запрос после логаута будет направлен на сайт ЕСИА.
В.7 Сведения о структуре маркера идентификации
Структура маркера идентификации аналогична структуре маркера доступа (см. Приложение В.5) и состоит из тех же трех частей: заголовок, набор утверждений и подпись.
Особенность заголовка маркера идентификации состоит в том, что него значение атрибута "sbt" равно "id".
Пример заголовка маркера идентификации в ЕСИА:
{"alg":"GOST3410_2012_512","sbt":"id","typ":"JWT","ver":0}
Сообщение, включающее в себя содержательные утверждения о маркере идентификации и пользователе, включает следующие атрибуты:
1) время аутентификации ("auth_time") - время, когда произошла аутентификация пользователя, указывается в секундах с 1 января 1970 г. 00:00:00 GMT;
2) время прекращения действия ("exp"), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;
3) идентификатор субъекта ("sub"), в качестве значения указывается oid. Этот идентификатор уникален для каждого субъекта, зарегистрированного в ЕСИА, и остается неизменным при последующих аутентификациях; адресат маркера ("aud"), указывается client_id системы, направившей запрос на аутентификацию;
4) организация, выпустившая маркер ("iss"), указывается URL ЕСИА;
5) время начала действия ("nbf") - в секундах с 1 января 1970 г. 00:00:00 GMT, т.е. маркер нельзя обрабатывать до наступления указанного времени;
6) внутренний идентификатор сессии ЕСИА ("urn:esia:sid");
7) начало блока описания субъекта вызова сессии ("urn:esia:sbj");
8) псевдоним субъекта ("urn:esia:sbj:nam") - внутренний для ЕСИА псевдоним пользователя;
9) oid субъекта ("urn:esia:sbj:oid") - oid учетной записи пользователя;
10) тип субъекта ("urn:esia:sbj:typ"), может принимать различные значения, например:
11) признак подтвержденности субъекта ("urn:esia:sbj:is_tru") - "is trusted" - учетная запись пользователя подтверждена. Параметр отсутствует, если учетная запись не подтверждена;
12) способ авторизации ("urn:esia:amd"), может принимать два значения: "DS" (электронная подпись) или "PWD" (пароль); время выдачи ("iat"), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;
13) метод аутентификации ("amr", приватное обозначение), может принимать два значения: "DS" (электронная подпись) или "PWD" (пароль);
Пример сообщения маркера идентификации в ЕСИА:
"auth_time": 1478618846748,
"exp": 1478629648,
"sub": 1000328225,
"aud": "TEST_SYS",
"iss": "http://esia.gosuslugi.ru/",
"nbf": 1478618848,
"urn:esia:sid": "0d543cf16cd43b4a2cd1b6ff96f1cb7da3ca2610d004b8816e951a8a7257ac53",
"urn:esia:sbj": {
"urn:esia:sbj:nam": "OID.1000328225",
"urn:esia:sbj:oid": 1000328225,
"urn:esia:sbj:typ": "P",
"urn:esia:sbj:is_tru": true
},
"urn:esia:amd": "PWD",
"iat": 1478618848,
"amr": "PWD"
}
Подпись (signature) маркера осуществляется по алгоритму, который указывается в параметре "alg" маркера. Подпись вычисляется от двух предыдущих частей маркера (HEADER.PAYLOAD).
В.8 Удаленная идентификация с использованием биометрической идентификации
Процедура удаленной идентификации включает последовательное прохождение аутентификации в ЕСИА по логину/паролю и верификации в биометрической системе по степени схожести биометрического образца.
Системы, в которых на данный момент доступна биометрическая идентификация:
- Единая биометрическая система.
Реализация взаимодействия ИС с биометрической системой при инициации удаленной идентификации производится согласно актуальной версии Методических рекомендаций биометрической системы. В рамках этого процесса должно быть выстроено стандартное взаимодействие с ЕСИА на следующих этапах:
- получение специального маркера доступа для взаимодействия с биометрической системой;
- завершение удаленной идентификации пользователя, получение пользовательского маркера доступа.
Указания по интеграции с Единой биометрической системой, в том числе - в части использования защищенных сетей передачи данных (VPN) при доступе к методам REST API Биометрической верификации, представлены в Приложении Б "Описание интеграции внешних систем с Единой биометрической системой в процессе биометрической верификации" документа "Методические рекомендации по работе с Единой биометрической системой", доступного на ресурсе https://bio.rt.ru/documents/basic/
Общая схема взаимодействия участников усиленной аутентификации представлена ниже.
Рисунок 17 - Схема взаимодействия участников
усиленной аутентификации
к протоколу заседания Подкомиссии
по использованию информационных
технологий при предоставлении
государственных и муниципальных услуг
Правительственной комиссии
по использованию информационных
технологий для улучшения качества
жизни и условий ведения
предпринимательской деятельности
от ________________ г. N ____
1. Получение специального маркера доступа для взаимодействия с биометрической системой
Информационная система реализует аутентификацию клиента и получение специального маркера доступа для взаимодействия с биометрической системой, разрешающего клиенту биометрическую верификацию в биометрической системе.
Для этого информационная система реализует взаимодействие с сервисом авторизации и получения маркера доступа ЕСИА, согласно Приложению В.2 "Модель контроля на основе делегированного принятия решения" данного документа.
В запросе на авторизацию ИС должна указать scope "openid" и специальный scope Единой биометрической системы - "bio", подробнее о котором указано в актуальных методических рекомендациях Единой биометрической системы.
Пользователь авторизуется в ЕСИА по логину и паролю и дает согласие на проведение усиленной аутентификации с использованием его биометрических данных в биометрической системе (в случаях, если согласие пользователя из данной информационной системы еще не получено).
В результате завершения этапа ИС получит специальный маркер доступа (access_token), обладающий следующими отличиями от стандартного маркера доступа ЕСИА:
- Наличие в составе маркера доступа URL REST-сервиса ЕСИА для передачи расширенного результата биометрической верификации из ЕБС (параметр ext_vrf_url).
В данном случае ИС не получает маркер обновления (refresh_token), то есть для каждого случая усиленной аутентификации ИС необходимо запрашивать маркер доступа заново.
Пример полученного расширенного маркера идентификации в ЕСИА:
"access_token":"eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE1MjgyMTI
4NTUsInNjb3BlIjoib3BlbmlkIGJpbyIsImV4dF92cmZfdXJsIjoiaHR0cHM6XC9cL2VzaWEtZGV2LnRlc3QuZ29zdXNsdWdpLnJ1XC
9lc2lhLXJzXC9hcGlcL3B1YmxpY1wvdjFcL2V4dFwvdnJmXC9yZXN1bHQiLCJpc3MiOiJodHRwOlwvXC9lc2lhLmdvc3VzbHVnaS5yd
VwvIiwidXJuOmVzaWE6c2lkIjoiMDI4Zjk0NWI5MjEwN2ZiMjc5MTE4YTM1OGM2M2ZiNDRhMzdjOGZiOTAyMjA1OGQxZjlhMjdiNjIz
MDg5ZjQ3YSIsInVybjplc2lhOnNial9pZCI6MTAwMDI5OTI4MiwiZXhwIjoxNTI4MjEzNDU1LCJpYXQiOjE1MjgyMTI4NTUsImNsaWV
udF9pZCI6IlRFU1RfU1lTIn0.FqmQrXLPQBAP8Sl8u6l2XyjtGWK3uNRA8IU7hH6nNHCSVffijYtFqmHOv4can_zXrzEKqG6Y_E21I1
6XcRuG_YoTnpBlBnH3FcCL9MqoiYQNETNC5AysumpTkmMXYPQqmJ4oPOVNyqJYye8TUtQmy9bI4Z3duvwZ3z11PZSlGZH9eETrWoRUq
yb316t4kKku9p6oM4gAgdu1_5gLeq3HcIPZV8XTQc625AOXg6qJPI52CchIRXJV-
MMZytX2ezKCs3OCyllXzq9mgk9OEfgdT7oHGQCDOLWjfhNm232yRikmhl-
u7M4QyCi0eChelQXFtjx38iaDDUgstHwMQsK7UQ","id_token":"eyJ2ZXIiOjAsInR5cCI6IkpXVCIsInNidCI6ImlkIiwiYWxnIj
oiUlMyNTYifQ.eyJhdWQiOiJURVNUX1NZUyIsInN1YiI6MTAwMDI5OTI4MiwibmJmIjoxNTI4MjEyODU1LCJhbXIiOiJQV0QiLCJ1cm
46ZXNpYTphbWQiOiJQV0QiLCJhdXRoX3RpbWUiOjE1MjgyMTI2OTQsImlzcyI6Imh0dHA6XC9cL2VzaWEuZ29zdXNsdWdpLnJ1XC8iL
CJ1cm46ZXNpYTpzaWQiOiIwMjhmOTQ1YjkyMTA3ZmIyNzkxMThhMzU4YzYzZmI0NGEzN2M4ZmI5MDIyMDU4ZDFmOWEyN2I2MjMwODlm
NDdhIiwidXJuOmVzaWE6c2JqIjp7InVybjplc2lhOnNiajp0eXAiOiJQIiwidXJuOmVzaWE6c2JqOmlzX3RydSI6dHJ1ZSwidXJuOmV
zaWE6c2JqOm9pZCI6MTAwMDI5OTI4MiwidXJuOmVzaWE6c2JqOm5hbSI6Ik9JRC4xMDAwMjk5MjgyIn0sImV4cCI6MTUyODIyMzY1NS
wiaWF0IjoxNTI4MjEyODU1fQ.P-5adtNRIECAgrJ7SCbXN6hHXxSAaP2olryXlHswvye_jyObow-
7SBN28ez1SG3C3Gxt8dZOq3JrKVa92Fr2PVNc9ACNnqHJDEY_4sSVTCKUjiTTXTW4nJNYmTTrczoAwuqir7PvNRYUtZuFAE8CwFrAl_
PPKExT0XaAP4Fc5BL_XOUPEw7XVYEjasBXzhoEMO0cVoGpztolATyxqYhkiR9AgXtd_sjye4svl5vEBxpGJOm8qSO_eM_orfC2_REyF
0XQtbblFW4qLe9zsko6vtm1QDW28Un101pXwAVhJN1oO0lATiT0uYWq0gxrt2U2B9kZPCak8nbgJizZx4NtNg",
"state":"21335561-1ee3-f501-79b3-bb10c06fd0f3",
"token_type":"Bearer",
"expires_in":600
}
Пример состава расширенного маркера доступа (PAYLOAD-часть):
"nbf": 1528212764,
"scope": "openid bio",
"ext_vrf_url": "https://esia-portal1.test.gosuslugi.ru/esia-rs/api/public/v1/ext/vrf/result",
"iss": "http://esia.gosuslugi.ru/",
"urn:esia:sid": "028f945b92107fb279118a358c63fb44a37c8fb9022058d1f9a27b623089f47a",
"urn:esia:sbj_id": 1000299282,
"exp": 1528213364,
"iat": 1528212764,
"client_id": "TEST_SYS"
}
2. Завершение удаленной идентификации пользователя, получение пользовательского маркера доступа
Информационная система реализует аутентификацию клиента и получение специального маркера доступа для завершения процесса удаленной идентификации пользователя в ЕСИА/биометрической системе.
Для этого информационная система реализует взаимодействие с сервисом авторизации и получения маркера доступа ЕСИА (аналогично предыдущему этапу).
В запросе на авторизацию <69> информационная система должна указать scope "openid" и специальный scope ("ext_auth_result" <70>), параметр verify_token (получен в результате верификации биометрических данных в биометрической системе).
--------------------------------
<69> Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te
<70> Набор данных, доступный ИС по данному scope, описан в Приложении В.4, п. 4.
В результате завершения этапа ИС Потребителя БДн получит специальный пользовательский расширенный маркер доступа, который будет содержать результат биометрической верификации.
ЕСИА выдаст данный маркер доступа только в случае:
- наличия в ЕСИА успешного результата биометрической верификации Пользователя;
- успешного сравнивания полученных параметров verify_token от биометрической системы и информационной системы;
- наличия согласия Пользователя на предоставление персональных данных.
В данном случае ИС не получает маркер обновления (refresh_token), то есть для каждого случая усиленной аутентификации ИС и получения доступа к данным пользователя необходимо запрашивать пользовательский маркер доступа заново.
Пользователь автоматически аутентифицируется в ЕСИА.
Пример полученного расширенного маркера идентификации в ЕСИА:
{"access_token":"eyJ2ZXIiOjEsInR5cCI6IkpXVCIsInNidCI6ImFjY2VzcyIsImFsZyI6IlJTMjU2In0.eyJuYmYiOjE1MjgyNz
gyNDgsInNjb3BlIjoiZXh0X2F1dGhfcmVzdWx0P29pZD0xMDAwMjk5MjgyIG9wZW5pZCIsImlzcyI6Imh0dHA6XC9cL2VzaWEuZ29zd
XNsdWdpLnJ1XC8iLCJ1cm46ZXNpYTpzaWQiOiI0MWM5ODUzMjc5ZjJkOTJhZDMwYWI5Yjk0MjMwMzU5YTM5MjUwZWY3ZTVhNzZlMDgz
ODgyZDYwZjhkZGYxZjhjIiwibWF0Y2giOnsidm9pY2UiOiIwLjk1IiwiZmFjZSI6IjAuOCIsIm92ZXJhbGwiOiIwLjkifSwidXJuOmV
zaWE6c2JqX2lkIjoxMDAwMjk5MjgyLCJleHAiOjE1MjgyODkwNDgsImlhdCI6MTUyODI3ODI0OCwiY2xpZW50X2lkIjoiVEVTVF9TWV
MifQ.Ica41_-BWPq6W0O-mYfA8OzvhPuvousw9Q51YdgDw9gcpF3CwekIUjNTnnehJHQiBwVIm2-
EucjzK8ZXOyvmFPHcc0R_Yx6xV6hfL0ehidOrphx-w9-
pRuw9vAfsMrAsfvTRzgv6Ek13HpiSr57BLOTUcRqKDsacjVayemQOvzA4CLYmTJbam8wVs93itlz1kv1_G3J-jUV29sMpz-
6yc0F_yU0mwXdx90qTkVvZrefGD0q04ISys_d1-
9j7z3iytzZ0viJj1EbrVxZXj3vNX6Ov2YekJ0JTk88DPCT8TcHpK_3wWNhQpLATp1iWYtq690UVYtJTLpTFv8uVTbCkpA",
"state":"c5edcf06-6993-bd32-fc28-12d707388622",
"token_type":"Bearer",
"expires_in":10800}
Пример состава расширенного маркера доступа (PAYLOAD-часть):
"nbf": 1528278248,
"scope": "ext_auth_result?oid=1000299282 openid",
"iss": "http://esia.gosuslugi.ru/",
"urn:esia:sid": "41c9853279f2d92ad30ab9b94230359a39250ef7e5a76e083882d60f8ddf1f8c",
"urn:esia:sbj_id": 1000299282,
"exp": 1528289048,
"iat": 1528278248,
"client_id": "TEST_SYS"
}
СЕРВИС РЕГИСТРАЦИИ ПОЛЬЗОВАТЕЛЯ И ПОДТВЕРЖДЕНИЯ ЛИЧНОСТИ
В целях регистрации пользователей в ЕСИА, а также подтверждения личности пользователей создан и опубликован в СМЭВ электронный сервис "Сервис регистрации пользователей Единой системы идентификации и аутентификации" <71>. Сервис предназначен для использования Операторами выдачи ключа ПЭП - организациями, которые в соответствии с постановлением Правительства РФ от 25 января 2013 г. N 33 "Об использовании простой электронной подписи при оказании государственных и муниципальных услуг" обладают правом создания (замены) и выдачи ключа простых электронных подписей и усиленных квалифицированных электронных подписей в целях оказания государственных и муниципальных услуг <72>.
--------------------------------
<71> SID данного сервиса в тестовой среде СМЭВ - SID0003419, в продуктивной - SID0003923.
<72> Порядок создания записи регистра органов и организаций, имеющих право создания (замены) и выдачи ключа простой электронной подписи (Операторов выдачи ключа ПЭП), определен в п. 12 Регламента.
Данный сервис ЕСИА поддерживает следующие функции:
- инициирование регистрации новой подтвержденной учетной записи пользователя в ЕСИА с выдачей идентификатора заявки на регистрацию пользователя, а также пароля пользователя для первого входа в систему;
- подтверждение учетной записи (подтверждения личности) пользователя ЕСИА, в том числе - выдача кода подтверждения для подтверждения упрощенной учетной записи пользователя;
- инициирование процедуры восстановления доступа к подтвержденной учетной записи пользователя в ЕСИА с выдачей идентификатора заявки на восстановление доступа, а также пароля пользователя для входа в систему;
- инициирование регистрации подтвержденной учетной записи пользователя в ЕСИА на базе существующей упрощенной;
- регистрация данных о детях пользователя;
- проверка статуса выполняемой операции (по регистрации пользователя/восстановлению доступа) <73>;
--------------------------------
<73> Детальная информация о работе сервиса и получении к нему доступа содержится в Руководстве пользователя электронного сервиса СМЭВ "Сервис регистрации Единой системы идентификации и аутентификации".
Г.1 Получение доступа к электронному сервису
Каждый орган/организация для использования программного интерфейса ЕСИА по регистрации пользователей должен:
1. Подать заявку на создание записи регистра органов и организаций, имеющих право создания (замены) и выдачи ключа простой электронной подписи согласно п. 12 Регламента.
2. Доработать (разработать) свою ИС, в которой будет предусмотрена функция регистрации пользователей ЕСИА.
3. Сгенерировать для ИС криптографические ключи и выпустить на них квалифицированный сертификат ЭП:
- Сертификат должен быть выпущен на юридическое лицо (содержит ОГРН и имя организации).
- Сертификат должен быть выпущен аккредитованным УЦ.
- Требования к ключевому контейнеру определяются эксплуатационной документацией на ИС, которая будет использовать ключи.
4. Зарегистрировать ИС в СМЭВ (согласно регламенту СМЭВ подается заявка на регистрацию ИС).
5. Получить для ИС в СМЭВ права на доступ к сервису ЕСИА в СМЭВ.
6. Зарегистрировать ИС в ЕСИА согласно п. 6 Регламента.
7. Зарегистрировать подключение ИС в тестовом контуре ЕСИА для отработки интеграции согласно п. 9 Регламента.
8. Зарегистрировать подключение ИС в продуктивном контуре ЕСИА для отработки интеграции согласно п. 10 Регламента.
9. Зарегистрировать в ЕСИА Центры обслуживания органа/организации. Для этого можно воспользоваться Технологическим порталом ЕСИА.
10. Настроить свою ИС согласно ее эксплуатационной документации. В частности, необходимо завести в ИС идентификаторы Центров обслуживания, полученные на предыдущем шаге, а также установить сетевую связность к СМЭВ и задать использование ключей, соответствующих зарегистрированному в ЕСИА и СМЭВ сертификату ИС.
11. Специалистам Центров обслуживания, которые будут выполнять регистрацию пользователей в ЕСИА, нужно выпустить средства КЭП. В сертификатах обязательно должны быть ОГРН организации (из тех, что получили право выдачи ПЭП), СНИЛС сотрудника.
12. Дать доступ специалистам Центров обслуживания к ИС согласно ее эксплуатационной документации.
Общая схема регистрации пользователя с использованием электронного сервиса включает в себя следующие шаги (Рисунок):
1. ИС отправляет запрос на регистрацию, включающий персональные данные пользователя, а также ряд дополнительных параметров.
2. ЕСИА возвращает идентификатор заявки на регистрацию пользователя, а также передает пароль для первого входа.
3. ЕСИА проводит проверку данных пользователя в БГИР, если проверки пройдены успешно, то регистрирует учетную запись.
4. ИС при необходимости вызывает метод, позволяющий проверить статус выполняемой регистрации, в качестве входных параметров указывая идентификатор заявки на регистрацию пользователя.
5. ЕСИА возвращает статус регистрации пользователя.
Рисунок 18 - Общая схема регистрации пользователя
Г.2.1 Запрос на регистрацию новой подтвержденной учетной записи
Для инициирования регистрации новой подтвержденной учетной записи пользователя в ЕСИА необходимо вызвать метод "Зарегистрировать подтвержденную учетную запись в ЕСИА с выдачей пароля для первого входа".
В качестве входных параметров метод получает персональные данные регистрируемого пользователя, необходимые для проведения операции, а также данные о способе доставки пароля для первого входа в систему. Возможны следующие способы доставки:
- отправка на адрес электронной почты (при условии, что при вызове сервиса адрес указан среди личных данных пользователя);
- отправка на номер мобильного телефона (при условии, что при вызове сервиса номер указан среди личных данных пользователя);
- отправка пароля не требуется (например, если пользователь будет входить в систему с использованием электронной подписи).
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на регистрацию пользователя (requestId), поскольку верификация данных пользователя осуществляется в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей).
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на регистрацию создана успешно, ЕСИА направляет пользователю по указанным в запросе каналам связи уведомление об успехе проверки и возможности входа в учетную запись. Если данные пользователя не прошли проверку по БГИР (и в заявке указан e-mail и/или номер мобильного телефона), ЕСИА направляет пользователю уведомление об этом. Регистрация учетной записи, данные профиля которой не прошли проверку по БГИР, не производится.
Г.2.2 Проверка состояния выполнения запроса
Для проверки статуса регистрации ИС должна произвести вызов метода "Проверить статус заявки на выполнение операции", в качестве входных параметров метод получает идентификатор заявки на регистрацию пользователя (requestId). Система, осуществляющая вызов сервиса ЕСИА, с использованием requestId может получить данные только по запросам, которые были инициированы ей самой.
В ответном сообщении передается информация о текущем статусе выполнения операции по регистрации пользователя.
Г.3 Подтверждение личности пользователя
Сервис регистрации пользователей, зарегистрированных в СМЭВ, обеспечивает возможность подтверждения личности в Центрах обслуживания Оператора выдачи ключа ПЭП. Для этого необходимо вызвать метод "Подтвердить личность гражданина РФ или иностранного гражданина в ЕСИА" данного сервиса.
Чтобы подтвердить свою учетную запись, пользователь должен предварительно создать упрощенную (непроверенную) или стандартную (проверенную) учетную запись. Это может сделать любой пользователь, имеющий номер мобильного телефона или адрес электронной почты, используя веб-интерфейс ЕСИА. Подтвержденная учетная запись создается пользователем из упрощенной (непроверенной) учетной записи в результате успешной проверки личных данных пользователя в базовых государственных информационных ресурсах (СНИЛС, ФИО, паспортные данные и др.) и подтверждения личности одним из доступных способов, в частности, посредством обращения в один из Центров обслуживания.
При регистрации учетной записи в Центре обслуживания с помощью метода "Зарегистрировать подтвержденную учетную запись в ЕСИА с выдачей пароля для первого входа" сразу создается подтвержденная учетная запись пользователя.
В качестве входных параметров метод, нацеленный на подтверждение личности, получает данные документа, удостоверяющего личность, а также ряд дополнительных параметров. В частности, может быть передан один из возможных типов контакта (email или mobile) для идентификации заявки на подтверждение учетной записи <74>.
--------------------------------
<74> Указание одного типа контакта необходимо для случая, когда имеется несколько заявок на подтверждение личности с идентичными данными документа, удостоверяющего личность.
В качестве выходных параметров метод возвращает результат выполнения операции.
Г.4 Восстановление доступа к учетной записи пользователя
Сервис регистрации пользователей, зарегистрированных в СМЭВ, обеспечивает возможность восстановления доступа к подтвержденной учетной записи пользователя при явке в Центр обслуживания Оператора выдачи ключа ПЭП. Для восстановления доступа необходимо вызвать метод "Восстановить доступ к учетной записи ЕСИА с выдачей пароля для входа" данного сервиса.
В качестве входных параметров метод получает персональные данные пользователя, необходимые для проведения операции, а также данные о способе доставки пароля для входа в систему. Возможны следующие способы доставки:
- отправка на адрес электронной почты (при условии, что при вызове сервиса адрес указан среди личных данных пользователя);
- отправка на номер мобильного телефона (при условии, что при вызове сервиса номер указан среди личных данных пользователя).
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или неуспешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на восстановление доступа (requestId), поскольку при восстановлении доступа осуществляется верификация данных пользователя в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей), а также пароль для входа в систему <75>.
--------------------------------
<75> Необходимость выполнения проверок данных пользователя связана с тем, что его идентификационные данные (ФИО, данные документа, удостоверяющего личность) могли измениться к моменту восстановления доступа. В этом случае пользователь сохраняет возможность восстановления доступа к своей учетной записи.
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на восстановление доступа выполнена успешно, ЕСИА направляет пользователю по указанным в запросе каналам связи уведомление об успехе проверки и возможности входа в учетную запись. Если данные пользователя не прошли проверку по БГИР (и в заявке указан e-mail и/или номер мобильного телефона), ЕСИА направляет пользователю уведомление об этом, при этом восстановление доступа к учетной записи не производится.
Специалист Центра обслуживания Оператора выдачи ключа ПЭП имеет возможность проверить статус восстановления доступа. Для этого ИС Оператора выдачи ключа ПЭП должна произвести вызов метода "Проверить статус заявки на выполнение операции", в качестве входных параметров метод получает идентификатор заявки на восстановление доступа (requestId). Система, осуществляющая вызов сервиса ЕСИА, с использованием requestId может получить данные только по запросам, которые были инициированы ей самой.
В ответном сообщении передается информация о текущем статусе выполнения операции восстановления доступа к учетной записи пользователя.
Г.5 Удаление учетной записи пользователя
Сервис регистрации пользователей, зарегистрированных в СМЭВ, обеспечивает возможность удаления подтвержденной учетной записи пользователя при явке в Центр обслуживания Оператора выдачи ключа ПЭП. Для удаления необходимо вызвать метод "Удалить учетную запись пользователя ЕСИА".
В качестве входных параметров метод получает персональные данные пользователя, необходимые для проведения операции.
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на удаление учетной записи (requestId), поскольку при удалении осуществляется верификация данных пользователя в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей) <76>.
--------------------------------
<76> Необходимость выполнения проверок данных пользователя связана с тем, что его идентификационные данные (ФИО, данные документа, удостоверяющего личность) могли измениться к моменту удаления учетной записи. В этом случае пользователь сохраняет возможность удалить свою учетную запись.
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на удаление выполнена успешно, ЕСИА производит удаление учетной записи и направляет пользователю уведомление об этом.
Специалист Центра обслуживания Оператора выдачи ключа ПЭП имеет возможность проверить статус удаления учетной записи. Для этого ИС Оператора выдачи ключа ПЭП должна произвести вызов метода "Проверить статус заявки на выполнение операции", в качестве входных параметров метод получает идентификатор заявки на удаление (requestId). Система, осуществляющая вызов сервиса ЕСИА, с использованием requestId может получить данные только по запросам, которые были инициированы ей самой.
В ответном сообщении передается информация о текущем статусе выполнения операции удаления учетной записи пользователя.
Г.6 Запрос на регистрацию подтвержденной учетной записи на базе существующей упрощенной
Для инициирования регистрации подтвержденной учетной записи пользователя в ЕСИА на базе существующей упрощенной необходимо вызвать метод "Подтверждение учетной записи, созданной на основе существующей упрощенной".
В качестве входных параметров метод получает персональные данные регистрируемого пользователя, необходимые для проведения операции.
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно).
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Г.7 Добавление данных о детях пользователя
Для добавления данных о детях в подтвержденную учетную запись пользователя в ЕСИА необходимо вызвать метод "Зарегистрировать данные о детях в подтвержденной учетной записи в ЕСИА".
В качестве входных параметров метод получает идентификационные данные зарегистрированного пользователя (для определения учетной записи, в которую необходимо добавить данные о детях) и данные о детях.
В качестве выходных параметров метод возвращает результат выполнения операции.
Г.8 Поиск учетной записи пользователя
Для поиска учетной записи пользователя в ЕСИА необходимо вызвать метод "Поиск учетной записи".
В качестве входных параметров метод получает идентификационные данные гражданина.
В качестве выходных параметров метод возвращает результат выполнения операции.
Г.9 Рекомендации по использованию сервиса
При обращении пользователя в Центр обслуживания <77> рекомендуется выяснить основную цель обращения, в зависимости от этого выбрать метод сервиса ЕСИА. Основные сценарии представлены в таблице 21.
--------------------------------
<77> Порядок регистрации Центров обслуживания Операторов выдачи ключа ПЭП определен в п. 14 Регламента.
Таблица 21 - Цели обращения пользователя
Г.9.2 Рекомендации по выбору способа доставки пароля
При регистрации подтвержденной учетной записи в ЕСИА рекомендуется отправлять пароль для первого входа на номер мобильного телефона пользователя, если производится обычная регистрация пользователя. Если производится регистрация с выдачей пользователю электронной подписи, то рекомендуется не отправлять пароль.
Если пользователь не имеет мобильного телефона, то допустимо использовать отправку пароля для первого входа на адрес электронной почты.
Г.9.3 Рекомендации по сохранению данных пользователя
При формировании запроса на регистрацию пользователя рекомендуется сохранять:
- идентификатор заявки на регистрацию пользователя (requestId);
- все данные, переданные методу "Зарегистрировать подтвержденную учетную запись в ЕСИА с выдачей пароля для первого входа".
Если пользователь будет проинформирован о возникшей в ходе регистрации ошибке (например, по адресу электронной почты), то он будет иметь возможность обратиться в свой Центр обслуживания для прояснения ситуации. В этом случае идентификатор заявки (requestId) и метод "Проверить заявку на регистрацию учетной записи" позволят получить дополнительную информацию о причинах проблемы. В частности, если при запросе была допущена опечатка, то специалист Центра обслуживания, имея сохраненные данные пользователя, будет иметь возможность отправить исправленную заявку на регистрацию учетной записи.
Г.9.4 Рекомендации по вызову метода "Подтвердить личность гражданина РФ или иностранного гражданина в ЕСИА"
При вызове сервиса "Подтвердить личность гражданина РФ или иностранного гражданина в ЕСИА" следует учесть, что даже при явном указании номера мобильного телефона/адреса электронной почты возможна ситуация, что учетная запись, требующая подтверждения личности, не будет найдена. Это возможно, например, если пользователь сообщил некорректный номер мобильного телефона/адрес электронной почты, либо этот тип контакта не был подтвержден в учетной записи. Следует уточнить у пользователя, какой логин он использует для входа в свою учетную запись, и осуществить вызов метода "Подтвердить личность гражданина РФ или иностранного гражданина в ЕСИА" именно с этим параметром.
При указании контактов необходимо передавать только один тип контакта (email или mobile) для идентификации заявки на подтверждение учетной записи.
Если пользователь не помнит номер мобильного телефона/адрес электронной почты, то можно предложить ему провести регистрацию учетной записи. Для этого следует вызвать метод "Зарегистрировать подтвержденную учетную запись в ЕСИА с выдачей пароля для первого входа".
Г.9.5 Рекомендации по взаимодействию с видами сведений в СМЭВ 3.X
Многие пользователи (клиенты ЦО), обращающиеся за государственными услугами или за услугой регистрации на портале госуслуг, не помнят, есть ли у них учетная запись и в каком она статусе. Одной из причин может являться редкое использование портала. Для правильного использования вида сведений ЕСИА операторами выдачи простой электронной подписи и уменьшения путаницы со стороны пользователя рекомендуется использовать алгоритм. Кроме рекомендуемого алгоритма необходимо придерживаться следующих правил работы с видом сведений:
- Для начала обслуживания пользователя в ЦО необходимо запросить и проверить его паспорт (и при необходимости СНИЛС). Данные при регистрации в ЕСИА необходимо передавать в соответствии с оригиналом документа, полученного от пользователя для минимизации ошибок при прохождении проверок данных пользователя в БГИР.
- Перед применением ВС <78> Register, RegisterBySimplified, Confirm, Recover, DeleteAccount необходимо применять ВС FindAccount для того, чтобы найти все учетные записи, удовлетворяющие входным параметрам, и выбрать конкретную учетную запись для продолжения работы с ней.
--------------------------------
<78> Детальная информация по описанию работы ВС доступна по ссылкам: Register, RegisterBySimplified, Confirm, Recover, DeleteAccount, FindAccount.
- После выбора конкретной учетной записи из списка найденных необходимо запросить подтверждение у пользователя, нужная ли учетная запись была выбрана, в соответствии с типом учетной записи, данными, по которым она была найдена, и датой ее регистрации. Это необходимо, потому что на данные пользователя может быть создано несколько учетных записей, например:
- - На данные пользователя создано несколько учетных записей (включая подтвержденную), при этом пользователь пользуется одной из них. В данном случае необходимо уточнить у пользователя, какой учетной записью он хотел бы продолжать пользоваться (сравнив данные, по которым они найдены). Если была выбрана подтвержденная учетная запись, то необходимо применить ВС Recover. В случае, если была выбрана упрощенная учетная запись, то необходимо применить ВС DeleteAccount для подтвержденной учетной записи и RegisterBySimplyfied - для выбранной упрощенной.
- - На данные пользователя создано несколько учетных записей, при этом пользователь обратился для создания новой учетной записи. В данном случае необходимо уточнить у пользователя, принадлежат ли ему найденные учетные записи (сравнив данные, по которым они найдены). Если была выбрана одна из найденных учетных записей, то необходимо применить к ней ВС RegisterBySimplified, Recover, Confirm (в зависимости от типа выбранной учетной записи). Если пользователь не регистрировал ранее учетную запись, то необходимо вместо регистрации новой учетной записи восстановить пароль к уже существующей учетной записи, используя данные пользователя.
В том случае если потребности операторов ЦО выходят за рамки данного алгоритма, разработчикам ПО для ЦО необходимо будет самостоятельно скомбинировать ВС требуемым образом.
Рекомендуемый алгоритм использования видов сведений
К ДАЛЬНЕЙШЕМУ ИСПОЛЬЗОВАНИЮ ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ЕСИА
В результате развития некоторые функциональные возможности ЕСИА сохраняются исключительно в целях обеспечения обратной совместимости.
Разработчикам ранее интегрированных ИС с ЕСИА рекомендуется отказаться от их использования.
Разработчикам вновь интегрируемых ИС с ЕСИА рекомендуется использовать актуальные функциональные возможности ЕСИА.
Д.2 Устаревшие утверждения SAML
Таблица 22 - Перечень атрибутов, поддержка которых
в будущем будет прекращена
Д.3 Устаревшие параметры сервиса регистрации
Таблица 23 - Перечень атрибутов, поддержка которых
в будущем будет прекращена
Значение параметра direct будет выведено из эксплуатации 30.10.16 |
Таблица 24 - Перечень скоупов, поддержка которых
в будущем будет прекращена
usr_inf | Просмотр всех персональных данных о пользователе. | Выведено из эксплуатации 14.07.17 | |
org_inf | Просмотр всех данных об организации "{Название}" и ее сотрудниках. | Выведено из эксплуатации 14.07.17 | |
usr_brf | Просмотр данных о пользователе. | Выведено из эксплуатации 14.07.17 | |
org_ful | Полный доступ ко всем данным организации "{Название}" и ее сотрудников | Выведено из эксплуатации 14.07.17 | |
sbj_inf | Просмотр данных о субъекте. | Выведено из эксплуатации 14.07.17 | |
Д.5 Устаревший импорт учетной записи
Версия импорта учетной записи, описанная в данном разделе, существует для обратной совместимости интегрированных ИС и не включает в себя функцию подтверждения упрощенных УЗ. Данная версия не будет дорабатываться в целях реализации новых функциональных возможностей.
Актуальная версия метода импорта учетных записей пользователей описана в Приложении Б.9.
Программный интерфейс, основанный на архитектурном стиле REST, в целях обеспечения импорта в ЕСИА учетных записей других ИС, обеспечивает возможность проверки наличия учетной записи пользователя, а в случае ее отсутствия - регистрации пользователя в ЕСИА. Алгоритм, по которому производится импорт учетной записи, приводится на рисунке ниже (см. Рисунок).
Рисунок 19 - Алгоритм устаревшего импорта учетной записи
Для импорта учетных записей система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом POST. В запросе должен быть указан ресурс /import.
В запросе на импорт учетной записи передаются следующие данные пользователя:
firstName | Имя | Y | Текстовая строка, содержащая не более 256 символов. | |
lastName | Фамилия | Y | Текстовая строка, содержащая не более 256 символов. | |
middleName | Отчество | Y | Текстовая строка, содержащая не более 256 символов. Необязательно, в случае если отчество отсутствует в паспорте. | |
birthDate | Дата рождения | Y | Формат: ДД.ММ.ГГГГ | |
birthPlace | Место рождения | N | Текстовая строка, содержащая не более 700 символов. | |
citizenship | Гражданство по классификатору ОКСМ | N/Y | Используется трехбуквенный код страны, например, для России он должен принимать значение RUS. По умолчанию принимается значение "RUS". Обязателен в случае, если указанный документ отличен от паспорта РФ. | |
gender | Пол | Y | Перечень допустимых значений: - "M" - мужской; - "F" - женский. | |
snils | СНИЛС | Y | Формат: "XXX-XXX-XXX XX" | |
контакт | Y | |||
type | Тип контакта | Y | Перечень допустимых значений: - "MBT" - мобильный телефон (обязательный параметр); - "EML" - электронная почта (необязательный параметр). | |
value | Значение | Y | Формат: - "+X(XXX)XXXXXXX" (для type = "MBT"); - текстовая строка в формате адреса электронной почты (для type = "EML"). | |
документ | Y | |||
type | Тип документа | Y | Перечень допустимых значений: - "RF_PASSPORT" - паспорт гражданина РФ; - "FID_DOC" - документ иностранного гражданина, удостоверяющий личность на территории РФ; - "FRGN_PASS" - заграничный паспорт гражданина РФ. | |
series | серия | Y/N | Для паспорта гражданина РФ в формате XXXX. Для заграничного паспорта гражданина РФ в формате XX. Необязательный для документа иностранного гражданина. | |
number | номер | Y | Для паспорта гражданина РФ в формате XXXXXX. Для заграничного паспорта гражданина РФ в формате XXXXXXX. | |
latinLastName | Фамилия (латиницей) | Y/N | Только для заграничного паспорта гражданина РФ. | |
latinFirstName | Имя (латиницей) | Y/N | Только для заграничного паспорта гражданина РФ. | |
issueId | Номер подразделения, выдавшего паспорт | Y/N | Только для паспорта гражданина РФ. Необязательный для документа иностранного гражданина и заграничного паспорта гражданина РФ. | |
issuedBy | Наименован ие подразделения, выдавшего паспорт | Y/N | Только для паспорта гражданина РФ. Необязательно для документа иностранного гражданина и заграничного паспорта гражданина РФ. | |
issueDate | Дата выдачи паспорта | Y | Формат: ДД.ММ.ГГГГ | |
expireDate | Дата окончания срока действия документа | Y/N | Только для заграничного паспорта гражданина РФ. Формат: ДД.ММ.ГГГГ | |
адрес | N | |||
type | Тип адреса | Y | Перечень допустимых значений: - "PLV" - адрес проживания; - "PRG" - адрес регистрации. | |
addressStr | Адресная строка | Y | Текстовая строка, содержащая элементы адреса (перечисляются через разделитель ",", не более 2000 символов) | |
countryId | Трехбуквенный код страны | N | В формате XXX. | |
zipCode | Индекс | N | Текстовая строка, содержащая не более 256 символов. | |
region | Область | N | Текстовая строка, содержащая не более 256 символов. | |
area | Район | N | Текстовая строка, содержащая не более 256 символов. | |
city | Город | N | Текстовая строка, содержащая не более 256 символов. | |
district | Округ | N | Текстовая строка, содержащая не более 256 символов. | |
settlement | Населенный пункт | N | Текстовая строка, содержащая не более 256 символов. | |
street | Улица | N | Текстовая строка, содержащая не более 256 символов. | |
additionArea | Уточнение по региону проживания | N | Текстовая строка, содержащая не более 256 символов. | |
additionAreaStr eet | Уточнение по улице | N | Текстовая строка, содержащая не более 256 символов. | |
house | Дом | N | Текстовая строка, содержащая не более 256 символов. | |
building | Строение | N | Текстовая строка, содержащая не более 256 символов. | |
frame | Корпус | N | Текстовая строка, содержащая не более 256 символов. | |
flat | Квартира | N | Текстовая строка, содержащая не более 256 символов. | |
fiasCode | Код ФИАС | N | Формат: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" | |
В запрос должен быть добавлен header (Authorization: Bearer) с ранее полученным маркером доступа, выданный на специальный scope (http://esia.gosuslugi.ru/ext_imp), позволяющий осуществлять автоматический импорт учетной записи пользователя. Данный маркер выдается только доверенным системам, имеющим право импорта пользователей таким образом; выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента (Приложение В.3), т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА.
Также запрос должен быть подписан электронной подписью системы, которая импортирует учетную запись в ЕСИА (Request-Data-Sign), и содержать тело запроса, закодированное в формате URL-Safe Base64 (Request-Data).
Пример запроса (вызов сервиса в среде разработки):
POST https://esia.gosuslugi.ru/rs/prns/import HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
Authorization: Bearer
eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6MX0.eyJleHAiOjE0NjEyMzI0MDU
sInNjb3BlIjoiaHR0cDpcL1wvZXNpYS5nb3N1c2x1Z2kucnVcL2V4dF9pbXAiLCJpc3MiOiJodHRwOlwvXC9lc2lhLm
dvc3VzbHVnaS5ydVwvIiwidXJuOmVzaWE6c2lkIjoiZDdkNGYzZWYtZjNlOS00MWVhLTliODUtY2MyODA3MTQzOWUyI
iwidXJuOmVzaWE6c2JqX2lkIjoxMDAwMDAwMDAyLCJjbGllbnRfaWQiOiJURVNUX1NZU1RFTV9JTVBPUlQiLCJpYXQi
OjE0NjExNDYwMDV9.Kw-
Kxh7ckYU_5xWTiUGdVn3rkFSp6TtfopivPfXnvgyPcqRmmPDsqjR_tJyhLED8w8iV6hjk2euchvi4aXxY1m_r716EXS
DiAae2WUd0rrGEb-SKIH5hXEBRwBIOTPlq-xA-Q3Lc-717yt6SAZAJtvUKKzaryYWDi-
r9wYZuR5kN2XQ8i75n85HhP1KcnERWQjT8DfQXEoaHP6rBqc9YECxtIiUFjZADk1jN1u6Ojq9kGEffRoGyPF7VGNMfU
jR469E0d1I3MLdlmSh8MdHW_mePoR19EguQPUtHwrtEALpyFLiiqvBwlnX4UQvZ7DWO1wfbwT16pNHfoY2FdUA5Jw
Request-Data-Sign:
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIDJTCCAg0CBFhKg5U
wDQYJKoZIhvcNAQELBQAwVzELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzENMAsGA1UECgwEVGVzdDENMAsGA1
UECwwEVGVzdDEZMBcGA1UEAwwQVGVzdCBSZXN0IFN5c3RlbTAeFw0xNjEyMDkxMDEyMzdaFw0xNzEyMDkxMDEyMzdaM
FcxCzAJBgNVBAYTAlJVMQ8wDQYDVQQIDAZNb3Njb3cxDTALBgNVBAoMBFRlc3QxDTALBgNVBAsMBFRlc3QxGTAXBgNV
BAMMEFRlc3QgUmVzdCBTeXN0ZW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCByEsM2_R1BrtltyJ15Aw
CW_tChh2euZC3FEqWDY6TFAlVyy9yO4qM_5P1WruplhA9dCCbft5JFsz4n_nE7lMMRaI34tqTyyo24xzX_VrhgTIi05
mt1Y5dbldfEiPVNT3aUCjFlbFzDXoUbc8nfQizkPa_CHGO0MBhuVuQWOVzw3FufAlExDjNPUoRRvaYoBWOK_3SnyS7_
88xJn-_yQQVwu0TQkSuqpOsylfBM-
Wq10U5x4bJ2NSeL71AzZjCL_mh1daQTQxEwBlVLuMlc5srMyw_QHQ1McsNrqrnx3zhFFNLS5Sk_LrSxqxOsC4sgBw1o
udVayUUvGbqe_nxu7P3AgMBAAEwDQYJKoZIhvcNAQELBQADggEBABxK0C1NjQMyvtJvZNRyM21GwQOklaBZuqRErJmp
LAR7auYLbZnwEdt1I8KEJBQW6pTb99rnQs-T-
qZiChh0PYlbCxXGeVCXk5dJWSiGE_SdrjWvSOH83iUA2Lv8Pi3NlVW2GcNOlFySlzE9HvGYJTIr5I_X-dw64-
2NYETLIYPQ7HWwAEwy09ucL9LMjGKYBe5FrwiulAyD20-lnIpYtXdLSpflKangPlPd1xmxEBXMQUmoKg7dTE-
q2gYfZLNUKsAezrattHGHTPRnqwWQHmwly_rXXodlgcNxeilT_dvc0o_JfkNmqGCc09RXSx1BWSWGynLeBBjYMy9VN8
XYQpQAADGCAfUwggHxAgEBMF8wVzELMAkGA1UEBhMCUlUxDzANBgNVBAgMBk1vc2NvdzENMAsGA1UECgwEVGVzdDENM
AsGA1UECwwEVGVzdDEZMBcGA1UEAwwQVGVzdCBSZXN0IFN5c3RlbQIEWEqDlTANBglghkgBZQMEAgEFAKBpMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDYyMDE1NTA1NVowLwYJKoZIhvcNAQkEMSIEIOp
wKJnoLommyNRoKDDlWVsWuBdYfowQ4byOiN-
gSPe2MA0GCSqGSIb3DQEBAQUABIIBADlNWxdZeqGBq8_4WqRs9H4SLde_Sukc1AG6hNj1cbTqxzthzzm1n_JQEZOTYa
P9bQdTEhOvKZXxFXC_JjPBMQauZPJc1eOR5DDB_7X4MAgGpMQbhpTQz3Sg7acJuJdWuYxL92BDk4qyzuwgJdQJplVJi
ckBvC78XeJVo1w4_jx5CVEn3pUIPdKxib6da0evB6CsxD98JcsvWZ3u-
H3LQ0_ApUOUHeF84r3AZ5mtILYj2w6o8rMAmsTDe7CAUXvDUAp9o5cTPk57rDNaW96d5J3SUtmZdx2nGBS41kJYWJND
iqyfHJ7X4nZVOS0glbT_JnaXtxrZTWp9BJo6NKJaagQAAAAAAAA
Request-Data:
ew0KICAiZmlyc3ROYW1lIjoiw5DCmMOQwrLDkMKww5DCvcOQwr7DkMKyIiwNCiAgImxhc3ROYW1lIjoiw5DCmMOQwrL
DkMKww5DCvSIsDQogICJtaWRkbGVOYW1lIjoiw5DCmMOQwrLDkMKww5DCvcOQwr7DkMKyw5DCuMORwociLA0KICAiYm
lydGhEYXRlIjoiMDEuMDEuMTk5OSIsDQogICJiaXJ0aFBsYWNlIjoiw5DCnMOQwr7DkcKBw5DCusOQwrLDkMKwIiwNC
iAgImdlbmRlciI6Ik0iLA0KICAic25pbHMiOiIwMDAtMDAwLTAwMCAwNyIsDQogICJjb250YWN0cyI6IHsNCiAgICAi
ZWxlbWVudHMiOiBbDQogICAgICB7DQogICAgICAgICJ0eXBlIjogIk1CVCIsDQogICAgICAgICJ2YWx1ZSI6ICIrNyg
5OTkpOTk5OTk5OSINCiAgICAgIH0sDQogICAgICB7DQogICAgICAgICJ0eXBlIjogIkVNTCIsDQogICAgICAgICJ2YW
x1ZSI6ICJ0ZXN0QHRlc3QudHMiDQogICAgICB9DQogICAgXQ0KICB9LA0KICAiZG9jdW1lbnRzIjogew0KICAgICJlb
GVtZW50cyI6IFsNCiAgICAgIHsNCiAgICAgICAgInR5cGUiOiJSRl9QQVNTUE9SVCIsDQogICAgICAgICJzZXJpZXMi
OiIyMjIyIiwNCiAgICAgICAgIm51bWJlciI6Ijg4OTk5OSIsDQogICAgICAgICJpc3N1ZUlkIjoiMTExMDAxIiwNCiA
gICAgICAgImlzc3VlZEJ5Ijoiw5DCoMOQwqPDkMKSw5DClCDDkMKzLsOQwpzDkMK-
w5HCgcOQwrrDkMKyw5HCiyIsDQogICAgICAgICJpc3N1ZURhdGUiOiIxOC4wMy4yMDE2Ig0KICAgICAgfQ0KICAgIF0
NCiAgfSwNCiAgImFkZHJlc3NlcyI6ew0KICAgICJlbGVtZW50cyI6IFsNCiAgICAgIHsNCiAgICAgICJ0eXBlIjogIl
BMViIsDQogICAgICAiYWRkcmVzc1N0ciI6IsOQwprDkMK1w5DCvMOQwrXDkcKAw5DCvsOQwrLDkcKBw5DCusOQwrDDk
cKPIMOQwp7DkMKxw5DCu8OQwrDDkcKBw5HCgsORwowsIMOQwqLDkMKww5HCiMORwoLDkMKww5DCs8OQwr7DkMK7w5HC
jMORwoHDkMK6w5DCuMOQwrkgw5DCoMOQwrDDkMK5w5DCvsOQwr0sIMOQwqjDkMK1w5HCgMOQwrXDkMKzw5DCtcORwog
gw5DCn8OQwr7DkcKBw5DCtcOQwrvDkMK-w5DCuiDDkMKzw5DCvsORwoDDkMK-
w5DCtMORwoHDkMK6w5DCvsOQwrPDkMK-
ICAgICDDkcKCw5DCuMOQwr_DkMKwIiwNCiAgICAgICJjb3VudHJ5SWQiOiAiUlVTIiwNCiAgICAgICJ6aXBDb2RlIjo
gIjM5NDAwMCIsDQogICAgICAicmVnaW9uIjogIsOQwprDkMK1w5DCvMOQwrXDkcKAw5DCvsOQwrLDkcKBw5DCusOQwr
DDkcKPIMOQwp7DkMKxw5DCu8OQwrDDkcKBw5HCgsORwowiLA0KICAgICAgImFyZWEiOiAiw5DCosOQwrDDkcKIw5HCg
sOQwrDDkMKzw5DCvsOQwrvDkcKMw5HCgcOQwrrDkMK4w5DCuSDDkMKgw5DCsMOQwrnDkMK-
w5DCvSIsDQogICAgICAiY2l0eSI6ICLDkMKow5DCtcORwoDDkMK1w5DCs8OQwrXDkcKIIMOQwp_DkMK-
w5HCgcOQwrXDkMK7w5DCvsOQwrogw5DCs8OQwr7DkcKAw5DCvsOQwrTDkcKBw5DCusOQwr7DkMKzw5DCviDDkcKCw5D
CuMOQwr_DkMKwIiwNCiAgICAgICJkaXN0cmljdCI6ICLDkMK9w5DCtcORwoIiLA0KICAgICAgInNldHRsZW1lbnQiOi
Aiw5DCo8ORwoHDkcKCw5HCjC3DkMKQw5DCvcOQwrfDkMKww5HCgSDDkMKfw5DCvsORwoHDkMK1w5DCu8OQwr7DkMK6I
iwNCiAgICAgICJzdHJlZXQiOiAiw5DCocOQwr7DkMKyw5DCtcORwoLDkcKBw5DCusOQwrDDkcKPIMOQwqPDkMK7w5DC
uMORwobDkMKwIiwNCiAgICAgICJhZGRpdGlvbkFyZWEiOiAiw5DCoMOQwrXDkMKzw5DCuMOQwr7DkMK9IMOQwqHDkMK
ww5DCtMOQwr7DkMKyw5DCvsOQwrUgw5DCvcOQwrXDkMK6w5DCvsOQwrwtw5DCtSDDkcKCw5DCvsOQwrLDkMKww5HCgM
OQwrjDkcKJw5DCtcORwoHDkcKCw5DCssOQwr4iLA0KICAgICAgImFkZGl0aW9uQXJlYVN0cmVldCI6ICLDkMKiw5DCt
cORwoHDkcKCIiwNCiAgICAgICJob3VzZSI6ICI4Ni8xIiwNCiAgICAgICJidWlsZGluZyI6ICJlIiwNCiAgICAgICJm
cmFtZSI6ICIyMDTDkcKDIiwNCiAgICAgICJmbGF0IjogIsOQwr_DkMK-
w5DCvC40MTkiLA0KICAgICAgImZpYXNDb2RlIjogIjc3LTAtMDAwLTAwMC0wMDAtMDAwLTQyMzYtMDAwMC0wMDAiDQo
NCiAgICAgICAgfQ0KICAgICAgfQ0KICAgIF0NCiAgfQ0KfQ
Cache-Control: no-cache
Content-Length: 1476
Host: esia-portal1.test.gosulsugi.ru
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)
"firstName":"Иванов",
"lastName":"Иван",
"middleName":"Иванович",
"birthDate":"01.01.1999",
"birthPlace":"Москва",
"gender":"M",
"snils":"000-000-000 07",
"contacts": {
"elements": [
{
"type": "MBT",
"value": "+7(999)9999999"
},
{
"type": "EML",
"value": "test@test.ts"
}
]
},
"documents": {
"elements": [
{
"type":"RF_PASSPORT",
"series":"2222",
"number":"889999",
"issueId":"111001",
"issuedBy":"РУВД г.Москвы",
"issueDate":"18.03.2016"
}
]
},
"addresses":{
"elements": [
{
"type": "PLV",
"addressStr":" Кемеровская область, Таштагольский район, Шерегеш поселок городского
типа, Усть-Анзас поселок, Советская улица",
"countryId": "RUS",
"zipCode": "652975",
"region": "Кемеровская Область",
"area": "Таштагольский Район",
"city": "Шерегеш Поселок городского типа",
"settlement": "Усть-Анзас Поселок",
"house": "Дом 19",
"fiasCode": "b6fbb398-97ee-4e12-a1d3-450184d23f27"
}
]
}
}
По полученным данным в ЕСИА выполняется поиск учетной записи. В зависимости от того, найдена в ЕСИА учетная запись, удовлетворяющая полученным данным, или нет, операция импорта может завершиться одним из следующих результатов:
- пользователь уже зарегистрирован в ЕСИА (подтвержденная учетная запись найдена по СНИЛС, данные паспорта и телефона совпадают);
- некоторые атрибуты не совпадают (учетная запись найдена по СНИЛС, но не все атрибуты совпадают, либо найдена упрощенная учетная запись по мобильному телефону);
- пользователь ЕСИА успешно подтвержден (найдена стандартная или готовая к подтверждению учетная запись по СНИЛС, данные паспорта и телефона совпадают, найденная учетная запись успешно подтверждена);
- пользователь ЕСИА успешно переподтвержден (найдена УЗ, подтвержденная через Почту России, данные паспорта и телефона совпадают, найденная учетная запись успешно переподтверждена);
- создана заявка на регистрацию (не найдена учетная запись пользователя, в том числе упрощенная, создана заявка на регистрацию, получен номер заявки на регистрацию).
В ответе передаются следующие параметры:
requestId | Код заявки на регистрацию | Возвращается в случае создания заявки на регистрацию. | |
code | Код завершения операции | Может быть возвращен в виде значений: - 0 или 1 - выполнен импорт учетной записи; - 2 - создана заявка на импорт (регистрацию) учетной записи; - код ошибки, варианты приведены в Таблице 12. | |
description | Текстовое описание кода завершения операции | Описание для кодов успешного импорта учетной записи в ЕСИА (code = 0, 1 или 2) и для code = ESIA-03200 | |
message | Текстовое описание кода ошибки выполнения операции | Описание для кодов ошибок при импорте учетной записи в ЕСИА (за исключением кода ESIA-03200) Варианты ошибок приведены в Таблице 12 |
Далее приводятся варианты ответов сервиса, при завершении операции импорта.
Пример ответа на запрос (пользователь уже зарегистрирован в ЕСИА, учетная запись уже подтверждена ранее):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"0", "description":"Person already has trusted account in ESIA"}
Пример ответа на запрос (учетная запись пользователя успешно подтверждена в ЕСИА):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"1", "description":"Person successfully confirmed as trusted in ESIA"}
Пример ответа на запрос (учетная запись пользователя успешно переподтверждена в ЕСИА):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"1", "description":"Person successfully reconfirmed as trusted in ESIA"}
Пример ответа на запрос (запрос на регистрацию успешно отправлен, создана заявка на регистрацию):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"requestId":"AAAAF3A1379F965664CB56FCE55BD8CCA2F38368985607E75E23", "code":"2",
"description":"Request to register person as trusted in ESIA has been accepted
successfully."}
Пример ответа на запрос (ошибка импорта, некоторые атрибуты запроса не совпадают с учетной записью в ЕСИА - требуется корректировка параметров запроса или учетной записи в ЕСИА):
Server: nginx/1.4.6 (Ubuntu)
Date: Thu, 21 Apr 2016 13:43:37 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
X-Powered-By: Servlet/3.0 JSP/2.2
{"code":"ESIA-03200", "description":"Import account error. Person have to check entered
data or fill in the data in his account in ESIA."}
В таблице ниже представлены коды ответов от сервиса импорта.
Таблица 25 - Коды и описание ошибок от сервиса импорта
ESIA-000001 | Внутренняя ошибка | Данный код возврата соответствует ситуации, когда обнаружена неизвестная ошибка | |
ESIA-005029 | Scope is not allowed | У системы, осуществляющей запрос к сервису импорта, отсутствует разрешение на доступ к скоупу ext_imp (например, указанный в запросе маркер доступа не дает право доступа к скоупу ext_imp) | |
ESIA-030002 | Заполните поле | Одно из полей "Фамилия", "Имя", "Отчество" пришло с пустым значением | |
ESIA-030003 | Неверно указаны параметры запроса | ||
ESIA-030007 | Недопустимые символы в полях запроса | Поля запроса содержат недопустимые символы "<", ">" или "&" | |
ESIA-030504 | Сертификат электронной подписи имеет некорректную структуру. Обратитесь в удостоверяющий центр | ||
ESIA-03200 | Ошибка импорта учетной записи | Необходимо скорректировать данные пользователя в параметрах запроса или параметры учетной записи в ЕСИА | |
ESIA-032006 | Указан некорректный тип контакта | ||
ESIA-032101 | Указан некорректный адрес электронной почты | ||
ESIA-032102 | В структуре адреса электронной почты (в имени и домене) должны отсутствовать точки в начале и конце. Например, mymail.mymail@example.com - верно; mymail.@.example.com - неверно | ||
ESIA-032103 | Указан некорректный формат имени для адреса электронной почты. Доступные символы: латинские буквы a - z и A - Z, цифры 0 - 9 и знаки пунктуации (#$%*+-=?_`{}|~.) | ||
ESIA-032104 | Указан некорректный формат домена для адреса электронной почты. Доступные символы: латинские буквы a - z и A - Z, цифры 0 - 9 и знаки пунктуации (#$%*+-=?_`{}|~.) | ||
ESIA-032105 | Недопустимо использовать два и более раза подряд следующие символы: ".", "-". | ||
ESIA-032110 | Не указан адрес электронной почты при вызове метода импорта и указании пустого значения в атрибуте EML | Данный код возврата соответствует ситуации, когда в запросе передан пустой параметр EML | |
ESIA-032200 | Не указан номер мобильного телефона | ||
ESIA-032201 | Номер мобильного телефона содержит недопустимые символы | ||
ESIA-032202 | Номер мобильного телефона указан в неверном формате | ||
ESIA-032203 | Указан некорректный номер мобильного телефона | ||
ESIA-032205 | Указанный номер телефона уже используется для регистрации учетной записи | Данный код ошибки возвращается при повторном импорте, когда номер мобильного телефона уже используется при регистрации и с момента регистрации не прошло 3-х суток данной УЗ была подтверждена через СМС, а также идут проверки данных в БГИР и с момента регистрации первого запроса не прошло 3 суток, или уже запущена регистрация с использованием данного номера телефона и идут проверки данных в БГИР. | |
ESIA-033000 | Не указан тип документа | ||
ESIA-033001 | Введите серию документа | ||
ESIA-033002 | Введите номер документа | ||
ESIA-033003 | Не указана дата выдачи документа | ||
ESIA-033004 | Не указано ведомство, выдавшее документ | ||
ESIA-033005 | Укажите дату выдачи документа | ||
ESIA-033006 | Некорректная дата выдачи документа | ||
ESIA-033007 | Укажите дату окончания срока действия документа | Если загранпаспорт указан в качестве документа, удостоверяющего личность | |
ESIA-033008 | Некорректная дата окончания срока действия документа | Если загранпаспорт указан в качестве документа, удостоверяющего личность | |
ESIA-033009 | Дата окончания срока действия документа должна быть меньше, чем дата выдачи | Если загранпаспорт указан в качестве документа, удостоверяющего личность | |
ESIA-033010 | Document type is wrong | Указан неверный тип документа, удостоверяющего личность | |
ESIA-033011 | Длина названия ведомства, выдавшего документ, должна быть меньше {количество} символов | ||
ESIA-033100 | Серия паспорта должна состоять из {количество} цифр | ||
ESIA-033101 | Серия паспорта может содержать только цифры | ||
ESIA-033102 | Номер паспорта должен состоять из {количество} цифр | ||
ESIA-033103 | Номер паспорта может содержать только цифры | ||
ESIA-033104 | Введите код подразделения в паспорте | ||
ESIA-033105 | Код подразделения в паспорте должен состоять из {количество} цифр | ||
ESIA-033106 | Код подразделения в паспорте может содержать только цифры | ||
ESIA-033109 | RF Passport issuer element wrong length | Неверная длина поля "Выдан" для паспорта РФ | |
ESIA-033110 | RF Passport issuer element wrong character | В поле "Выдан" паспорта РФ указан недопустимый символ | |
ESIA-033201 | Серия документа может содержать только цифры, тире, буквы русского и латинского алфавита | ||
ESIA-033202 | Номер документа может содержать только цифры, тире, буквы русского и латинского алфавита | ||
ESIA-033300 | Серия документа должна состоять из {количество} символов | ||
ESIA-033301 | Серия документа может содержать только цифры и буквы русского алфавита | ||
ESIA-033302 | Номер документа должен состоять из {количество} цифр | ||
ESIA-033303 | Номер документа может содержать только цифры | ||
ESIA-034000 | ZipCode element is empty | Не указан индекс для адреса РФ. Поле "Индекс" присутствует, но не заполнено | |
ESIA-034001 | ZipCode format is wrong | Неверный формат индекса | |
ESIA-034002 | Address type is wrong | Неверный тип адреса | |
ESIA-034004 | AddressStr element is empty | Не указано значение поля addressStr | |
ESIA-034005 | Address elements House, Building, Frame are null | В адресе не указаны значения дом/корпус/строение | |
ESIA-034006 | Address element countryId is wrong | Указан неверный код страны | |
ESIA-035100 | Не указана фамилия | ||
ESIA-035101 | Не указано имя | ||
ESIA-035102 | Поле может содержать только буквы русского или латинского алфавитов, цифры, дефис, пробел, апостроф, точку, запятую. Запятая допустима только в середине слова. В поле недопустимо одновременно использовать русские и латинские буквы | ||
ESIA-035103 | Не указан пол | ||
ESIA-035104 | Укажите дату рождения | ||
ESIA-035105 | Некорректная дата рождения | ||
ESIA-035106 | Укажите гражданство | ||
ESIA-035107 | Укажите идентификационный документ | ||
ESIA-035108 | Указанный документ не является идентификационным документом | ||
ESIA-035109 | Указанные идентификационный документ и гражданство не соответствуют друг другу | ||
ESIA-035110 | Указанный пол {наименование} не соответствует словарю | ||
ESIA-035111 | Указанное гражданство {наименование} не соответствует словарю | ||
ESIA-035112 | Укажите место рождения | ||
ESIA-035113 | Укажите вид на жительство или разрешение на временное проживание | ||
ESIA-035115 | Указанная страна рождения {Наименование} не соответствует словарю | ||
ESIA-035117 | Количество символов не должно превышать 700 символов | Для поля "Кем выдан" (паспорт) | |
ESIA-035118 | Поле может содержать только буквы русского или латинского алфавитов, цифры, дефис, пробел, апостроф, точку, запятую. Запятая допустима только в середине слова. В поле недопустимо одновременно использовать русские и латинские буквы | Для поля "Имя" | |
ESIA-035119 | Количество символов не должно превышать 700 символов | Для поля "Месторождение" | |
ESIA-035120 | Количество символов в слове не должно превышать 30 символов | Для поля "Месторождение", если значение указано более одного слова, то отдельное слово не должно превышать 30 символов | |
ESIA-036100 | Введите СНИЛС | Не указан СНИЛС | |
ESIA-036101 | Некорректный формат СНИЛС | ||
ESIA-036102 | Введенный СНИЛС не существует | Указанный СНИЛС некорректен (неверная контрольная сумма) | |
ESIA-039600 | Указанный номер телефона используется в другой упрощенной учетной записи | Данный код возврата соответствует ситуации, когда найдена упрощенная учетная запись по указанному в запросе номеру мобильного телефона | |
ESIA-039812 | Номер мобильного телефона уже используется в другой учетной записи. Вы сможете зарегистрировать учетную запись на этот номер телефона не ранее дд.мм.гггг. Восстановите доступ к учетной записи или укажите другой номер мобильного телефона | Данный код возврата соответствует ситуации, когда номер телефона подтвержден в другой учетной записи менее 30 суток назад и его использование при регистрации новой учетной записи невозможно | |
ESIA-910307 | Registration Endorsement by SMS is falied | Истекло время ожидания ответного sms-сообщения с согласием на регистрацию или исчерпано количество попыток отправки ответного sms-сообщения (время ожидания - 3 суток, количество попыток - 3 шт.) |
Система, используя имеющийся идентификатор заявки на регистрацию пользователя, может узнать статус заявки, а также причину ошибки (при ее наличии). Для получения данных о ходе выполнения проверок система должна выполнить запрос методом GET в https-адрес REST-API системы ЕСИА <79>. Запрос также должен содержать маркер доступа системы на скоуп ext_imp.
--------------------------------
<79> В среде разработки сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/reqs/{requestId}, где requestId - уникальный идентификатор заявки на проверку данных пользователя.
GET https://esia-portal1.test.gosuslugi.ru/rs/reqs/
AAAA5F79379F965664CB739F5BDC6FD8E24797A576A4F056322D
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInNidCI6ImFjY2VzcyIsInR5cCI6IkpXVCIsInZlciI6M
В качестве ответа ЕСИА возвращает json с параметрами, указанными в табл. 13.
Таблица 26 - Параметры ответа на запрос
о статусе проверки данных пользователя
status | Y | Статус заявки на регистрацию пользователя. Может принимать значения: - VALIDATING - идет проверка данных учетной записи в БГИР; - VALIDATION_FAILED - ошибка при проверке данных учетной записи в БГИР, детализация ошибки содержится в параметре errorStatusInfo; - SUCCEEDED - операция успешно выполнена. | |
personOid | N | Идентификатор зарегистрированной учетной записи (возвращается в случае успешно выполненной операции импорта учетной записи в ЕСИА) | |
flowDetails | N | Возвращает данные о задаче, ее статус и - при наличии - об ошибке. Включает в себя следующие атрибуты: - имя (name), принимающее следующие значения: - до момента завершения проверки СНИЛС: - raRegistrationEndorsement - подтверждение пользователем регистрации по СМС; - sendSMS - отправка пароля для первого входа; - validateSnils - проверка ФИО, СНИЛС и даты рождения в ПФР России; - после успешного завершения проверки СНИЛС и создания упрощенной УЗ: - validateRfPassport - проверка паспортных данных в МВД России. - статус (status), принимающий следующие значения: - S - успешно выполнена; - P - в работе; - W - ожидает реакции пользователя или предыдущего связанного задания; - I - инициализирована; - C - операция отменена; - F - ошибка выполнения. - ошибка (error, необязательно), включающая в себя код ошибки (code) и текстовое описание (message). | |
errorStatusInfo | N | Детальная информация об ошибке (при наличии). Формат: - code - код ошибки; - message - текстовое описание ошибки. |
Пример ответа на запрос о статусе выполнения заявки (успешная регистрация учетной записи при импорте в ЕСИА):
{"stateFacts":["Identifiable"],"status":"SUCCEEDED","personOid":1000352622}
Пример ответа на запрос о статусе выполнения заявки (регистрация учетной записи при импорте в ЕСИА не выполнена - ошибка при проверке ФИО, СНИЛС и даты рождения в ПФР России):
"stateFacts":["Identifiable"],
"status": "VALIDATION_FAILED",
"flowDetails":
[
{
"name":"raRegistrationEndorsement",
"status":"S"
},
{
"name": "validateSnils",
"status": "F",
"error":{"code": "ESIA-910001",
"message": "Пенсионный фонд Российской Федерации не подтвердил существование
СНИЛС с указанными реквизитами"}
},
{
"name": "sendSMS",
"status": "C"
}
],
"errorStatusInfo":
{
"code": "ESIA-910001",
"message": "Пенсионный фонд Российской Федерации не подтвердил существование СНИЛС с
указанными реквизитами"
}
}
Пример ответа на запрос о статусе выполнения заявки (регистрация учетной записи при импорте в ЕСИА не выполнена - ошибка при проверке паспортных данных в МВД России):
"stateFacts":["Identifiable"],
"status": "VALIDATION_FAILED",
"flowDetails":
[
{
"name": "validateRfPassport",
"status": "F",
"error":{"code": "ESIA-910100",
"message": "В автоматическом режиме не удалось произвести проверку
вашего паспорта."}
}
],
"errorStatusInfo":
{
"code": "ESIA-910100",
"message": "В автоматическом режиме не удалось произвести проверку вашего
паспорта."
}
}
УПРОЩЕННОЙ ИДЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЕЙ ЕДИНОЙ СИСТЕМЫ
ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ
В целях идентификации пользователей и проверки корректности информации, которую они предоставляют об имеющихся у них документах, создан и опубликован в СМЭВ электронный сервис "Единый сервис упрощенной идентификации пользователей Единой системы идентификации и аутентификации" <80>. Сервис предназначен для использования финансовыми организациями во исполнение требований Федерального закона от 7 августа 2001 г. N 115-ФЗ "О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма" и Распоряжения Правительства Российской Федерации от 15 августа 2012 г. N 1471-р.
--------------------------------
<80> SID данного сервиса в тестовой среде СМЭВ - SID0004152, в продуктивной - SID0004769.
Сервис может быть использован в режиме проверки данных пользователя.
В режиме "проверка данных пользователя" идентификация личности и запрос разрешения на проверку данных документов пользователя не проводится. Проверка запускается непосредственно в момент обращения к сервису (в данном режиме).
В режиме "проверка данных пользователя" выполняются следующие проверки:
- паспорта (соответствия ФИО и паспорта);
- СНИЛС (соответствия ФИО и СНИЛС);
- ИНН (соответствия ФИО и ИНН).
Единый сервис поддерживает следующие функции:
- инициирование запроса на проверку данных пользователя;
- проверка статуса выполнения запроса на проверку данных пользователя.
Е.1 Получение доступа к электронному сервису
Порядок и правила получения доступа к единому сервису упрощенной идентификации пользователей Единой системы идентификации и аутентификации приведен в документе "Регламент информационного взаимодействия Участников с Оператором ЕСИА и Оператором эксплуатации инфраструктуры электронного правительства". Информация содержится в пункте "Порядок согласования права использования Единого сервиса упрощенной идентификации пользователей Единой системы идентификации и аутентификации". Документ доступен по адресу https://digital.gov.ru/ru/documents/4244/.
Е.2 Проверка данных пользователя
Проверка данных пользователя с использованием электронного сервиса включает в себя следующие шаги:
1. ИС отправляет запрос на проверку данных пользователя, включающий персональные данные пользователя;
2. сервис возвращает идентификатор заявки;
3. сервис инициирует проверку данных пользователя в БГИР;
4. ИС при необходимости вызывает метод, позволяющий проверить статус выполняемой проверки данных пользователя, в качестве входных параметров указывая идентификатор заявки;
5. сервис возвращает статус операции проверки данных пользователя. Если операция завершена, то возвращается статус операции (данные валидны или данные не валидны).
Е.2.1 Запрос на идентификацию и проверку данных пользователя
Для инициирования проверки данных пользователя необходимо вызвать метод "Отправить запрос на проверку данных пользователя (без отправки пользователю запроса на разрешение)".
В качестве входных параметров метод получает персональные данные проверяемого пользователя (серия и номер паспорта, ФИО, СНИЛС, ИНН), необходимые для проведения операции.
В качестве выходных параметров метод возвращает статус выполнения операции (успешно или не успешно), идентификатор заявки на идентификацию пользователя и проверку его данных (requestId), поскольку проверка данных пользователя осуществляется в асинхронном режиме.
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Е.2.2 Проверка состояния выполнения запроса
Для получения результата идентификации пользователя и проверки его данных должен быть вызван метод "Получить результат обработки запроса на проверку данных пользователя (без подтверждения пользователем разрешения)", в качестве входного параметра метод получает идентификатор заявки на проверку данных пользователя (requestId).
В выходных параметрах передается информация о текущем статусе выполнения операции по проверке данных пользователя. В случае, если операция проверки завершена, в ответном сообщении передается результат проверки: указаны данные корректны, в процессе обработки, данные некорректны или неверный код запроса.
При неуспешном завершении метода возвращает ошибку, содержащую код и текст ошибки.
ФЗ о страховых пенсиях
ФЗ о пожарной безопасности
ФЗ об ОСАГО
ФЗ об образовании
ФЗ о государственной гражданской службе
ФЗ о государственном оборонном заказе
О защите прав потребителей
ФЗ о противодействии коррупции
ФЗ о рекламе
ФЗ об охране окружающей среды
ФЗ о полиции
ФЗ о бухгалтерском учете
ФЗ о защите конкуренции
ФЗ о лицензировании отдельных видов деятельности
ФЗ об ООО
ФЗ о закупках товаров, работ, услуг отдельными видами юридических лиц
ФЗ о прокуратуре
ФЗ о несостоятельности (банкротстве)
ФЗ о персональных данных
ФЗ о госзакупках
ФЗ об исполнительном производстве
ФЗ о воинской службе
ФЗ о банках и банковской деятельности
Уменьшение неустойки
Проценты по денежному обязательству
Ответственность за неисполнение денежного обязательства
Уклонение от исполнения административного наказания
Расторжение трудового договора по инициативе работодателя
Предоставление субсидий юридическим лицам, индивидуальным предпринимателям, физическим лицам
Управление транспортным средством водителем, находящимся в состоянии опьянения, передача управления транспортным средством лицу, находящемуся в состоянии опьянения
Особенности правового положения казенных учреждений
Общие основания прекращения трудового договора
Порядок рассмотрения сообщения о преступлении
Судебный порядок рассмотрения жалоб
Основания отказа в возбуждении уголовного дела или прекращения уголовного дела
Документы, прилагаемые к исковому заявлению
Изменение основания или предмета иска, изменение размера исковых требований, отказ от иска, признание иска, мировое соглашение
Форма и содержание искового заявления