Методические рекомендации по использованию Единой системы идентификации и аутентификации. Версия 2.86

Приложение___________
к протоколу заседания Подкомиссии
по использованию информационных технологий
при предоставлении государственных
и муниципальных услуг
Правительственной комиссии
по использованию информационных технологий
для улучшения качества жизни и условий ведения
предпринимательской деятельности
от __________________г. N__________

Единая система идентификации и аутентификации

Методические рекомендации по использованию Единой системы идентификации и аутентификации.
Версия 2.37

ГАРАНТ:

См. Регламент информационного взаимодействия Участников с Оператором ЕСИА и Оператором эксплуатации инфраструктуры электронного правительства

Таблица изменений

Версия	Дата	Автор	Изменение
1.0	-	-	Документ создан
2.0	-	-	Создана новая версия документа в рамках развития ЕСИА в 2013 г.
2.1	-	-	Внесены исправления в документ: - уточнено описание процедуры подписания запроса при аутентификации с помощью протокола SAML; - уточнено описание перечня SAML-атрибутов; - уточнено описание электронного сервиса по регистрации пользователей ЕСИА, опубликованного в СМЭВ (добавлено описание процедуры получения доступа к сервису, добавлены идентификаторы сервиса ЕСИА в СМЭВ, уточнено описание метода восстановления доступа); - уточнено описание областей доступа (scope), используемых программными интерфейсами на основе REST.
2.2	-	-	Исключено Приложение с описанием электронных сервисов ЕСИА для работы с должностными лицами ОГВ. Произведена перенумерация остальных приложений. Внесены уточнения и детализации в технические описания во всех приложениях
2.3	-	-	Детализация описания механизма аутентификации с использованием OpenID Connect 1.0
2.4	-	-	Добавлено описание программного интерфейса на основе REST по получению данных о филиалах и ОГВ. Уточнено описание программного интерфейса на основе REST по получению данных о системных группах. Изменено обозначение типов учетных записей. Добавлены ссылки на Технологический портал ЕСИА. Уточнено описание redirect_uri при использовании сервиса авторизации ЕСИА на основе OAuth 2.0. Уточнено описание сервиса получения данных о субъекте (Приложение Б.7). Уточнен формат адреса, используемый в REST-сервисе ЕСИА
2.4.1	-	-	Уточнен формат запроса на получение маркера доступа при реализации модели контроля доступа на основе полномочий системы-клиента. Уточнен процесс завершения активной сессии пользователя при использовании протокола SAML
2.5	-	-	Добавлено описание: - новых типов документов физических лиц, получаемых через REST API ЕСИА; - данных о детях, получаемых через REST API ЕСИА; - новых возможностей по использованию аутентификации с использованием OpenID Connect 1.0 (проверка аутентификации в фоновом режиме и открытие страницы аутентификации во всплывающем окне); - возможностей по управлению данными организации; - новых разрешений на доступ к данным (scope); - возможности возврата пользователя в систему, направившую пользователя в ЕСИА для выполнения операций.
2.6	-	-	Добавлено описание сервиса "Единый сервис упрощенной идентификации пользователей Единой системы идентификации и аутентификации"
2.7	-	-	Добавлено описание использования разрешения (scope) для передачи сведений о детях.
2.8	-	-	Добавлено описание использования разрешения (scope) "openid" для интеграции информационных систем
2.9	-	-	Добавлено в Таблицу 11 "Состав набора данных" пункт - место рождения, при вызове скоупа id_doc и foreign_passport_doc
2.10	-	-	Из Таблицы 11 исключен пункт место рождения. Добавлено описание сервиса УПРИД. Уточнена информация по сервису регистрации. Добавлен раздел Б.9 Предоставление списка измененных пользователей или организаций за период времени В таблице 6 добавлены параметры ответа на запрос о персональных данных пользователя: verifying и status.
2.11	-	-	К Таблице 11 в примечании добавлено описание scope, позволяющих получить Гражданство пользователя.
2.12	-	-	Уточнено описание структуры маркера идентификации (Приложение В.7).
2.13	-	-	В Таблице 11 добавлен скоуп "birthplace".
2.14	-	-	В Таблице 10 исправлены коды ошибок.
2.15	-	-	В Таблице 11 добавлен скоуп usr_org.
2.16	-	-	Добавлено описание полей "district" и "settlement" для атрибута orgAddresses (Таблица 5).
2.17	17.01.2017	Пригарина Д.А.	В Таблице 10 добавлен новый код ошибки при отсутствии разрешения на доступ к указанному скоупу. В таблице 6 добавлены параметры ответа на запрос о контактах пользователя: vrfValStu и verifyingValue.
2.18	31.01.2017	Пригарина Д.А.	Добавлен раздел с описанием метода импорта учетной записи пользователя (Приложение Б.9).
2.19	08.02.2017	Маслова Г.В.	В таблице 6 изменен параметр fiasCode ответа на запрос о сведениях об отдельной записи в перечне адресов физического лица.
2.20	09.03.2017	Пригарина Д.А.	Обновлен алгоритм импорта УЗ, пример ответа на запрос, обязательность полей адреса (Приложение Б.9).
2.21	10.04.2017	Пригарина Д.А.	Добавлено описание получения информации для скоупа usr_org (Приложение В.4). В Приложении Б.9 добавлено описание заголовков запроса (Request-Data, Request-Data Sign). Обновлено описание параметров series и number для документа, удостоверяющего личность.
2.22	02.05.2017	Горбунова О.Е.	В Приложение В.4 в перечень скоупов добавлен скоуп usr_avt. Добавлено описание получения информации для скоупа usr_avt (Приложение Б.10).
2.23	04.05.2017	Пригарина Д.А.	Добавлено описание ошибок для параметра errorStatusInfo (Приложение Б.9). Обновлено описание ответа для запроса: https://esia-portal1.test.gosuslugi.ru/rs/orgs/100000/emps?embed=(ele ments.person) (Приложение Б.1).
2.24	20.06.2017	Маслова Г.В.	Обновлен пример запроса (вызов сервиса в среде разработки) в Приложении Б.10 (добавлен параметр "birthplace".
2.25	03.07.2017	Пригарина Д.А.	В разделе 3.1.1 добавлена информация о прекращении поддержки SAML 2.0 в ЕСИА. В разделах Б.2, В.2.2, В.4, В.5 обновлены примеры, касающиеся скоупа id_doc. В разделах В.6.2.2, В.6.2.3 обновлены примеры запросов.
2.26	18.07.2017	Маслова Г.В.	Добавлена Таблица 10 с кодами ошибок от сервиса импорта. Для параметров запроса импорта актуализированы форматы данных и значение обязательности для отправки в запросе. В Приложениях Б8, B 3.2, B4 удалена информация о скоупе sbj_inf. Добавлено Приложение Д4 по устаревшим скоупам ЕСИА.
2.27	17.08.2017	Пригарина Д.А.	Обновлена обязательность следующих полей запроса метода импорта (Б.9): birthplace, series, number, issuedBy.
2.28	29.08.2017	Пригарина Д.А.	В описании метода импорта (Б.9) добавлен новый тип документа - FRGN_PASS (заграничный паспорт гражданина РФ), обновлено описание параметров запроса для документа, удостоверяющего личность. В Таблице 11 для параметра flowDetails в поле Name добавлено новое значение - raRegistrationEndorsement (подтверждение регистрации пользователем по СМС).
2.29	08.11.2017	Пригарина Д.А.	Обновлена обязательность поля middleName запроса метода импорта (Б.9).
2.30	19.12.2017	Маслова Г.В.	Обновлена обязательность поля middleName запроса метода импорта (Б.9).
2.31	26.12.2017	Жукова Д.А.	Добавлены новые параметры в ответе на запрос при получении данных организации (rs/orgs, Б.4). Добавлены новые параметры при ответе на запрос при получении списка организация пользователя (rs/prns/{prn_oid}/roles, В.4).
2.32	30.01.2018	Маслова Г.В.	Внесены уточнения в таблицу 8.
2.33	02.02.2018	Маслова Г.В.	Внесены изменения в раздел 3.5 "Возврат пользователя в систему, вызвавшую профиль пользователя в ЕСИА или регистрацию пользователя в ЕСИА".
2.34	09.02.2018	Маслова Г.В.	Исправлены опечатки.
2.35	01.03.2018	Цирихов А.М.	Внесены изменения в Приложение Б.9 Импорт учетной записи пользователя: - в таблице с описанием параметров запроса: обязательность параметра документа issuedBy - наименование подразделения, выдавшего паспорт -указана как Y/N (обязателен только для паспорта гражданина РФ); - в примере запроса импорта УЗ скорректировано содержимое элемента addresses; - скорректированы примеры ответов на запрос импорта УЗ; - Таблица 10 - Коды и описание ошибок от сервиса импорта: добавлены коды ESIA-030007, ESIA-032205, ESIA-039812, ESIA-039815, и их описания; - Таблица 11 - Параметры ответа на запрос о статусе проверки данных пользователя: в описание добавлен параметр personOid - идентификатор зарегистрированной учётной записи; - Таблица 11 - Параметры ответа на запрос о статусе проверки данных пользователя: в перечень возможных значений атрибута name параметра flowDetails добавлено значение "C" - операция отменена; - Скорретирован основной и добавлены дополнительные примеры ответов на запрос о статусе выполнения заявки.
2.36	07.03.2018	Жукова Д.А.	Добавлен раздел "Удаленная идентификация с использованием биометрической идентификации" (Приложение В.8).
2.37	12.03.2018	Маслова Г.В.	Исправлены опечатки.
2.37	13.03.2018	Цирихов А.М.	Выполнены доработки и внесены изменения в Приложение Б.9 Импорт учетной записи пользователя: - обновлена схема, представленная на рисунке 14 -Алгоритм импорта учетной записи в ЕСИА; - скорректирована таблица с параметрами ответа на запрос импорта УЗ в ЕСИА: - в примечаниях добавлено описание возможных значений возращаемого параметра code (Код завершения операции); - в примечаниях добавлено описание назначения возращаемого параметра description (Текстовое описание кода завершения операции); - в примечаниях добавлено описание назначения возращаемого параметра message (Текстовое описание кода ошибки выполнения операции); - Таблица 10 - Коды и описание ошибок от сервиса импорта: - скорректировано содержимое столбца с описанием кодов возврата для некоторых кодов ошибок; - добавлен код ошибки ESIA-910307 и его описание.

Список сокращений

Сокращение / термин	Наименование / определение
ЕГРИП	Единый государственный реестр индивидуальных предпринимателей
ЕГРЮЛ	Единый государственный реестр юридических лиц
ЕПГУ	Федеральная государственная информационная система "Единый портал государственных и муниципальных услуг (функций)"
ЕСИА	Федеральная государственная информационная система "Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме"
ИНН	Идентификационный номер налогоплательщика
ИС	Информационная система
КЭП	Усиленная квалифицированная электронная подпись
ОГВ	Орган государственной власти. Федеральные органы исполнительной власти, государственные внебюджетные фонды, органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональных центров предоставления государственных и муниципальных услуг, а также иные организации, определенные федеральными законами, актами Президента Российской Федерации и актами Правительства Российской Федерации
ОГРН	Основной государственный регистрационный номер
ОГРНИП	Основной государственный регистрационный номер индивидуального предпринимателя
Оператор выдачи ключа ПЭП	Орган или организация, обладающая правом создания (замены) ключа ПЭП в соответствии с постановлением Правительства РФ от 25 января 2013 г. N 33 "Об использовании простой электронной подписи при оказании государственных и муниципальных услуг". В соответствии с указанным постановлением Правительства, качестве Операторов выдачи ключа ПЭП могут выступать федеральные органы исполнительной власти, государственные внебюджетные фонды, органы исполнительной власти субъектов Российской Федерации, органы местного самоуправления, государственные и муниципальные учреждения, многофункциональные центры предоставления государственных и муниципальных услуг, а также иные организации, определенные федеральными законами, актами Президента Российской Федерации и актами Правительства Российской Федерации (а также уполномоченные ими организации), осуществляющие оказание государственных или муниципальных услуг и подключенные к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме
Оператор ЕСИА	Министерство связи и массовых коммуникаций Российской Федерации
Оператор ИС	Организация, осуществляющая регистрацию и управление ИС. В качестве операторов ИС, включенных в регистр информационных систем ЕСИА, могут быть организации, обеспечивающие решение следующих задач: - предоставление государственных и муниципальных услуг; - исполнение государственных и муниципальных функций; - формирование БГИР; - межведомственное электронное взаимодействие; - иные задачи, предусмотренные федеральными законами, актами Президента РФ и актами Правительства РФ.
Пользователь ЕСИА	Пользователь информационно-телекоммуникационной сети "Интернет", зарегистрированный в ЕСИА в качестве физического лица. Может иметь роли индивидуального предпринимателя, сотрудника юридического лица, должностного лица ОГВ
Поставщик услуг	ИС, интегрированная с ЕСИА и осуществляющая предоставление пользователям ЕСИА данных и услуг, в частности, государственных и муниципальных услуг в электронной форме
ПЭП	Простая электронная подпись
Регламент	Регламент взаимодействия участников информационного взаимодействия с оператором ЕСИА и оператором инфраструктуры электронного правительства при организации информационно-технологического взаимодействия информационных систем с использованием ЕСИА
СМЭВ	Федеральная государственная информационная система "Единая система межведомственного электронного взаимодействия"
СНИЛС	Страховой номер индивидуального лицевого счета застрахованного лица в системе персонифицированного учета Пенсионного фонда России
Специалист Центра обслуживания	Сотрудник Оператора выдачи ключа ПЭП, осуществляющий подтверждение личности пользователей ЕСИА
Технологический портал ЕСИА	Специализированное веб-Приложение, размещенное по адресу https://esia.gosuslugi.ru/console/tech. Предназначено, в частности, для управления ИС организаций
ФИО	Фамилия, имя, отчество
Центр обслуживания	Центр обслуживания органа или организации, имеющей право создания (замены) и выдачи ключа ПЭП. В Центре обслуживания специалистами Центра обслуживания осуществляется регистрация и/или подтверждение личности пользователей ЕСИА
ЮЛ	Юридическое лицо
OAuth	Открытый протокол авторизации
REST	Передача репрезентативного состояния (Representational State Transfer)
SAML	Security Assertion Markup Language
SMS	Служба коротких сообщений (Short Message Service)

1 Введение

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

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

Созданная Минкомсвязью России ФГИС ЕСИА:

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

- регистрация лица в ЕСИА сопряжена с проверкой значимых для удостоверения личности критериев;

- ЕСИА обеспечивает защиту размещённой в ней информации в соответствии с законодательством Российской Федерации.

2. Является ориентированной на пользователя - предоставляет ему возможности:

- идентификации и аутентификации с использованием единой учетной записи и широкого спектра поддерживаемых методов аутентификации при доступе к различным информационным системам органов государственной власти;

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

1.1 Назначение документа

Настоящий документ:

1. Описывает базовые сценарии использования ЕСИА:

- идентификация и аутентификация пользователей при доступе к информационным системам органов государственной власти (раздел 3);

- ведение идентификационных данных и полномочий пользователей (раздел 4);

- получения информационными системами органов государственной власти данных из регистров, хранимых в ЕСИА (раздел 4).

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

- регистр физических лиц;

- регистр юридических лиц и должностных лиц юридических лиц;

- регистр органов государственной власти и должностных лиц органов государственной власти;

- регистр информационных систем.

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

1.2 Нормативные ссылки

Настоящий документ разработан в целях реализации и во исполнение следующих нормативно-правовых актов:

- Федеральный закон от 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.

2 Общее описание ЕСИА

В соответствии с постановлением Правительства Российской Федерации от 28 ноября 2011 г. N 977 ЕСИА должна обеспечивать санкционированный доступ участников информационного взаимодействия (заявителей и должностных лиц ОГВ) к информации, содержащейся в государственных информационных системах, муниципальных информационных системах и иных информационных системах.

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

Основные функциональные возможности ЕСИА:

- идентификация и аутентификация пользователей, в том числе:

- однократная аутентификация ¹, которая дает пользователям ЕСИА следующее преимущество: пройдя процедуру идентификации и аутентификации в ЕСИА, пользователь может в течение одного сеанса работы обращаться к любым информационным системам, использующим ЕСИА, при этом повторная идентификация и аутентификация не требуется.

- поддержка различных методов аутентификации: по паролю, по электронной подписи, а также двухфакторная аутентификация (по постоянному паролю и одноразовому паролю, высылаемому в виде sms-сообщения);

- поддержка уровней достоверности идентификации пользователя (упрощенная учетная запись, стандартная учетная запись, подтвержденная учетная запись).

- ведение идентификационных данных ², а именно - ведение регистров физических, юридических лиц, органов и организаций, должностных лиц органов и организаций и информационных систем;

- авторизация уполномоченных лиц ОГВ при доступе к следующим функциям ЕСИА:

- ведение регистра должностных лиц ОГВ в ЕСИА;

- ведение справочника полномочий в отношении ИС и предоставление пользователям ЕСИА (зарегистрированным в ЕСИА как должностные лица ОГВ) полномочий по доступу к ресурсам ИС, зарегистрированным ЕСИА;

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

- ведение и предоставление информации о полномочиях пользователей в отношении информационных систем, зарегистрированных в ЕСИА.

Обращение участников информационного взаимодействия к ЕСИА должно происходить только по протоколу HTTPS (использовать протокол HTTP запрещено).

3 Аутентификация пользователей через ЕСИА

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

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

- физические лица, имеющие учетную запись в регистре физических лиц ЕСИА;

- индивидуальные предприниматели, т.е. физические лица имеющие признак индивидуального предпринимателя;

- должностные лица юридических лиц, т.е. физические лица, присоединенные к учетным записям юридических лиц ЕСИА;

- должностные лица органов и организаций, т.е. физические лица, присоединенные к учетным записям ОГВ.

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

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

- механизм, основанный на стандарте SAML версии 2.0;

- механизм, основанный на модели OpenID Connect 1.0.

Аутентификация с использованием стандарта SAML

ЕСИА использует стандарт SAML версии 2.0, который был разработан в 2005 году концерном OASIS. SAML базируется на языке XML и определяет способы обмена информацией об аутентификации пользователей, их полномочиях и идентификационных данных. В соответствии с принятой в этом стандарте терминологией, ЕСИА выступает в роли доверенного поставщика идентификации (Identity Provider), а система выступает в роли поставщика услуг (Service Provider) ³.

Общая схема подключения системы к ЕСИА представлена на рисунке ниже.

Рисунок 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 Как обеспечить вход пользователей через ЕСИА

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

- Регистрацию ИС в регистре информационных систем ЕСИА (в соответствии с Регламентом ⁴).

- Регистрацию системы с целью идентификации и аутентификации в тестовой среде в соответствии с Регламентом ⁵. Исполнение этого процесса предоставляет возможность участнику производить взаимодействие с ЕСИА в тестовой среде.

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

- Подключение продуктивной версии интегрируемой системы к продуктивной среде ЕСИА в соответствии с Регламентом ⁶.

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

3.1.1 Аутентификация с использованием стандарта SAML ⁷

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

1 и 2 шаг: Регистрация ИС

Регистрация ИС осуществляется согласно Регламенту (раздел 6).

3 шаг: Доработать систему

Рекомендуемая последовательность действий:

1. Сформулировать функциональные требования к взаимодействию своей системы с ЕСИА.

Для этого следует:

- изучить рекомендуемые сценарии использования и выбрать нужные;

- определить перечень сведений о пользователе, которые вашей ИС требуется получать из ЕСИА в утверждениях SAML;

- определить требования к уровню достоверности идентификации пользователя (см. п. 4.1.1).

2. Представить или самостоятельно сгенерировать (например, с помощью утилиты keytool из состава Java Development Kit) для своей системы сертификат ключа неквалифицированной электронной подписи в формате X.509 версии 3. Сертификат требуется для идентификации ИС при взаимодействии с ЕСИА. Допускается использование самоподписанного сертификата. Специальные требования: алгоритм RSA, длина ключа 2048 бит. Более подробную информацию о сертификате X.509 можно посмотреть по ссылке http://tools.ietf.org/html/rfc5280.

3. Реализовать интерфейсы поставщика услуг 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 приложения А).

