Единая система идентификации и аутентификации. Методические рекомендации по использованию Единой системы идентификации и аутентификации Версия 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.

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

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

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

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

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

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

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

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

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

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

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

А.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 по адресу конкретного разрешения. Пример запроса:

В.1 общие сведения

OAuth 2.0 определяет протокол взаимодействия следующих сторон:

– владелец ресурса (resource owner) – сущность, которая может предоставить доступ к защищаемому ресурсу (например, конечный пользователь);

– система-клиент (client) – приложение, которое запрашивает доступ к защищаемому ресурсу от имени владельца ресурса;

– сервис авторизации (authorization server) – сервис, который выпускает для клиента маркеры доступа с разрешения владельца ресурса;

– поставщик ресурса (resource server) – сервис, на котором размещены защищаемые ресурсы, и который может принимать запросы на доступ к защищаемым ресурсам и отвечать на эти запросы.

Модель контроля доступа, реализуемая сервисом авторизации ЕСИА, основана на использовании маркера доступа (security access token). Этот маркер несет информацию о подмножестве полномочий системы-клиента, о самой системе-клиенте, а также ряд служебных параметров.

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

В ЕСИА используются два способа получения маркера доступа:

1. Система-клиент получает маркер доступа в результате делегированного принятия решения сервисом авторизации на основании согласия владельца ресурса. В этом случае сервис авторизации выдает маркер доступа, если явными образом получает разрешение со стороны владельца ресурса.

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

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

Аутентификация пользователя, реализуемая с помощью модели OAuth 2.0 и распишения OpenID Connect, основана на использовании маркера идентификации (ID token). Этот маркер несет информацию об идентификационных данных пользователя, а также ряд служебных параметров.

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

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

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

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

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

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

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

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

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

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

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

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

Похожее:  12 способов оплатить кредит в банке Ренессанс

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

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

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

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

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

Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (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).

_____________________________

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

Получение данных о документах в исходном виде происходит так же путем указания scope.Сервис доступен для типов документов VEHICLE_INFO (Выписка
о транспортном средстве по владельцу), ILS_PFR (Cведения о состоянии индивидуального
страхового счета застрахованного лица)

, PAYOUT_INCOME (Сведения о доходах
физического лица и о выплатах страховых взносов, произведенных в пользу физического
лица). Но в случае запроса данных ответ может поступить не сразу, а в течении некоторого времени.В случае, если сведение запрошено в ведомстве и ответ еще не поступил, возвращается
идентификатор этого запроса и идентификатор пользователя (oid).

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

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

{"sub":"3","info":{"uid":"1000486446","stateFacts":["EntityRoot"],"firstName":"Тимофей","lastName":"Сазонов","middleName":"Трофимович","trusted":true,"updatedOn":1633359785,"status":"REGISTERED","verifying":true,"rIdDoc":160710,"containsUpCfmCode":false,"eTag":"A543E45F09EDC6AEE19530A674E636B54F9A29CC"}}

Г.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.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован.

Adblock
detector