2 общее описание есиа
В соответствии с постановлением Правительства Российской Федерации от 28 ноября 2022 г. № 977 ЕСИА должна обеспечивать санкционированный доступ участников информационного взаимодействия (заявителей и должностных лиц ОГВ) к информации, содержащейся в государственных информационных системах, муниципальных информационных системах и иных информационных системах.
При этом ЕСИА не обеспечивает выполнение процессов идентификации, аутентификации и авторизации участников межведомственного взаимодействия, возникающих в процессе использования СМЭВ, в частности, при взаимодействии информационных систем с использованием СМЭВ.
Основные функциональные возможности ЕСИА:
– идентификация и аутентификация пользователей, в том числе:
– однократная аутентификация*(1), которая дает пользователям ЕСИА следующее преимущество: пройдя процедуру идентификации и аутентификации в ЕСИА, пользователь может в течение одного сеанса работы обращаться к любым информационным системам, использующим ЕСИА, при этом повторная идентификация и аутентификация не требуется.
– поддержка различных методов аутентификации: по паролю, по электронной подписи, а также двухфакторная аутентификация (по постоянному паролю и одноразовому паролю, высылаемому в виде sms-сообщения);
– поддержка уровней достоверности идентификации пользователя (упрощенная учетная запись, стандартная учетная запись, подтвержденная учетная запись).
– ведение идентификационных данных*(2), а именно – ведение регистров физических, юридических лиц, органов и организаций, должностных лиц органов и организаций и информационных систем;
– авторизация уполномоченных лиц ОГВ при доступе к следующим функциям ЕСИА:
– ведение регистра должностных лиц ОГВ в ЕСИА;
– ведение справочника полномочий в отношении ИС и предоставление пользователям ЕСИА (зарегистрированным в ЕСИА как должностные лица ОГВ) полномочий по доступу к ресурсам ИС, зарегистрированным ЕСИА;
– делегирование вышеуказанных полномочий уполномоченным лицам нижестоящих ОГВ. – ведение и предоставление информации о полномочиях пользователей в отношении информационных систем, зарегистрированных в ЕСИА.
1 введение
Переход к оказанию государственных и муниципальных услуг в электронном виде требует от государства предоставить людям и органам государственной власти возможности безопасно идентифицировать друг друга онлайн. Когда люди и органы государственной власти могут доверять результатам идентификации друг друга, они могут предоставлять и потреблять услуги, чего нельзя было бы достичь в другом случае из-за большой сложности или важности услуг.
В текущей онлайн среде от людей требуется ведение десятков различных имен пользователей и паролей – по одной паре для каждого вебсайта, с которым пользователь взаимодействует. Сложность такого подхода является бременем для людей и потворствует такому поведению, как повторное использование паролей, что упрощает онлайн мошенничества и нарушения идентификации.
В то же время органы государственной власти сталкиваются с постоянно возрастающими затратами на управление учётными записями пользователей, последствиями онлайн мошенничеств и неэффективностью электронных услуг в результате нежелания потенциальными пользователями проходить регистрацию еще одной учётной записи.
Созданная Минкомсвязью России ФГИС ЕСИА:
1. Предоставляет использующим ее информационным системам органов государственной власти решение по достоверной идентификации пользователей (как физических, так и должностных лиц ЮЛ и ОГВ), достигнутой благодаря тому, что:
– регистрация лица в ЕСИА сопряжена с проверкой значимых для удостоверения личности критериев;
– ЕСИА обеспечивает защиту размещённой в ней информации в соответствии с законодательством Российской Федерации.
2. Является ориентированной на пользователя – предоставляет ему возможности:
– идентификации и аутентификации с использованием единой учетной записи и широкого спектра поддерживаемых методов аутентификации при доступе к различным информационным системам органов государственной власти;
– управления своими персональными данными, размещенными в ЕСИА, и контроля над их предоставлением в информационные системы органов государственной власти.
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.5 Регистрация системных групп
Для систем, интегрированных с ЕСИА, имеется возможность проверять наличие у пользователей специфических полномочий по доступу к этой системе. Данная возможность обеспечивается в ЕСИА посредством механизма системных групп (групп доступа) – для проведения авторизации сотрудников организаций (ЮЛ или ОГВ).
Оператор ИС может зарегистрировать одну или несколько системных групп, которые будут доступны организации; уполномоченные сотрудники организаций смогут включать/исключать своих сотрудников с помощью веб-интерфейса ЕСИА (см. п. 4.2.2.3).
Регистрацию системных групп можно осуществлять с помощью Технологического портала ЕСИА, при условии, что данной организации предоставлено право создания собственных системных групп.
В ЕСИА предусмотрены следующие типы групп доступа:
– публичная – доступная для назначения всем организациям. Уполномоченный сотрудник организации (не являющейся владельцем группы) всегда может включать в эту группу сотрудников своей организации;
– ограниченно доступная (приватная) группа для ОГВ – доступная всем организациям, имеющим признак ОГВ;
– ограниченно доступная (приватная) – доступная организациям только с разрешения владельца системной группы. Уполномоченный сотрудник организации может включать в эту группу сотрудников своей организации только после получения организацией прав доступа со стороны организации-владельца системной группы.
Организация-владелец ограниченно доступной группы может предоставить организации доступ к группе в следующих режимах:
– с возможностью свободного включения в группу сотрудников;
– с включением в группу сотрудников только с персональным согласованием этого включения со стороны организации-владельца этой группы. В этом случае добавление сотруднка в группу с помощью веб-интерфейса или программного интерфейса влечет за собой направление запроса в учетную запись организации-владельца группы для его рассмотрения; только после согласования запроса со стороны организации-владельца сотрудник будет добавлен в группу.
2.2.3 Управление принадлежностью сотрудников к системным группам
Для регулирования доступа сотрудников к интегрированным с ЕСИА информационным
системам уполномоченный сотрудник организации имеет возможность с помощью веб-интерфейса ЕСИА включать и исключать сотрудников из системных групп*(18).
Группы доступа (системные группы) связаны с информационными системами, доступ к которым они регулируют. Если сотрудник организации был включен в системную группу, то соответствующие данные сможет обрабатывать ИС-владелец данной системной группы: информация о принадлежности к системной группе будет передана в утверждениях SAML, а также может быть получена с помощью программного интерфейса, основанного на архитектурном стиле REST.
Общая схема взаимодействия выглядит следующим образом:
1. ОГВ регистрирует в ЕСИА информационную систему (ИС-1), доступ которой должны получать представители организаций, зарегистрированных в ЕСИА. При регистрации ИС-1 данный ОГВ определяет название соответствующей системной группы (см. п. 4.1.4), например «группа 1».
2. Уполномоченный сотрудник организации использует веб-интерфейс ЕСИА для просмотра существующих групп доступа. Находит группы доступа, связанные с системой ИС-1, и видит, что в этом перечне появилась «группа-1»*(19).
3. Уполномоченный сотрудник ЮЛ добавляет в «группу-1» сотрудников организации, которым он разрешает действовать в ИС-1 от имени ЮЛ.
4. Сотрудник ЮЛ, включенный в системную группу «группа-1», аутентифицируется с помощью ЕСИА в ИС-1.
5. ИС-1 получает среди SAML-утверждений информацию о том, что пользователь включен в «группу-1» (для этого анализирует утверждение memberOfGroups – см. п. А.5 приложения А), и принимает положительное решение о доступе пользователя к своим ресурсам.
6. Если другая интегрированная с ЕСИА ИС-2 при аутентификации обрабатывает SAML-утверждение о принадлежности пользователя к группам, то она не увидит информацию о «группе-1», потому что данная ИС-2 не является владельцем этой группы.
3.4 Особенности получения данных ИС
Получать данные об интегрированных с ЕСИА информационных системах можно только посредством программных интерфейсов, основанных на архитектурном стиле REST (см. п. Б.7 приложения Б).
Чтобы система могла быть идентифицирована средствами ЕСИА, она должна загрузить в ЕСИА свой сертификат (см. п. 4.2.4).
Чтобы система могла производить идентификацию ИС через ЕСИА, она должна предварительно получить разрешение на вызов соответствующего REST-сервиса ЕСИА. Необходимость получать данные об ИС должна быть указана в Заявке на создание записи регистра информационных систем в ЕСИА (среди целей подключения ИС в ЕСИА)*(22).
_____________________________
*(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.2.2.
*(13) Для подтверждения личности Центры обслуживания могут использовать соответствующий программный интерфейс ЕСИА (см. п. Г.3 приложения Г).
*(14) Инициирование приглашения на присоединение пользователя к юридическому лицу или ОГВ возможно с помощью программного интерфейса ЕСИА. Детальная информация – в Приложении Б.7.
*(15) Раздел 6 Регламента.
*(16) Также возможно управление данными организации с помощью программного интерфейса на основе REST (см. Приложение Б).
*(17) Бывший сотрудник ЮЛ может продолжать использовать свою учетную запись ЕСИА, например, для получения государственных услуг в электронном виде.
*(18) Если соответствующими информационными системами предусмотрены группы доступа (системные группы), см. п. 4.1.5.
*(19) Если это публичная группа или ограниченно доступная группа, доступ к которой предоставлен данной организации.
*(20) За исключением получения данных об ИС (см. п. Б.7 приложения Б и п. В.3 приложения В.
*(21) Порядок подключения к ЕСИА с целью использования программных интерфейсов описан в п. 9-10 Регламента.
*(22) См. раздел 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 (протокол единого выхода) – определяет механизм одновременного завершения активных сессий, ассоциированных с аутентифицированным субъектом. Выход может инициироваться пользователем или поставщиком идентификации.
Аутентификация с использованием модели 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 – Схема подключения системы к ЕСИА
Б.1 общие сведения о программном интерфейсе есиа
В рамках развития ЕСИА реализован прикладной программный интерфейс на базе архитектурного стиля “Representational State Transfer” (REST). Он позволяет интегрированным с ЕСИА информационным системам получать доступ к хранящимся в ЕСИА ресурсам, т.е. данным (например, о пользователях или других информационных системах), а также выполнять ряд операций.
Вызов прикладного программного интерфейса возможен только теми интегрированными с ЕСИА системами, которые имеют на это соответствующие полномочия. Контроль доступа к ресурсам ЕСИА осуществляет сервис авторизации ЕСИА, реализующий модель контроля доступа, основанную на спецификациях OAuth 2.0 (см. Приложение В).
Для обозначения ресурсов используются специальные идентификаторы. Сами ресурсы организованы иерархически, уровни разделены косой чертой – “/”. Ресурсы более «низкого» уровня являются составными частями «родительского уровня»:
В ЕСИА используется два типа ресурсов:
– документ содержит информацию об отдельном объекте в базе данных, который характеризуется некоторыми полями и значениями. Например, при доступе к документу об организации сервис возвращает наименование организации, ее тип, ОГРН и др. Кроме того, в документе могут содержаться ссылки на связанные ресурсы: так, в документе об организации размещаются указатели на ресурсы (документы) по ее сотрудникам;
– коллекция представляет собой список некоторых ресурсов, например, документов. Перечень организаций, сотрудников отдельной организации – примеры коллекций. Ресурсы, который включены в коллекцию, снабжены собственными идентификаторами (uri). Обычно для обозначения коллекции используются множественные существительные (orgs, sbjs и др.).
Б.7.5 управление доступом к непубличным группам
Программный интерфейс позволяет предоставить другой организации доступ к непубличной группе (если организация, вызывающая сервис, является владельцем данной группы), а также отозвать доступ.
Пусть организация с идентификатором 1000000001 – владелец приватной группы RA.USR_CFM («Операторы системы подтверждения личности»). С помощью программного интерфейса эта организация может:
– посмотреть перечень организаций, которым предоставлена данная группа;
– дать некоторой организации доступ к данной группе;
– отозвать у организации доступ к группе.
Для просмотра списка организаций, которым предоставлен доступ к указанной группе, необходимо выполнить запрос методом GET в адрес программного интерфейса ЕСИА*(23). В заголовке запроса должен быть указан маркер доступа. Имеется возможность вызвать этот сервис с функцией встраивания (embed), чтобы сразу был виден перечень организаций, которым предоставлен доступ. Пример запроса:
Пример ответа, из которого видно, что доступ предоставлен четырем организациям (указаны их ОГРН и идентификаторы разрешений):
Для добавления организации в этот перечень необходимо выполнить запрос методом POST в адрес этого же программного интерфейса ЕСИА*(24). В заголовке запроса должен быть указан маркер доступа. В теле запроса должны быть указаны параметры:
– <ogrn> – ОГРН организации;
– <rqCfm> – признак, определяющий, что включение в группу требует персонального согласования со стороны владельца группа (для этого он должен иметь значение “true”).
Пример запроса (разрывы строки даны для удобства чтения):
Для отзыва доступа необходимо выполнить запрос методом DELETE по адресу конкретного разрешения. Пример запроса:
Базовый сценарий аутентификации
Базовым сценарием аутентификации при использовании OpenID Connect 1.0 является сценарий аутентификации физического лица (например, заявителя). Сценарий включает следующие шаги:
1. Пользователь нажимает на веб-странице системы-клиента кнопку «Войти через ЕСИА».
2. Система-клиент формирует и отправляет в ЕСИА запрос на аутентификацию и перенаправляет браузер пользователя на специальную страницу предоставления доступа.
3. ЕСИА осуществляет аутентификацию пользователя одним из доступных способов. Если пользователь ещё не зарегистрирован в ЕСИА, то он может перейти к процессу регистрации.
4. Когда пользователь аутентифицирован, ЕСИА сообщает пользователю, что система-клиент запрашивает данные о нем в целях проведения идентификации и аутентификации, предоставляя перечень запрашиваемых системой-клиентом сведений.
5. Если пользователь дает разрешение на проведение аутентификации системой-клиентом, то ЕСИА выдает системе-клиенту специальный авторизационный код.
6. Система-клиент формирует в адрес ЕСИА запрос на получение маркера идентификации, включая в запрос полученный ранее авторизационный код.
7. ЕСИА проверяет корректность запроса (например, что система-клиент зарегистрирована в ЕСИА) и авторизационного кода и передает системе-клиенту маркер идентификации.
8. Система-клиент извлекает идентификатор пользователя из маркера идентификации. Если идентификатор получен, а маркер проверен, то система-клиент считает пользователя аутентифицированным.
После получения маркера идентификации система-клиент использует REST-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа (см. приложения Б и В).
Рисунок 4 – Идентификация и аутентификация пользователей при использовании механизма OpenID Connect 1.0
В.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) в виде авторизационного кода;
– система-клиент запрашивает маркер доступа, предъявив авторизационный код сервису авторизации;
– сервис авторизации аутентифицирует систему-клиента, проверяет авторизационный код и выдает маркер доступа и маркер обновления;
– система-клиент запрашивает у поставщика защищенный ресурс, предъявляя маркер доступа;
– поставщик ресурса проверяет маркер доступа, если он валиден, то разрешает доступ к защищенному ресурсу;
– система-клиент вновь запрашивает с помощью выданного ранее маркера доступ к защищенному ресурсу;
– поставщик ресурса проверяет маркер, обнаруживает, что срок его действия истек, возвращает сообщение об ошибке;
– система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления;
– сервис авторизации проверяет валидность маркера обновления и возвращает два новых маркера: доступа и обновления.
Схема взаимодействия представлена на рисунке 14.
После того, как система-клиент получила маркер доступа, она может неоднократно обращаться за получением соответствующего защищенного ресурса, пока не истечет срок действия этого маркера. Когда это произойдет, системе-клиенту потребуется получить новый маркер доступа.
Ключевая особенность этой модели в том, что сам владелец ресурса никогда не получает маркер доступа, его получает сама система-клиент в результате прямой связи с сервисом авторизации (server-side flow).
Рисунок 14 – Общая схема взаимодействия при получении маркера доступа с помощью авторизационного кода
Для оптимизации повторного получения маркера доступа используется механизм маркера обновления (refresh token): в этом случае первоначально в обмен на авторизационный код системе-клиенту выдается не только маркер доступа, но и маркер обновления. Когда маркер доступа перестает действовать, система-клиент обращается к сервису авторизации за получением нового маркера доступа, предъявляя маркер обновления.
Особенности маркера обновления:
– имеет более длительный (или бессрочный) срок действия, чем у маркера доступа;
– предъявляется исключительно при необходимости получить новый маркер доступа (таким образом, минимизируется риск перехвата);
– выдается сервисом авторизации одновременно с маркером доступа;
– может быть отозван владельцем ресурса.
Таким образом, наличие маркера обновления позволяет системе-клиенту получать новый маркер доступа даже тогда, когда пользователь (владелец ресурса) недоступен, при условии, что владелец ресурса явным образом не запретил доступ.
В.5 сведения о структуре и проверке маркера доступа
Используемый ЕСИА маркер состоит из трех частей:
1. Заголовок (header), в котором содержится общая информация о типе маркера, в том числе об использованных в ходе его формирования криптографических операциях.
2. Набор утверждений (payload / claim set) с содержательными сведениями о маркере.
3. Подпись (signature), которая удостоверяет, что маркер «выдан» ЕСИА и не был изменен при передаче.
Части маркера разделены точкой, так что он имеет вид:
Маркер передается в виде строки в формате Base64url*(4).
Каждая часть маркера содержит набор утверждений (claims) трех типов:
Заголовок (header) содержит описание свойств используемого маркера:
1. Алгоритм шифрования (“alg”, стандартное обозначение); в настоящее время в ЕСИА поддерживается алгоритм электронной подписи RSA SHA-256, рекомендуемый спецификацией (соответствует значению “RS256”)*(5) и алгоритм электронной подписи ГОСТ Р 34.10-2001 (соответствует значению “GOST3410”);
2. Глобальный тип маркера (“typ”, стандартное обозначение), который в ЕСИА всегда имеет значение “JWT” (JSON Web Token);
3. ЕСИА-специфический тип маркера и его версия (“sbt” и “ver” соответственно, приватное обозначение), что необходимо для использования в ЕСИА нескольких типов маркера; для маркера доступа – “access”.
Например, заголовок маркера доступа в ЕСИА будет иметь следующий вид:
Сообщение (payload) включает в себя содержательные утверждения о субъекте. В случае, если система проводит аутентификацию пользователя с использованием механизма SAML, системе нет необходимости разбираться в формате payload маркера доступа. Однако если система проводит аутентификацию пользователя с использованием REST, ей необходимо извлечь необходимую информацию из сообщения маркера (payload) и проверить подпись ЕСИА.
Сообщение включает в себя содержательные утверждения о маркере доступа и субъекте: 1. Данные о маркере доступа:
– время прекращения действия (“exp ”) – в секундах с 1 января 1970 г. 00:00:00 GMT;
– время начала действия (“nbf”) – в секундах с 1 января 1970 г. 00:00:00 GMT, т.е. маркер нельзя обрабатывать до наступления указанного времени;
– время выдачи (“iat”) – в секундах с 1 января 1970 г. 00:00:00 GMT;
В.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).
_____________________________
Вконтакте: регистрация и войти
Чтобы создать новую страничку ВКонтакте, следует ввести имя, фамилию, указать дату рождения и нажать на зеленую кнопку «Продолжить регистрацию».
Для входа на свою страничку, ранее уже зарегистрированную, следует ввести телефон или email, пароль и нажать «Войти».
Дополнительные материалы:
1. Зачем нужна регистрация на сайте?
2. Регистрация на сайте Одноклассники: пошаговые советы
3. Регистрация на сайтах в 2 клика через автозаполнение Яндекс браузера
4. Проблемы с входом в соцсети: причины и решения
Г.1 получение доступа к электронному сервису
Каждый орган/организация для использования программного интерфейса ЕСИА по регистрации пользователей должен:
1. Подать заявку на создание записи регистра органов и организаций, имеющих право создания (замены) и выдачи ключа простой электронной подписи согласно п. 12 Регламента.
2. Доработать (разработать) свою ИС, в которой будет предусмотрена функция регистрации пользователей ЕСИА.
3. Сгенерировать для ИС криптографические ключи и выпустить на них квалифицированный сертификат ЭП:
– Сертификат должен быть выпущен на юридическое лицо (содержит ОГРН и имя организации).
– Сертификат должен быть выпущен аккредитованным УЦ.
– Требования к ключевому контейнеру определяются эксплуатационной документацией на ИС, которая будет использовать ключи.
4. Зарегистрировать ИС в СМЭВ (согласно регламенту СМЭВ подается заявка на регистрацию ИС).
5. Получить для ИС в СМЭВ права на доступ к сервису ЕСИА в СМЭВ.
6. Зарегистрировать ИС в ЕСИА согласно п. 6 Регламента.
7. Зарегистрировать подключение ИС в тестовом контуре ЕСИА для отработки интеграции согласно п. 9 Регламента.
8. Зарегистрировать подключение ИС в продуктивном контуре ЕСИА для отработки интеграции согласно п. 10 Регламента.
9. Зарегистрировать в ЕСИА Центры обслуживания органа/организации. Для этого можно воспользоваться Технологическим порталом ЕСИА.
10. Настроить свою ИС согласно ее эксплуатационной документации. В частности, необходимо завести в ИС идентификаторы Центров обслуживания, полученные на предыдущем шаге, а также установить сетевую связность к СМЭВ и задать использование ключей, соответствующих зарегистрированному в ЕСИА и СМЭВ сертификату ИС.
11. Специалистам Центров обслуживания, которые будут выполнять регистрацию пользователей в ЕСИА, нужно выпустить средства КЭП. В сертификатах обязательно должны быть ОГРН организации (из тех, что получили право выдачи ПЭП), СНИЛС сотрудника.
12. Дать доступ специалистам Центров обслуживания к ИС согласно ее эксплуатационной документации.
Г.2.1 запрос на регистрацию новой подтвержденной учетной записи
Для инициирования регистрации новой подтверждённой учётной записи пользователя в ЕСИА необходимо вызвать метод «Зарегистрировать подтверждённую учётную запись в ЕСИА с выдачей пароля для первого входа».
В качестве входных параметров метод получает персональные данные регистрируемого пользователя, необходимые для проведения операции, а также данные о способе доставки пароля для первого входа в систему. Возможны следующие способы доставки:
– отправка на адрес электронной почты (при условии, что при вызове сервиса адрес указан среди личных данных пользователя);
– отправка на номер мобильного телефона (при условии, что при вызове сервиса номер указан среди личных данных пользователя);
– отправка пароля не требуется (например, если пользователь будет входить в систему с использованием электронной подписи).
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на регистрацию пользователя (requestId), поскольку верификация данных пользователя осуществляется в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей).
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на регистрацию создана успешно, ЕСИА направляет пользователю по указанным в запросе каналам связи уведомление об успехе проверки и возможности входа в учетную запись. Если данные пользователя не прошли проверку по БГИР (и в заявке указан email и/или номер мобильного телефона)
Г.4 восстановление доступа к учетной записи пользователя
Сервис регистрации пользователей, зарегистрированный в СМЭВ, обеспечивает возможность восстановления доступа к подтвержденной учетной записи пользователя при явке в Центр обслуживания Оператора выдачи ключа ПЭП. Для восстановления доступа необходимо вызвать метод «Восстановить доступ к учётной записи ЕСИА с выдачей пароля для входа» данного сервиса.
В качестве входных параметров метод получает персональные данные пользователя, необходимые для проведения операции, а также данные о способе доставки пароля для входа в систему. Возможны следующие способы доставки:
– отправка на адрес электронной почты (при условии, что при вызове сервиса адрес указан среди личных данных пользователя);
– отправка на номер мобильного телефона (при условии, что при вызове сервиса номер указан среди личных данных пользователя).
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на восстановление доступа (requestId), поскольку при восстановлении доступа осуществляется верификация данных пользователя в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей), а также пароль для входа в систему*(5).
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на восстановление доступа выполнена успешно, ЕСИА направляет пользователю по указанным в запросе каналам связи уведомление об успехе проверки и возможности входа в учетную запись. Если данные пользователя не прошли проверку по БГИР (и в заявке указан e-mail и/или номер мобильного телефона), ЕСИА направляет пользователю уведомление об этом, при этом восстановление доступа к учетной записи не производится.
Специалист Центра обслуживания Оператора выдачи ключа ПЭП имеет возможность проверить статус восстановления доступа. Для этого ИС Оператора выдачи ключа ПЭП должна произвести вызов метода «Проверить статус заявки на выполнение операции», в качестве входных параметров метод получает идентификатор заявки на восстановление доступа (requestId).
В ответном сообщении передается информация о текущем статусе выполнения операции восстановления доступа к учетной записи пользователя.
Г.5 удаление учетной записи пользователя
Сервис регистрации пользователей, зарегистрированный в СМЭВ, обеспечивает возможность удаления подтвержденной учетной записи пользователя при явке в Центр обслуживания Оператора выдачи ключа ПЭП. Для удаления необходимо вызвать метод «Удалить учетную запись пользователя ЕСИА».
В качестве входных параметров метод получает персональные данные пользователя, необходимые для проведения операции.
В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно). При успешном завершении в ответном сообщении содержится идентификатор заявки на удаление учетной записи (requestId), поскольку при удалении осуществляется верификация данных пользователя в асинхронном режиме (в силу возможной недоступности БГИР ФОИВ для осуществления верификации персональных данных пользователей)*(6).
При неуспешном завершении метод возвращает ошибку, содержащую код и текстовое описание ошибки.
Если заявка на удаление выполнена успешно, ЕСИА производит удаление учетной записи и направляет пользователю уведомление об этом.
Специалист Центра обслуживания Оператора выдачи ключа ПЭП имеет возможность проверить статус удаления учетной записи. Для этого ИС Оператора выдачи ключа ПЭП должна произвести вызов метода «Проверить статус заявки на выполнение операции», в качестве входных параметров метод получает идентификатор заявки на удаление (requestId).
В ответном сообщении передается информация о текущем статусе выполнения операции удаления учетной записи пользователя.
Изменились правила входа на evhod-v-lichnyj-kabinet.ru
С 14.03.2022 г. «Правительство для граждан» вводит усиленную защиту информации пользователей портала Evhod-v-lichnyj-kabinet.ru. С этой целью вход на портал будет производиться посредством двухфакторной индентификации. Что это значит?
Если раньше войти на портал можно было, выбрав один из способов (логин/пароль, ЭЦП, смс код), то теперь при входе через логин/пароль нужно применять одновременно два способа: логин/пароль плюс СМС подтверждение. Воспользоваться только одним из этих способов по отдельности больше нельзя.
Теперь для входа на портал пользователям evhod-v-lichnyj-kabinet.ru необходимо:
ввести логин/ИИН;
ввести пароль;
подтвердить вход одноразовым СМС-кодом.
Обратите внимание, что смс придет только на номер, зарегистрированный в базе мобильных граждан. Тем, кто еще не зарегистрировал номер, необходимо это сделать. Регистрация в базе доступна на портале Egov, через мобильное приложение eGov Mobile или в ЦОНе. Если номер заблокирован или неактуален, нужно обратиться в call-центр по номеру 1414 либо поменять номер в личном кабинете evhod-v-lichnyj-kabinet.ru.
Двухфакторная защита позволит снизить риск доступа третьих лиц к личным данным граждан.
Отметим, что доступ к порталу помимо логина/пароля плюс СМС доступен также:
через ЭЦП;
через мобильное приложение eGov Mobile (сканирование QR-кода);
посредством биометрии (Digital ID).
Эти способы считаются достаточно защищенными, поэтому для них двухфакторная идентификация не требуется. Войти можно будет без СМС.
Ошибка авторизации! ваша сессия истекла, повторите попытку авторизации. 1с-битрикс – разработка
При входе в систему выдает ошибку авторизации.
По всей вероятности повредилось какая то таблица(возможно кончилось место, наиболее вероятная причина)
либо отсутствует “место” для хранения сессий (прим. отсутствует папка)
Ваша сессия истекла, повторите попытку авторизации.
Нельзя авторизоваться в админке.
Комментарий:
При входе в систему выдает ошибку авторизации
По всей вероятности повредилось какая то таблица(возможно кончилось место, наиболее вероятная причина)
либо отсутствует “место” для хранения сессий (прим. отсутствует папка)
Решение:
нужно запустить /bitrix/admin/site_checker.php (он покажет и исправит проблему)
Чтобы сделать тестирование без авторизации нужно: Инструмент представляет возможность протестировать конфигурацию даже если не работает авторизация или сайт не открывается из за нарушения сжатия (на экране отображаются крякозябры). Для этого достаточно создать пустой файл site_checker_debug в папке /bitrix. После этого откройте страницу
Второе решение: (оно ровно такое же, но другим способом заходим в админку и на мой взгляд смысла не имеет)
Решение только для редакций, включающих модуль Проактивной защиты (Стандарт и выше).
Проблема была в том, что было включено хранение сессий в БД, при этом была повреждена таблица b_sec_session.
Отключаете скриптом через ftp хранение сессий в БД (создадим файл названием us.php с кодом который представлен ниже и закинем в корень сайта по ftp)
Код – который должен быть в файлике us.php
require ( $_SERVER [ "DOCUMENT_ROOT" ]. "/bitrix/header.php" );
COption::SetOptionInt( 'security' , 'session' , 'N' );
require ( $_SERVER [ "DOCUMENT_ROOT" ]. "/bitrix/footer.php" );
Запускам сначала наш файлик
http://ваш_сайт/us.php
, после этого проводим штатную авторизацию
После этого проведите проверку и восстановление БД штатными средствами Битрикса.
Сервис регистрации пользователя и подтверждения личности
В целях регистрации пользователей в ЕСИА, а также подтверждения личности пользователей, создан и опубликован в СМЭВ электронный сервис «Сервис регистрации пользователей Единой системы идентификации и аутентификации»*(1). Сервис предназначен для использования Операторами выдачи ключа ПЭП – организациями, которые в соответствии с постановлением Правительства РФ от 25 января 2022 г.
№ 33 «Об использовании простой электронной подписи при оказании государственных и муниципальных услуг» обладают правом создания (замены) и выдачи ключа простых электронных подписей и усиленных квалифицированных электронных подписей в целях оказания государственных и муниципальных услуг*(2).
Данный сервис ЕСИА поддерживает следующие функции:
– инициирование регистрации новой подтверждённой учётной записи пользователя в ЕСИА с выдачей идентификатора заявки на регистрацию пользователя, а также пароля пользователя для первого входа в систему;
– подтверждение учетной записи (подтверждения личности) пользователя ЕСИА, в том числе – выдача кода подтверждения для подтверждения упрощенной учетной записи пользователя;
– инициирование процедуры восстановления доступа к подтверждённой учётной записи пользователя в ЕСИА с выдачей идентификатора заявки на восстановление доступа, а также пароля пользователя для входа в систему;
– удаление учетной записи;
– инициирование регистрации подтверждённой учётной записи пользователя в ЕСИА на базе существующей упрощенной;
– регистрация данных о детях пользователя;
– проверка статуса выполняемой операции (по регистрации пользователя / восстановлению доступа)*(3);
– поиск учетной записи.
Таблица 2 – рекомендации по информированию пользователя о несоответствии авторизации требованиям системы
_____________________________
* Если информационная система работает исключительно с учетными записями юридических лиц / государственных организаций, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, имеющие такую учетную запись (см.
Приложение А.6). В этом случае если пользователь, присоединенный к организации, ранее аутентифицировался в ЕСИА как физическое лицо, но перешел в эту ИС, то ЕСИА обеспечит автоматическое переключение его роли на роль юридического лица (если требуется – попросит пользователя выбрать организацию, от которой ему требуется работать).
** Если информационная система требует исключительно аутентификации по электронной подписи, то рекомендуется настроить ее метаданные так, чтобы доступ к ней могли получить только пользователи, аутентифицированные таким образом (см. Приложение А.6).
Следует учесть, что если информационная система направляет пользователя в «Профиль пользователя ЕСИА» для совершения некоторых операций (например, для выполнения проверок данных учетной записи), то после их выполнения пользователь не будет автоматчиески возвращен в ИС.