4. Доработать дизайн сайта, выбрав место для размещения кнопки "Войти через ЕСИА" и реализовать в системе логику обработки данных о пользователях, получаемых из ЕСИА. Недопустимо отображать страницу аутентификации ЕСИА во фрейме сайта.

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

6. Загрузить актуальные метаданные поставщика идентификации ЕСИА:

- метаданные тестового поставщика идентификации ЕСИА опубликованы по ссылке https://esia-portal1.test.gosuslugi.ru/idp/shibboleth ⁸;

- метаданные промышленного поставщика идентификации ЕСИА опубликованы по ссылке https://esia.gosuslugi.ru/idp/shibboleth.

7. Подготовить метаданные интегрируемой системы (поставщика услуг). Чтобы подготовить их правильно, рекомендуется использовать следующие исходные данные:

- описание файла метаданных (п. А.5 приложения А);

- шаблон файла метаданных (п. А.6 приложения А);

- требования вашей системы к типу учетной записи:

- тип роли пользователя (физическое лицо, индивидуальный предприниматель, представителя юридического лица, должностное лицо государственной организации) - блок SupportedGlobalRoles и метаданных;

- допустимый метод аутентификации (по паролю, по КЭП, усиленная аутентификация) - блок SupportedGlobalRoles метаданных;

