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

Есиа в госуслугах – что это такое и для чего он нужен?

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

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

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

— Федеральный закон от 6 апреля 2022 г. № 63-ФЗ «Об электронной подписи».

— Государственная программа Российской Федерации «Информационное общество (2022 — 2020 годы)», утвержденная распоряжением Правительства Российской Федерации от 20 октября 2022 г. № 1815-р.

— Постановление Правительства Российской Федерации от 28 ноября 2022 г. № 977 «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».

— Постановление Правительства Российской Федерации от 9 февраля 2022 г. № 111 «Об электронной подписи, используемой органами исполнительной власти и органами местного самоуправления при организации электронного взаимодействия между собой, о порядке её использования, а также об установлении требований к обеспечению совместимости средств электронной подписи».

— Постановление Правительства Российской Федерации от 25 января 2022 г. № 33 «Об использовании простой электронной подписи при оказании государственных и муниципальных услуг».

— Постановление Правительства Российской Федерации от 10 июля 2022 г. № 584 «Об ис пользовании федеральной государственной информационной системы «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме».

— Положение «Об инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», утверждённое постановлением Правительства Российской Федерации от 8 июня 2022 г. № 451.

— Положение «О федеральной государственной информационной системе «Единая система идентификации и аутентификации в инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме», утверждённое приказом Минкомсвязи России от 13 апреля 2022 г. № 107.

А.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 (протокол единого выхода) — определяет механизм одновременного завершения активных сессий, ассоциированных с аутентифицированным субъектом. Выход может инициироваться пользователем или поставщиком идентификации.

Б.7.5 управление доступом к непубличным группам

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

Пусть организация с идентификатором 1000000001 — владелец приватной группы RA.USR_CFM («Операторы системы подтверждения личности»). С помощью программного интерфейса эта организация может:

— посмотреть перечень организаций, которым предоставлена данная группа;

— дать некоторой организации доступ к данной группе;

— отозвать у организации доступ к группе.

Для просмотра списка организаций, которым предоставлен доступ к указанной группе, необходимо выполнить запрос методом GET в адрес программного интерфейса ЕСИА*(23). В заголовке запроса должен быть указан маркер доступа. Имеется возможность вызвать этот сервис с функцией встраивания (embed), чтобы сразу был виден перечень организаций, которым предоставлен доступ. Пример запроса:

Пример ответа, из которого видно, что доступ предоставлен четырем организациям (указаны их ОГРН и идентификаторы разрешений):

Для добавления организации в этот перечень необходимо выполнить запрос методом POST в адрес этого же программного интерфейса ЕСИА*(24). В заголовке запроса должен быть указан маркер доступа. В теле запроса должны быть указаны параметры:

— <ogrn> — ОГРН организации;

— <rqCfm> — признак, определяющий, что включение в группу требует персонального согласования со стороны владельца группа (для этого он должен иметь значение “true”).

Пример запроса (разрывы строки даны для удобства чтения):

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

В.2.1 общие принципы

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

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

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

— система-клиент получает разрешение на доступ (authorization grant) в виде авторизационного кода;

— система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;

— сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;

— система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;

— поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;

— система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;

— поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;

— система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;

— сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.

Схема взаимодействия представлена на рисунке 14.

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

Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).

Рисунок 14 — Общая схема взаимодействия при получении маркера доступа с помощью авторизационного кода

Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления.

Особенности маркера обновления:

— имеет более длительный (или бессрочный) срок действия, чем у маркера доступа;

— предъявляется исключительно при необходимости получить новый маркер доступа (таким образом, минимизируется риск перехвата);

— выдается сервисом авторизации одновременно с маркером доступа;

— может быть отозван владельцем ресурса.

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

В.7 сведения о структуре маркера идентификации

Структура маркера идентификации аналогична структуре маркера доступа (см. Приложение В.5) и состоит из тех же трех частей: заголовок, набор утверждений и подпись.

Особенность заголовка маркера идентификации состоит в том, что него значение атрибута “sbt” равно “id”.

Пример заголовка маркера идентификации в ЕСИА:

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

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”), может принимать различные значения, например — “P” (физическое лицо);

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” (пароль);

Пример сообщения маркера идентификации в ЕСИА:

Подпись (signature) маркера осуществляется по алгоритму, который указывается в параметре “alg” маркера. Подпись вычисляется от двух предыдущих частей маркера (HEADER.PAYLOAD).

_____________________________

Г.4 восстановление доступа к учетной записи пользователя

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

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

— отправка на адрес электронной почты (при условии, что при вызове сервиса адрес указан среди личных данных пользователя);

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

В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на восстановление доступа (requestId), поскольку при восстановлении доступа осуществляется верификация данных пользователя в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей), а также пароль для входа в систему*(70).

При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.

Если заявка на восстановление доступа выполнена успешно, ЕСИА направляет пользователю по указанным в запросе каналам связи уведомление об успехе проверки и возможности входа в учетную запись. Если данные пользователя не прошли проверку по БГИР (и в заявке указан e-mail и/или номер мобильного телефона), ЕСИА направляет пользователю уведомление об этом, при этом восстановление доступа к учетной записи не производится.

Специалист Центра обслуживания Оператора выдачи ключа ПЭП имеет возможность проверить статус восстановления доступа. Для этого ИС Оператора выдачи ключа ПЭП должна произвести вызов метода «Проверить статус заявки на выполнение операции», в качестве входных параметров метод получает идентификатор заявки на восстановление доступа (requestId).

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

Е.2.2 проверка состояния выполнения запроса

Для получения результата идентификации пользователя и проверки его данных должен быть вызван метод «Получить результат обработки запроса на проверку данных пользователя (без подтверждения пользователем разрешения)», в качестве входного параметра метод получает идентификатор заявки на проверку данных пользователя (requestId).

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

При неуспешном завершении метода возвращает ошибку, содержащую код и текст ошибки.

_____________________________

*(1) Соответствующий термин на английском языке — Single Sign On

*(2) Соответствующий термин на английском языке — Identity Management

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

*(4) Раздел 6 Регламента.

*(5) Раздел 9 Регламента.

*(6) Раздел 10 Регламента.

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

*(8) Раздел 9 Регламента.

*(9) Раздел 10 Регламента.

*(10) Раздел 9 Регламента.

*(11) Раздел 10 Регламента.

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

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

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

*(14) См. Приложение В.6.2.2.

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

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

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

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

*(19) Раздел 6 Регламента.

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

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

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

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

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

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

*(26) См. раздел 6 Регламента.

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