- допустимый уровень (статус) учетной записи (подтверждена или упрощенная/стандартная учетная запись) - блок SupportedAccTypes метаданных.

- требования вашей системы к перечню сведений о пользователе, которые нужно получать из ЕСИА в утверждениях SAML;

- сертификат ключа электронной подписи.

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

9. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом ⁹.

4 шаг: Ввести доработку в эксплуатацию

1. Осуществить регистрацию метаданных в промышленной ЕСИА в соответствии с Регламентом ¹⁰.

2. После регистрации метаданных проверить работу промышленной версии ЕСИА с промышленной версией вашей системы.

3.1.2 Аутентификация с использованием OpenID Connect 1.0

1 и 2 шаг: Регистрация ИС

Регистрация ИС осуществляется согласно Регламенту (раздел 6).

При использовании способа аутентификации, основанного на OAuth 2.0 и расширения OpenID Connect, не требуется формирование метаданных.

3 шаг: Доработать систему

Рекомендуемая последовательность действий:

1. Выпустить ключевой контейнер и сертификат ключа квалифицированной электронной подписи для подключаемой информационной системы (должен содержать ОГРН ЮЛ, являющегося оператором информационной системы).

Дополнительно поддерживается работа с ключевым контейнером и сертификатом ключа неквалифицированной электронной подписи в формате X.509 версии 3. В этом случае является допустимым самостоятельно сгенерировать (например, с помощью утилиты keytool из состава Java Development Kit) для своей системы ключевой контейнер и самоподписанный сертификат. Сертификат требуется для идентификации ИС при взаимодействии с ЕСИА. ЕСИА поддерживает алгоритмы формирования электронной подписи RSA с длиной ключа 2048 бит и алгоритмом криптографического хэширования SHA-256, а также алгоритм электронной подписи ГОСТ Р 34.10-2001 и алгоритм криптографического хэширования ГОСТ Р 34.11-94.

2. Реализовать интерфейсы системы-клиента REST-сервисов ЕСИА и модели контроля доступа, основанной на OAuth 2.0. Детальная информация содержится в приложениях Б и В.

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

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

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

6. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом ¹¹.

4 шаг: Ввести доработку в эксплуатацию

1. Осуществить подключение ИС к промышленной ЕСИА в соответствии с Регламентом ¹².

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)	"Для доступа вам необходимо использовать средство квалифицированной электронной подписи. Если у вас имеется средство электронной подписи, войдите заново, использовав это средство." После этого сообщения рекомендуется разместить кнопку вызова единого завершения сессии

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

3.2.2 Сценарий единого завершения сессии

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

Единое завершение сессии выполняется в соответствии с профилем Single Logout стандарта SAML. Процесс инициируется пользователем при нажатии кнопки "Выход" в системе поставщика услуг, реализовавшего указанный сценарий. Информационная система не должна самостоятельно инициировать единое завершение сессии.

Сценарий включает следующие шаги:

1. Пользователь нажимает кнопку "Выход" в системе.

2. Система формирует и направляет в ЕСИА запрос на завершение сессии - <LogoutRequest>.

3. ЕСИА определяет остальных участников сессии. Остальные участники сессии - это все системы, в которые пользователь вошёл через ЕСИА на протяжении текущей сессии. Если другие участники существуют, ЕСИА отправляет запрос <LogoutRequest> каждому из них.

4. Система, получившая <LogoutRequest>, завершает на своей стороне активную сессию пользователя (или проверяет, что сессия к этому моменту уже неактивна). Затем формирует и отправляет в ЕСИА ответ о том, что сессия завершена - <LogoutResponse>.

5. Когда все остальные участники корректно завершили свои сессии, ЕСИА формирует и отправляет ответ <LogoutResponse> системе, инициировавшей процедуру завершения сессии. Если какой-то из поставщиков услуг не смог завершить сессию, ЕСИА отображает пользователю веб-страницу, информирующую его о том, что процедура не может быть корректно завершена и что пользователю необходимо перезапустить браузер.

6. Система, инициировавшая процедуру завершения сессии, обрабатывает полученный от ЕСИА ответ. Например, перенаправляет пользователя на веб-страницу завершения сессии.

3.2.3 Форматы сообщений

Основные используемые в ЕСИА форматы электронных сообщений 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, то имеется возможность проверить наличие у пользователя сессии в ЕСИА в фоновом режиме. Иными словами, кнопку "Вход" можно выводить только в том случае, если пользователь не имеет сессии, а если имеет - то произвести вход в систему автоматически ¹⁵.

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 системы, указанный в Технологическом портале).

Пример ссылки с корректным контекстом возврата:

Следует помнить, что после закрытия пользователем браузера контекст возврата не будет сохранен.

4 Ведение регистров ЕСИА

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

Таблица 3 - Основные механизмы ведения регистров ЕСИА

Процесс	Регистр	Механизм	Ссылка на раздел документа
Регистрация	Регистр физических лиц	Веб-интерфейс	4.1.1
		Программный интерфейс, доступный через СМЭВ	Приложение Г
	Регистр юридических лиц	Веб-интерфейс	4.1.2
	Регистр ОГВ	Веб-интерфейс	4.1.3
	Регистр ИС	Веб-интерфейс	4.1.4, 4.1.5
Управление данными	Регистр физических лиц	Веб-интерфейс	4.2.1
	Регистр юридических лиц	Веб-интерфейс	4.2.2
		Программный интерфейс на основе REST	Приложение Б
	Регистр ОГВ	Веб-интерфейс	4.2.3
		Программный интерфейс на основе REST	Приложение Б
	Регистр ИС	Веб-интерфейс	4.2.4
Получение данных	Регистр физических лиц	Программный интерфейс на основе SAML	4.3, Приложение А
		Программный интерфейс на основе REST	4.3, Приложение Б
	Регистр юридических лиц	Программный интерфейс на основе SAML	4.3, Приложение А
		Программный интерфейс на основе REST	4.3, Приложение Б
	Регистр ОГВ	Программный интерфейс на основе SAML	4.3, Приложение А
	Регистр ИС	Программный интерфейс на основе REST	4.3, Приложение Б

4.1 Регистрация

4.1.1 Регистрация физических лиц и получение ролей

В ЕСИА предусмотрены следующие роли пользователей:

- физические лица, имеющие учетную запись в регистре физических лиц ЕСИА;

- индивидуальные предприниматели, т.е. физические лица имеющие признак индивидуального предпринимателя;

- должностные лица юридических лиц, т.е. физические лица, присоединенные в ЕСИА к учетным записям юридических лиц ЕСИА;

- должностные лица органов и организаций, т.е. физические лица, присоединенные в ЕСИА к учетным записям ОГВ.

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

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

В ЕСИА предусмотрены учетные записи физических лиц следующих типов, каждый из которых соответствует определенному уровню идентификации пользователя:

- упрощенная (непроверенная) учетная запись (содержит минимальный набор данных о пользователе);

- стандартная (проверенная) учетная запись (данные о пользователе проверены в БГИР);

- подтвержденная учетная запись (данные о пользователе проверены в БГИР, а личность пользователя-физического лица подтверждена одним из доступных способов подтверждения).

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

Рисунок 5 - Типы учетных записей и роли пользователя в ЕСИА

4.1.1.1 Регистрация учетной записи физического лица

Регистрация учетной записи физического лица возможна следующими способами:

1. Самостоятельная регистрация пользователя через веб-интерфейс. В этом случае пользователю самостоятельно нужно пройти следующие шаги:

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

- перевод учетной записи в состояние стандартной (проверенной) (включает в себя заполнение пользователем личных данных, инициирование процедуры проверки личных данных в БГИР и автоматическую верификацию личных данных в БГИР).

- перевод учетной записи в состояние подтвержденной (включает в себя подтверждение личности пользователя одним из доступных способов подтверждения - с помощью обращения в один из Центров обслуживания ¹⁶, отправкой кода подтверждения личности по почте или с помощью КЭП).

2. Регистрация пользователя в одном из Центров обслуживания, ИС которого осуществляет вызов операций с использованием программного интерфейса ЕСИА, опубликованного в СМЭВ. Детальная информация о программном интерфейсе ЕСИА размещена в приложении Г. В результате регистрации в Центре обслуживания пользователь сразу получает подтвержденную учетную запись ЕСИА.

4.1.1.2 Назначение ролей

Назначение всех ролей физического лица в ЕСИА осуществляется с помощью веб-интерфейса ¹⁷.

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

Таблица 4 - Способы назначения ролей

Роль	Способ назначения роли
Индивидуальный предприниматель	Самостоятельно через веб-интерфейс ЕСИА с помощью направления заявки с данными ИП, включающей в себя: - ФИО; - ИНН физического лица; - ОГРНИП. Заявка проходит проверку в БГИР. Если в ЕГРИП действительно существует запись с указанными данным, то пользователь получает роль индивидуального предпринимателя
Должностное лицо юридического лица	Получение роли должностного лица ЮЛ в ЕСИА происходит в результате: - регистрации ЮЛ в ЕСИА, в этом случае регистрирующий ЮЛ пользователь получает роль должностного лица ЮЛ с правами руководителя (см. п. 4.1.2); - приглашения руководителем или администратором профиля ЮЛ в ЕСИА сотрудника. Процедура приглашения сотрудника для присоединения к организации выполняется с помощью веб-интерфейса ЕСИА 18. Включает в себя следующие шаги: 1. Руководитель или администратор учетной записи ЮЛ в ЕСИА формирует с помощью веб-интерфейса ЕСИА приглашение на присоединение к организации, включающее в себя: - адрес электронной почты пользователя; - ФИО пользователя; - СНИЛС пользователя (опционально). 2. ЕСИА отправляет на указанный адрес электронной почты пользователя приглашение со ссылкой для присоединения к организации. 3. Пользователь, имеющий подтвержденную учетную запись, входит в ЕСИА по ссылке в приглашении. Если его ФИО и СНИЛС совпадает с данными в приглашении, то он присоединяется к учетной записи ЮЛ. Физическое лицо получает роль должностного лица ЮЛ.
Должностное лицо ОГВ	Получение роли должностного лица ОГВ в ЕСИА происходит в результате: - регистрации ОГВ в ЕСИА, в этом случае регистрирующий ОГВ пользователь получает роль должностного лица ОГВ с правами руководителя (см. п. 4.1.3); - приглашения руководителем или администратором профиля ОГВ в ЕСИА сотрудника. Процедура приглашения сотрудника для присоединения к ОГВ выполняется с помощью веб-интерфейса ЕСИА 19 и аналогична процессу присоединения сотрудника к учетной записи ЮЛ

Один пользователь ЕСИА может одновременно являться должностным лицом в нескольких ОГВ и ЮЛ, а также иметь роль одного индивидуального предпринимателя.

4.1.2 Регистрация юридических лиц

Регистрация ЮЛ (внесение записи в регистр ЮЛ) осуществляется с помощью веб-интерфейса ЕСИА. Создавать учетную запись ЮЛ можно только из подтвержденной учетной записи физического лица - руководителя организации или представителя юридического лица, имеющего право действовать от имени организации без доверенности.

Процедура регистрации ЮЛ из подтвержденной учетной записи пользователя включает в себя следующие шаги:

1. Переход во вкладку "Организации" профиля пользователя и инициирование процедуры регистрации.

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

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

- организационно-правовую форму;

- адрес электронной почты организации.

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

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

4.1.3 Регистрация ОГВ

В регистр органов и организаций ЕСИА могут быть включены только организации, подпадающие под действие Постановления Правительства Российской Федерации от 28 ноября 2011 г. N 977.

Регистрация ОГВ осуществляется с помощью единого веб-интерфейса ЕСИА, предусмотренного и для ЮЛ. Специфика заключается в том, что руководитель ОГВ при регистрации в качестве типа своей организации указывает "Государственный орган или организация", указывает свою территориальную принадлежность и выбирает своё ведомство, подтверждающее статус регистрирующейся организации как ОГВ.

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

4.1.4 Регистрация информационных систем

Регистрация ИС выполняется организацией, являющейся оператором данной ИС. Эта организация предварительно должна быть зарегистрирована в ЕСИА.

В ЕСИА должны быть зарегистрированы ИС, которые:

- используют ЕСИА как поставщик идентификации (Identity Provider) для идентификации и аутентификации пользователей;

- используют ЕСИА в качестве поставщика ресурса (для интеграции по REST и OAuth 2.0);

- осуществляют регистрацию пользователей в ЕСИА.

Для регистрации ИС можно воспользоваться функцией Технологического портала ЕСИА ²⁰.

4.1.5 Регистрация системных групп

Для систем, интегрированных с ЕСИА, имеется возможность проверять наличие у пользователей специфических полномочий по доступу к этой системе. Данная возможность обеспечивается в ЕСИА посредством механизма системных групп (групп доступа) - для проведения авторизации сотрудников организаций (ЮЛ или ОГВ). Оператор ИС может зарегистрировать одну или несколько системных групп, которые будут доступны организации; уполномоченные сотрудники организаций смогут включать/исключать своих сотрудников с помощью веб-интерфейса ЕСИА (см. п. 4.2.2.3). После аутентификации данные о принадлежности сотрудника организации к системным группам данной ИС будут переданы в SAML-утверждениях, а также доступны с помощью программного интерфейса, основанного на архитектуре REST.

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

В ЕСИА предусмотрены следующие типы групп доступа:

- публичная - доступная для назначения всем организациям. Уполномоченный сотрудник организации (не являющейся владельцем группы) всегда может включать в эту группу сотрудников своей организации;

- ограниченно доступная (приватная) группа для ОГВ - доступная всем организациям, имеющим признак ОГВ;

- ограниченно доступная (приватная) - доступная организациям только с разрешения владельца системной группы. Уполномоченный сотрудник организации может включать в эту группу сотрудников своей организации только после получения организацией прав доступа со стороны организации-владельца системной группы.

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

- с возможностью свободного включения в группу сотрудников;

- с включением в группу сотрудников только с персональным согласованием этого включения со стороны организации-владельца этой группы. В этом случае добавление сотрудника в группу с помощью веб-интерфейса или программного интерфейса влечет за собой направление запроса в учетную запись организации-владельца группы для его рассмотрения; только после согласования запроса со стороны организации-владельца сотрудник будет добавлен в группу.

4.2 Управление данными

4.2.1 Управление данными физических лиц

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

https://esia-portal1.test.gosuslugi.ru/profile/user/

К персональным данным, размещенным в ЕСИА, относятся:

- основная информация:

- фамилия, имя, отчество;

- пол;

- дата рождения;

- реквизиты удостоверяющего личность документа (только для стандартной (проверенной) и подтвержденной учетной записи);

- гражданство (только для стандартной (проверенной) и подтвержденной учетной записи).

- идентификаторы:

- СНИЛС (только для стандартной (проверенной) и подтвержденной учетной записи);

- ИНН (только для подтвержденной учетной записи).

- документы:

- водительское удостоверение;

- свидетельство о рождении;

- полис ОМС;

- заграничный паспорт;

- военный билет.

- данные о детях;

- контактная информация:

- адрес электронной почты;

- мобильный телефон;

- домашний телефон

- почтовый адрес;

- адрес регистрации.

- транспортные средства:

- государственный регистрационный знак транспортного средства и реквизиты свидетельства о регистрации транспортного средства.

Процедура редактирования ряда полей различается в зависимости от того, является ли учетная запись пользователя упрощенной (непроверенной), стандартной (проверенной) или подтвержденной. Для стандартной (проверенной) и подтвержденной учетной записи изменение ряда полей возможно только после проверки этих данных в БГИР. До тех пор, пока данные не будут подтверждены, изменение данных не произойдет.

4.2.2 Управление данными юридических лиц

Управление данными ЮЛ осуществляется самостоятельно руководителем или администратором профиля ЮЛ с помощью веб-интерфейса ЕСИА²¹. Доступны следующие функции:

- управление идентификационными данными ЮЛ;

- управление сотрудниками ЮЛ;

- управление филиалами ЮЛ;

- управление принадлежностью сотрудников к системным группам (группам доступа).

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

4.2.2.1 Управление идентификационными данными ЮЛ

Уполномоченный сотрудник имеет возможность редактировать следующие данные ЮЛ:

- организационно-правовая форма;

- адрес электронной почты;

- почтовый адрес;

- телефон организации;

- факс организации.

4.2.2.2 Управление сотрудниками ЮЛ

Уполномоченный сотрудник с помощью веб-интерфейса ЕСИА имеет возможность просмотреть перечень сотрудников, т.е. пользователей, присоединенных к организации. Также он имеет возможность:

- отредактировать следующие данные сотрудника:

- служебный адрес электронной почты;

- служебный номер телефона;

- должность.

- отправить приглашение пользователю для его присоединения к организации (см. п. 4.1.1.2), а также исключить сотрудника из организации. При исключении сотрудника ЕСИА удаляет пользователя из всех системных групп и исключает сотрудника из ЮЛ, при этом учетная запись сотрудника не удаляется из регистра физических лиц ²².

4.2.2.3 Управление принадлежностью сотрудников к системным группам

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

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

Общая схема взаимодействия выглядит следующим образом:

1. ОГВ регистрирует в ЕСИА информационную систему (ИС-1), доступ которой должны получать представители организаций, зарегистрированных в ЕСИА. При регистрации ИС-1 данный ОГВ определяет название соответствующей системной группы (см. п. 4.1.4), например "группа 1".

2. Уполномоченный сотрудник организации использует веб-интерфейс ЕСИА для просмотра существующих групп доступа. Находит группы доступа, связанные с системой ИС-1, и видит, что в этом перечне появилась "группа-1" ²⁴.

3. Уполномоченный сотрудник ЮЛ добавляет в "группу-1" сотрудников организации, которым он разрешает действовать в ИС-1 от имени ЮЛ.

4. Сотрудник ЮЛ, включенный в системную группу "группа-1", аутентифицируется с помощью ЕСИА в ИС-1.

5. ИС-1 получает среди SAML-утверждений информацию о том, что пользователь включен в "группу-1" (для этого анализирует утверждение memberOfGroups - см. п. А.5 приложения А), и принимает положительное решение о доступе пользователя к своим ресурсам.

6. Если другая интегрированная с ЕСИА ИС-2 при аутентификации обрабатывает SAML-утверждение о принадлежности пользователя к группам, то она не увидит информацию о "группе-1", потому что данная ИС-2 не является владельцем этой группы.

4.2.2.4 Управление филиалами ЮЛ

Уполномоченный сотрудник с помощью веб-интерфейса ЕСИА имеет возможность просмотреть перечень филиалов организации, зарегистрировать новый филиал, а также:

- изменить данные филиала;

- управлять сотрудниками филиала и их данными;

- управлять принадлежностью сотрудников филиала к группам.

Указанные операции с филиалами аналогичны соответствующим операциям с учетными записями организаций.

4.2.3 Управление данными ОГВ

Управление данными ОГВ осуществляется по аналогии с управлением обычными организации-юридическими лицами, т.е. с помощью веб-интерфейса ЕСИА.

Управление данными ОГВ включает в себя:

- управление должностными лицами ОГВ;

- управление полномочиями должностных лиц ОГВ;

- управление филиалами ОГВ.

4.2.3.1 Управление должностными лицами ОГВ

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

4.2.3.2 Управление полномочиями должностных лиц ОГВ

Полномочия должностного лица регулируются при помощи механизма системных групп. Выполняется по аналогии с тем, как это реализуется у юридических лиц, не имеющих признака ОГВ (см. п. 4.2.2.3).

4.2.3.3 Управление филиалами ОГВ

Управление филиалами ОГВ выполняется по аналогии с тем, как это реализуется у юридических лиц, не имеющих признака ОГВ (см. п. 4.2.2.4).

4.2.4 Управление данными ИС

Изменение данных ИС осуществляется в соответствии с Регламентом. Уполномоченный сотрудник оператора ИС имеет также возможность с помощью веб-приложения "Технологический портал ЕСИА" осуществлять следующие действия:

- загружать и удалять сертификаты ИС;

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

4.3 Получение данных

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

1. Программный интерфейс на основе SAML 2.0. ИС, интегрированная с ЕСИА, получает данные пользователя на момент его аутентификации в ЕСИА. Детальная информация об использовании этого программного интерфейса представлена в приложении А.

2. Программный интерфейс на базе архитектурного стиля "Representational State Transfer" (REST). Он позволяет интегрированным с ЕСИА информационным системам получать доступ к хранящимся в ЕСИА данным в произвольный момент времени после предварительного получения разрешения от пользователя ²⁵. Обеспечивается доступ к следующим данным:

- данные о пользователе (идентификационные данные, данные о транспортных средствах, данные о вхождении в организации);

- данные об организациях (идентификационные данные, данные о сотрудниках);

- данные об информационных системах (идентификационные данные, данные об организации-владельце).

Детальная информация об использовании этого программного интерфейса представлена в Приложениях Б и В ²⁶.

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-сервиса ЕСИА. Необходимость получать данные об ИС должна быть указана в Заявке на создание записи регистра информационных систем в ЕСИА (среди целей подключения ИС в ЕСИА) ²⁷.

------------------------------

¹ Соответствующий термин на английском языке - Single Sign On

² Соответствующий термин на английском языке - Identity Management

³ Подробное описание схемы интеграции посредством SAML 2.0 представлено в приложении А.

⁴Раздел 6 Регламента.

⁵Раздел 9 Регламента.

⁶Раздел 10 Регламента.

⁷ Внимание! В связи с прекращением поддержки SAML 2.0 в ЕСИА подключение ИС к ЕСИА через этот интерфейс будет прекращено с 01.01.2018 г., поэтому для подключения рекомендуется использовать протокол OAuth 2.0 / OpenID Connect. Запрещено подключение по протоколу SAML 2.0 и по протоколу OAuth 2.0 / OpenID Connect одновременно. Возможность изменения параметров подключения к ЕСИА через интерфейс SAML 2.0 для ранее подключенных ИС будет сохранена.

⁸ Здесь и далее esia-portal1 в ссылке - имя тестового домена в зависимости от тестовой среды. Конкретную тестовую среду для регистрации устанавливает оператор эксплуатации при обработке заявки на регистрацию.

⁹Раздел 9 Регламента.

¹⁰Раздел 10 Регламента.

¹¹Раздел 9 Регламента.

¹²Раздел 10 Регламента.

¹³ Если информационная система работает исключительно с учетными записями юридических лиц / государственных организаций, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, имеющие такую учетную запись (см. Приложение А.6). В этом случае если пользователь, присоединенный к организации, ранее аутентифицировался в ЕСИА как физическое лицо, но перешел в эту ИС, то ЕСИА обеспечит автоматическое переключение его роли на роль юридического лица (если требуется - попросит пользователя выбрать организацию, от которой ему требуется работать).

¹⁴ Если информационная система требует исключительно аутентификации по электронной подписи, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, аутентифицированные таким образом (см. Приложение А.6). В этом случае ЕСИА самостоятельно обеспечит корректное информирование пользователя о необходимых шагах по получению доступа.

¹⁵ См. Приложение В.6.2.2.

¹⁶ Для подтверждения личности Центры обслуживания могут использовать соответствующий программный интерфейс ЕСИА (см. п. Г.3 приложения Г).

¹⁷ Инициирование приглашения на присоединение пользователя к юридическому лицу или ОГВ возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.

¹⁸ Инициирование приглашения на присоединение пользователя к юридическому лицу возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.

¹⁹ Инициирование приглашения на присоединение пользователя к ОГВ возможно с помощью программного интерфейса ЕСИА. Детальная информация - в Приложении Б.7.

²⁰Раздел 6 Регламента.

²¹ Также возможно управление данными организации с помощью программного интерфейса на основе REST (см. Приложение Б).

²² Бывший сотрудник ЮЛ может продолжать использовать свою учетную запись ЕСИА, например, для получения государственных услуг в электронном виде.

²³ Если соответствующими информационными системами предусмотрены группы доступа (системные группы), см. п. 4.1.5.

²⁴ Если это публичная группа или ограниченно доступная группа, доступ к которой предоставлен данной организации.

²⁵ За исключением получения данных об ИС (см. п. Б.7 приложения Б и п. В.3 приложения В.

²⁶ Порядок подключения к ЕСИА с целью использования программных интерфейсов описан в п. 9-10 Регламента.

²⁷ См. раздел 6 Регламента.

²⁸ В целях обеспечения совместимости системы, получавшие ранее полномочия юридических лиц в утверждении systemAuthority, продолжат получать эти данные в этом утверждении. Однако дальнейшее развитие функционала полномочий будет происходить в терминологии групп доступа, в связи с чем этим системам рекомендуется отказаться от использования systemAuthority и анализировать утверждения memberOfGroups. При регистрации в ЕСИА новых ИС, ориентированных на работу с ЮЛ, они будут иметь возможность зарегистрировать только системные группы. Данные о них будут передаваться в утверждении memberOfGroups.

²⁹ В тестовой среде сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/prns

³⁰ Например, fullname, contacts, email (см. Приложение В.4). Все эти scope также позволяют получить данные о признаке подтвержденности учетной записи пользователя (атрибут <trusted>). При запросе у сервиса авторизации ЕСИА маркера доступа на указанные scope не нужно в качестве параметра указывать oid этого пользователя.

³¹ Для просмотра полных данных о ребенка с его документами можно использовать режим встраивания (embed). В этих целях необходимо сделать запрос методом GET по следующему адресу: /prns/{oid}/kids/{kid_id}?embed=(documents.elements)

³² Запрошенный ресурс: /prns/100000/vhls?embed=(elements)

³³ В тестовой среде сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/orgs

³⁴ В настоящее время используются следующие коды:

10.FED - Федеральный орган исполнительной власти;

30.FND - Государственный внебюджетный фонд;

11.REG - Орган исполнительной власти субъекта РФ;

12.LCL - Орган местного самоуправления;

20.GOV - Государственное учреждение;

21.MCL - Муниципальное учреждение.

³⁵ Запрос ресурса: /orgs/100000/addrs?embed=(elements)

³⁶ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs

³⁷ Запрос ресурса: /orgs/100000/emps?embed=(elements.person)

³⁸ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs

³⁹ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}

⁴⁰ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/ctts

⁴¹ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/ctts/{ctt_id}

⁴² Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/ctts/{ctt_id}

⁴³ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/addrs

⁴⁴ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/addrs/{addr_id}

⁴⁵ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/vhls

⁴⁶ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/vhls/{vhl_id}

⁴⁷ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/vhls/{vhl_id}

⁴⁸ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/invts

⁴⁹ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/invts

⁵⁰ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/invts/{invt_id}

⁵¹ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/emps/{emp_id}

⁵² Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/emps/{emp_id}

⁵³ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/grps/{grp_id}/pe rms

⁵⁴ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/grps/{grp_id}/pe rms

⁵⁵ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/brhs

⁵⁶ Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs/{org_oid}/brhs/{brh_id}

⁵⁷ В среде разработки сервис доступен по URL https://esia-portal1.test.gosuslugi.ru/rs/reqs/{requestId}, где requestId - уникальный идентификатор заявки на проверку данных пользователя.

⁵⁸ Сервис доступен по URL https:// esia-portal1.test.gosulsugi.ru /esia-rs/api/public/{version}/pso/{prn_oid}/avt/circle

⁵⁹ Сервис доступен по URL https:// esia-portal1.test.gosulsugi.ru /esia-rs/api/public/{version}/pso/{prn_oid}/avt/circle

⁶⁰ Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac

⁶¹ Либо один или несколько scope, обеспечивающих доступ к персональным данным пользователя.

⁶² Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te

⁶³ Подробнее см. в: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-02#appendix -B

⁶⁴ См.: http://tools.ietf.org/html/draft-jones-json-web-token-10#section-8

⁶⁵ Подробнее см.: 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

⁶⁶ Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/ac

⁶⁷ Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te

⁶⁸ SID данного сервиса в тестовой среде СМЭВ - SID0003419, в продуктивной - SID0003923.

⁶⁹ Порядок создания записи регистра органов и организаций, имеющих право создания (замены) и выдачи ключа простой электронной подписи (Операторов выдачи ключа ПЭП), определен в п. 12 Реглмента.

⁷⁰ Детальная информация о работе сервиса и получении к нему доступа содержится в Руководстве пользователя электронного сервиса СМЭВ "Сервис регистрации Единой системы идентификации и аутентификации".

⁷¹ Указание одного типа контакта необходимо для случая, когда имеется несколько заявок на подтверждение личности с идентичными данными документа, удостоверяющего личность.

⁷² Необходимость выполнения проверок данных пользователя связана с тем, что его идентификационные данные (ФИО, данные документа, удостоверяющего личность) могли измениться к моменту восстановления доступа. В этом случае пользователь сохраняет возможность восстановления доступа к своей учетной записи.

⁷³ Необходимость выполнения проверок данных пользователя связана с тем, что его идентификационные данные (ФИО, данные документа, удостоверяющего личность) могли измениться к моменту удаления учетной записи. В этом случае пользователь сохраняет возможность удалить свою учетную запись.

⁷⁴ Порядок регистрации Центров обслуживания Операторов выдачи ключа ПЭП определен в п. 14 Регламента.

⁷⁵ SID данного сервиса в тестовой среде СМЭВ - SID0004152, в продуктивной - SID0004769.