есиа что это такое расшифровка зачем подтверждать через мфц

Есиа что это такое расшифровка зачем подтверждать через мфц

МФЦ принимают документы только по предварительной записи (за исключением некоторых услуг).
Забрать результат предоставления услуги можно без записи.
За час до закрытия центра прекращается выдача талонов электронной очереди на приём и выдачу документов.

Зарегистрируйтесь и получайте госуслуги онлайн!

Что такое учетная запись (ЕСИА)?

Учетная запись – это «универсальный ключ» к получению электронных госуслуг и сервисов. Часто ее называют ЕСИА, потому что при получении логина и пароля регистрация осуществляется в Единой системе идентификации и аутентификации.

Для чего нужна учетная запись?

Учетная запись даст вам доступ не только к Порталу госуслуг Санкт-Петербурга, но и ко многим другим официальным городским интернет-ресурсам.

С подтвержденной учетной записью вы сможете без очередей и не выходя из дома:

записаться к врачу

оформить выплаты и льготы

оплатить коммунальные услуги

записать ребенка в детский сад и школу

получить российский или заграничный паспорт

проверить и уплатить штрафы, налоги, госпошлины

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

Достаточно зарегистрироваться один раз – и можно пользоваться перечисленными ресурсами без ограничений.

Как зарегистрироваться?

Заполните форму регистрации, указав ФИО, номер мобильного телефона и e-mail.

Нажмите кнопку «Зарегистрироваться». Получите код подтверждения.

Придумайте пароль, введите его в открывшемся окне и обязательно запомните. Теперь это ваш пароль для входа на госуслуги. Нажмите кнопку «Готово».

Заполните профиль пользователя. Укажите СНИЛС и данные документа, удостоверяющего личность. МВД и ПФР проверят внесенную информацию. Проверка займет от нескольких часов до нескольких дней.

Подтвердите личность онлайн через веб-версии или мобильные приложения банков (Сбербанк, Тинькофф Банк, Почта Банк, Банк ВТБ, Банк Санкт-Петербург и другие) или обратитесь с паспортом и СНИЛС в любой МФЦ города.

номер мобильного телефона;

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

Если вы уже зарегистрированы на Едином портале gosuslugi.ru, то отдельная регистрация на региональном портале gu.spb.ru не нужна. Используйте те же логин и пароль, что вы используете для входа на портал gosuslugi.ru.

Что такое «неподтвержденная» и «подтвержденная» учетная запись ЕСИА?

Зарегистрировавшись и указав персональные данные, вы получите учетную запись уровня «Неподтвержденная». Она дает ограниченные возможности: доступ к информационным госуслугам и сервисам (например, запись к врачу или проверка статуса заявления), просмотр задолженностей и штрафов.

Завершающим этапом регистрации является подтверждение введенных вами данных. После этого статус вашей учетной записи меняется на «Подтвержденная».

Подтвержденная учетная запись дает доступ к максимально широкому спектру электронных госуслуг, например, более чем к 240 электронным услугам на Портале gu.spb.ru, а также возможность без ограничений пользоваться всеми доступными сервисами.

Как подтвердить учетную запись?

Онлайн-банк

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

Подтвердить учетную запись можно лично в удобном для вас МФЦ города с паспортом и СНИЛС.

Почта России

Вы можете заказать получение кода подтверждения личности Почтой России из Личного кабинета.

Квалифицированная электронная подпись

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

Чтобы сразу получить подтвержденную учетную запись, вы можете зарегистрироваться онлайн через веб-версии или мобильные приложения банков, перечисленных выше, или лично обратиться в любой МФЦ города с паспортом и СНИЛС.

Как создать учетную запись юридического лица или индивидуального предпринимателя?

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

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

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

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

Источник

Преимущества регистрации в Единой системе идентификации и аутентификации (ЕСИА)

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

При помощи учетной записи ЕСИА можно получать различные электронные услуги:

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

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

Полная информация о способах регистрации в ЕСИА представлена на портале Госуслуг.

Жители Краснодарского края могут пройти процедуру регистрации в ЕСИА в центрах обслуживания. Информация об адресах и режиме работы всех центров обслуживания представлена на портале Госуслуг. В частности, центры обслуживания развернуты во всех клиентских службах ПФР на территории края.

Источник

Чем отличаются учетные записи на Госуслугах и как сделать подтвержденную?

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

Официальный портал Екатеринбурга начинает цикл публикаций с разъяснением удобных механизмов получения муниципальных и государственных услуг в электронном виде.

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

Зачем нужна учетная запись?

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

Какие типы учетных записей существуют?

Существует три типа учетных записей.

1. Упрощенная.

Упрощенная учетная запись открывает доступ только к справочной информации: получению бухгалтерской отчетности юрлица или копий некоторых документов. Для упрощенной учетной записи нужна лишь электронная почта или номер телефона. Но большинство государственных и муниципальных услуг будут скрыты либо недоступны для пользователя. Поэтому лучше сразу получить стандартную учетную запись. Это занимает пять минут.

2. Стандартная.

Стандартная учетная запись расширяет список доступных услуг: проверка штрафов ГИБДД по свидетельству о регистрации транспортного средства, по номеру автомобиля и водительскому удостоверению; регистрация товарного знака. Для этой записи пользователь заполняет паспортные данные и СНИЛС. Но чтобы полноценно пользоваться порталом, нужен следующий тип учетной записи.

3. Подтвержденная.

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

Зачем разделены учетные записи?

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

Как сделать подтвержденную учетную запись?

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

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

3. Подтвердить личность: лично прийти в центр обслуживания, в том числе в любом из отделений муниципального Многофункционального центра, получить письмо с кодом по почте или воспользоваться электронной подписью.

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

Источник

Есиа что это такое расшифровка зачем подтверждать через мфц

Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.

Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.

Обзор документа

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

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

ПРИЛОЖЕНИЕ _____
к протоколу заседания Подкомиссии
по использованию информационных технологий
при предоставлении государственных
и муниципальных услуг
Правительственной комиссии
по использованию информационных технологий
для улучшения качества жизни и условий ведения
предпринимательской деятельности
от __________________ г. № ____

ТАБЛИЦА ИЗМЕНЕНИЙ

СПИСОК СОКРАЩЕНИЙ

1 ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 ОБЩЕЕ ОПИСАНИЕ ЕСИА

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

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

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

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

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

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

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

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

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

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

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

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

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

3 АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ ЧЕРЕЗ ЕСИА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В ЕСИА создан механизм аутентификации пользователей, основанный на спецификациях OAuth 2.0 и расширении OpenID Connect 1.0.

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

Расширение OpenID Connect 1.0 предполагает использование маркера идентификации (ID Token) в целях проведения идентификации и аутентификации пользователя. Маркер идентификации содержит идентификационные данные пользователя, а также ряд служебных параметров (дата выдачи, время окончания срока действия и пр.).

Для иллюстрации использования OpenID Connect 1.0 в ЕСИА принята следующая терминология:

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

3.1 Как обеспечить вход пользователей через ЕСИА

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

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

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

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

— Подключение продуктивной версии интегрируемой системы к продуктивной среде ЕСИА в соответствии с Регламентом*(6).

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

3.1.1 Аутентификация с использованием стандарта 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*(7);

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

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

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

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

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

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

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

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

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

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

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

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. Осуществить подключение ИС к тестовой среде и отладить взаимодействие с ЕСИА в тестовой среде в соответствии с Регламентом*(10).

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

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

2. После подключения ИС к промышленной ЕСИА проверить работу промышленной версии ЕСИА с промышленной версией вашей системы.

3.2 Рекомендуемые сценарии интеграции по SAML

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

Базовый сценарий аутентификации пользователя

Базовым сценарием является сценарий аутентификации физического лица (например, заявителя). Этот сценарий позволяет получить сведения об индивидуальном пользователе (физическом лице) в момент аутентификации и соответствует профилю Web Browser SSO Profile стандарта SAML 2.0. Сценарий включает следующие шаги:

1. Пользователь нажимает на странице системы поставщика услуг кнопку «Войти через ЕСИА».

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

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

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

5. Когда пользователь успешно аутентифицирован, ЕСИА передаёт в систему ответ на запрос аутентификации, который содержит набор утверждений SAML (SAML Assertions) о пользователе.

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

Дополнительный сценарий аутентификации пользователя в качестве представителя организации

ЕСИА также позволяет аутентифицировать пользователя в качестве представителя:

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

Для проверки наличия у аутентифицированного сотрудника ЮЛ необходимых полномочий следует использовать функционал системных групп (4.2.2.3).

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

Сценарий с установкой локальной сессии

Сценарий с авторизацией пользователя

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

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

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

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

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

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

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

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

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-сервисы ЕСИА для получения дополнительных данных о пользователе, предварительно получив соответствующий маркер доступа (см. приложения Б и В).

Дополнительный сценарий аутентификации пользователя в качестве представителя организации

ЕСИА также позволяет аутентифицировать пользователя в качестве представителя организации, для этого ИС должна:

— запросить у ЕСИА не только маркер идентификации, но и маркер доступа (на получение данных пользователя);

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

— запросить у пользователя, от имени какой организации он будет работать в данной ИС (если пользователь является сотрудником нескольких организаций).

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

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

Сценарий с установкой локальной сессии

Сценарий с авторизацией пользователя

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

Для получения авторизационных данных следует использовать программный интерфейс, основанный на архитектурном стиле REST (п. 4.3, приложение Б). В этом случае помимо маркера идентификации система должна также запросить маркер доступа к нужным авторизационным данным.

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

3.4 Требования к визуальному оформлению входа посредством ЕСИА

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

— аутентификация исключительно посредством ЕСИА;

— аутентификация посредством ЕСИА в качестве одного из возможных вариантов аутентификации.

Независимо от выбранного сценария, при оформлении входа в систему с использованием ЕСИА не рекомендуется использовать слова «аутентификация» или «авторизация», вместо этого следует использовать слово «вход».

3.4.1 Аутентификация исключительно посредством ЕСИА;

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

При нажатии на кнопку «Вход» должно происходить перенаправление пользователя на страницу аутентификации ЕСИА в соответствии с применяемым сценарием аутентификации.

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

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

3.5 Возврат пользователя в систему, вызвавшую профиль пользователя в ЕСИА или регистрацию пользователя в ЕСИА

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

— изменение данных в личном профиле (например, прохождение процедуры проверки данных пользователя);

— прохождение процедуры регистрации.

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

— признак, позволяющий определить необходимость возврата в систему после регистрации упрощенной учетной записи (при вызове страницы регистрации ЕСИА); возврат после регистрации упрощенной учетной записи будет произведен только при передаче признака со значением «true».

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

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

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

4 ВЕДЕНИЕ РЕГИСТРОВ ЕСИА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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). Он позволяет интегрированным с ЕСИА информационным системам получать доступ к хранящимся в ЕСИА данным в произвольный момент времени после предварительного получения разрешения от пользователя*(24). Обеспечивается доступ к следующим данным:

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

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

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

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

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

ПРИЛОЖЕНИЕ А. ИСПОЛЬЗОВАНИЕ ЕСИА В ЦЕЛЯХ ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ ПОСРЕДСТВОМ СТАНДАРТА SAML 2.0

А.1 Общие сведения о стандарте SAML 2.0

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

Основными компонентами SAML 2.0 являются:

SAML 2.0 определяет синтаксис и семантику утверждений, относящихся к аутентификации, атрибутам и авторизационной информации. Определены следующие типы утверждений:

SAML 2.0 определяет способ передачи утверждений в протоколах. В ЕСИА используются следующие протоколы SAML 2.0 типа запрос/ответ:

Связывания SAML 2.0 определяют, как различные сообщения протоколов SAML 2.0 могут передаваться поверх транспортных протоколов (например, SOAP, HTTP). B ЕСИА используются следующие связывания SAML 2.0:

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

Как правило, поставщику услуг требуется детальная информация о результатах проведенной аутентификации. Эта информация содержится в контексте аутентификации, передаваемом в утверждениях SAML 2.0. Аутентификационный контекст (authentication context) определяет синтаксис для описания механизмов аутентификации.

А.2 Общие рекомендации по реализации интерфейсов поставщика услуг

Для реализации интерфейсов поставщика услуг можно использовать уже разработанные различные реализации поставщиков услуг с открытым кодом. Одним из таких поставщиков услуг является OIOSAML, реализованный под различные платформы. Различные реализации OIOSAML можно посмотреть на информационном ресурсе http://digitaliser.dk/group/42063/resources.

Примечание. В сборки последних версий OIOSAML разработчики стали включать библиотеки OpenSAML, которые несовместимы с ЕСИА. В настоящий момент с ЕСИА совместима версия 2.4.1. OpenSAML. Скачать данную версию можно по ссылке: http://www.shibboleth.net/downloads/java-opensaml/2.4.1.

Еще одним возможным вариантом реализации поставщика услуг для сред PHP является SimpleSAMLphp. Более подробную информацию о SimpleSAMLphp можно получить на информационном ресурсе http://simplesamlphp.org.

При самостоятельной реализации интерфейсов поставщика услуг на Java или C++ одним из возможных вариантов является использование набора библиотек с открытым кодом OpenSAML (строго версии 2.4.1.), который поддерживает работу со спецификациями SAML версии 1.0, 1.1 и 2.0. Подробную информацию о библиотеках OpenSAML можно посмотреть на информационном ресурсе https://wiki.shibboleth.net/confluence/display/OpenSAML/Home. Примеры кода по использованию OpenSAML для Java приведены в разделе А.7.

А.3 Общие требования к реализации интерфейса поставщика услуг

Интерфейсы поставщика услуг должны соответствовать следующим профилям SAML 2.0:

— Web Browser SSO с учетом рекомендаций Interoperable SAML 2.0 Web Browser SSO Deployment Profile;

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

— алгоритм c14n для каноникализации сообщения в формате XML;

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

— алгоритм c14n для каноникализации сообщения в формате XML;

— алгоритмы RSA и SHA-1 / SHA-256 / SHA-512 для передачи ключа преобразования сообщения на основе открытого ключа информационной системы, алгоритм AES для осуществления преобразования на переданном ключе. В качестве протокола доставки сообщения от системы ЕСИА информационной системе используется метод связывания HTTP POST.

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

— SHA-1 / SHA-256 / SHA-512;

В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

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

— SHA-1 / SHA-256 / SHA-512;

В качестве протокола доставки используется метод связывания HTTP-redirect.

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

— SHA-1 / SHA-256 / SHA-512;

В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

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

— SHA-1 / SHA-256 / SHA-512;

В качестве протокола доставки используется метод связывания HTTP-redirect.

А.4 Описание форматов электронных сообщений SAML 2.0 в ЕСИА

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

— протокол запроса аутентификации;

— протокол единого выхода.

Запрос аутентификации (AuthnRequest)

Запрос аутентификации (AuthnRequest) представляет собой XML-документ, который содержит следующие элементы:

Для сгенерированного SAML 2.0 сообщения с запросом AuthnRequest должно быть выполнено связывание (binding) с протоколом HTTP по методу HTTP-Redirect с учетом следующих особенностей:

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

— подписанное сообщение сжимается и кодируется в кодировке Base64.

В процессе связывания формируется конечный URL AuthnRequest, который в качестве GET-параметров должен содержать:

Пример URL AuthnRequest:

Ответ на запрос аутентификации (AuthnResponse).

Элементы saml2:Issuer и saml2:Signature содержат идентификатор поставщика идентификации и электронную подпись, созданную с помощью сертификата поставщика идентификации.

Элемент saml2:Subject содержит информацию о AuthnRequest, которому соответствует данный AuthnResponse, и представляет собой следующую структуру:

Элемент saml2:NameID содержит уникальный идентификатор, присвоенный поставщиком идентификации соответствующему AuthnRequest.

Элемент saml2:SubjectConfirmationData содержит набор атрибутов, в том числе:

Элементы saml2:AuthnStatement и saml2:AttributeStatement содержат информацию о результатах аутентификации.

Элемент saml2:AuthnStatement имеет два атрибута:

Элемент saml2:AttributeStatement содержит атрибуты пользователя и имеет следующую структуру:

Элемент saml2:Attribute имеет три атрибута:

Элемент saml2:AttributeValues состоит из двух атрибутов: xmlns:xsi и xsi:type. Эти атрибуты определяют формат значения атрибута пользователя.

Пример AuthnResponse приведен в разделе А.9.

Запрос завершения активной сессии пользователя (LogoutRequest)

Запрос завершения активной сессии (LogoutRequest) представляет собой XML-документ со следующей структурой:

Завершение активной сессии пользователя может быть инициировано как со стороны поставщика услуг, так и со стороны поставщика идентификации. В случае, если завершение сессии инициирует поставщик услуг, то LogoutRequest должен содержать обязательный элемент saml2:SessionIndex.

Элемент saml2:LogoutRequest имеет следующие атрибуты:

Элемент saml2:NameID в качестве значения содержит уникальный идентификатор присвоенный поставщиком идентификации соответствующему AuthnRequest.

Элемент saml2:SessionIndex содержит уникальный идентификатор пользователя, созданный при аутентификации.

Запрос на завершение сессии должен производиться из браузера (от имени пользователя). В качестве протокола доставки должен использоваться метод связывания HTTP-redirect.

Примеры запроса завершения сессии:

Ответ на запрос завершения активной сессии (LogoutResponse).

Ответ на запрос завершения активной сессии (LogoutResponse) представляет собой XML-документ со следующей структурой:

Элемент saml2:LogoutResponse имеет следующие атрибуты:

Элемент saml2p:Status имеет вложенный элемент saml2p:StatusCode, имеющий атрибут Value, в качестве значения которого передается статус операции.

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

Примеры ответа на запрос завершения сессии:

А.5 Описание метаданных поставщика услуг

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

МЕТАДАННЫЕ ПОСТАВЩИКА УСЛУГ

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

Если у пользователя или организации отсутствуют те или иные атрибуты, то они не передаются в SAML-утверждениях.

А.6 Шаблон файла метаданных

А.7 Рекомендации по указанию URL-адресов и выбору идентификатора поставщика услуг

1. Правильно для Единого портала государственных услуг (функций):

2. Неправильно для Единого портала государственных услуг (функций):

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

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

— Единый портал государственных услуг (функций): entityID=»http://www.gosuslugi.ru»;

— Российская общественная инициатива: entityID=»https://www.roi.ru».

— Единый портал государственных услуг (функций): entityID=»http://www.gosuslugi.ru»;

— Некорректный пример: entityID=»http://109.207.1.97″.

3. Указанный в поле entityID URL не должен содержать символов кириллицы.

А.8 Примеры кода на языке Java по использованию OpenSAML

Пример кода поставщика услуг

Пример кода создания запроса

Извлеченное сообщение «responseMessage» необходимо преобразовать (unmarshal) и извлечь сообщение :

Далее с извлеченным SAML 2.0 Response message можно выполнять операции. Например, извлечем Subject′s Name Id и сертификат:

А.9 Пример AuthnResponse

ПРИЛОЖЕНИЕ Б. СЕРВИСЫ ЕСИА НА БАЗЕ ПОДХОДА REST

Б.1 Общие сведения о программном интерфейсе ЕСИА

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

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

В ЕСИА используется два типа ресурсов:

— документ содержит информацию об отдельном объекте в базе данных, который характеризуется некоторыми полями и значениями. Например, при доступе к документу об организации сервис возвращает наименование организации, ее тип, ОГРН и др. Кроме того, в документе могут содержаться ссылки на связанные ресурсы: так, в документе об организации размещаются указатели на ресурсы (документы) по ее сотрудникам;

Для вызова сервиса ЕСИА, позволяющего получить доступ к защищенному ресурсу, система-клиент должна направить в https-адрес программного интерфейса ЕСИА запрос. Для этого (в зависимости от типа запроса) используются методы GET или POST. В каждом запросе должен быть указан идентификатор ресурса, к которому запрашивается доступ. Кроме того, в запрос на вызов REST-API должен быть добавлен следующий header:

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

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

При вызове сервиса может быть указана конкретная схема предоставления данных об объекте. Для этого необходимо дать ссылку на соответствующую схему в заголовке запросе (с помощью ACCEPT. Например:

В ответе на корректный запрос выдается JSON-документ, который представляет собой набор пар ключ/значение или массив значений. В заголовке (headers) ответа содержатся следующие данные:

1. Ссылки (links) на связанные ресурсы. Например, если в запросе указан ресурс с данными конкретного пользователя (prns/402), то ссылки будут содержать ресурсы с его контактными данными, документами, адресам, транспортными средствами, а также на «родительский» ресурс с перечнем всех пользователей в системе.

2. Указатель запрошенного ресурса (location), т.е. uri запрошенного ресурса.

3. Тип предоставляемых данных (Content-Type) с указанием схемы предоставляемых данных. Например, если запрашиваются данные о пользователе в схеме Person-1, то будет указано следующее значение: Content-Type: [application/json; q=.2; schema=»https://esia-portal1.test.gosuslugi.ru/rs/model/prn/Person-1″]

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

Содержательная часть ответа на запрос содержится в разделе body. Пример возвращаемых данных (разрывы строк даны для удобства чтения) о физическом лице:

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

— EntityRoot- корневой объект;

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

Из данного ответа видно, что на каждой странице отображается по 2 элемента.

Однако указание параметра «embed» позволяет получить данные о контактах непосредственно в ответе на следующий запрос:

В этом случае запрос данного ресурса будет возвращать ответ (фрагмент, разрывы строки даны для удобства чтения):

В данном случае на месте ссылок на связанные элементы встраиваются данные контактов.

При встраивании сохраняется возможность получать схемы возвращаемых ресурсов, например:

В этом случае данные об элементах будут возвращаться согласно первой схеме.

Также возможно встраивание нескольких ресурсов в запросе, например:

В этом случае в ответе вместо ссылок на сотрудников организации будут передаваться:

— краткие персональные данные (ФИО, пол, дата рождения и пр.).

При встраивании нескольких ресурсов также возможно указание на версии, например:

Перечень ссылок, которые могут быть встроены:

— данные о физических лицах:

— контактные данные (contacts);

— транспортные средства (vehicles);

— организации, к которым принадлежит физическое лицо (organizations);

— данные об организациях:

— контактные данные (contacts);

транспортные средства (vehicles);

— данные о сотрудниках организации:

— данные о сотруднике как физическом лице (person).

— данные по ссылкам, отображаемым в содержании ответа в разделе «elements» (возможность встраивания elements есть везде, где параметр stateFacts имеет значение «hasSize»).

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

— предоставление персональных данных пользователей;

— проверка факта удаления учётной записи пользователя ЕСИА;

— предоставление сведений о вхождении пользователя в группы и организации;

— предоставление данных из профиля организации;

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

— предоставление сведений о вхождении пользователей в группы;

— управление данными организации;

— предоставление сведений о субъекте.

Б.2 Предоставление персональных данных пользователей

Для получения персональных данных о пользователях система-клиент должна направить в https-адрес REST-API системы ЕСИА*(28) запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Иерархия идентификаторов этих ресурсов в ЕСИА имеет следующий вид:

— — внутренний идентификатор объекта, в том числе пользователя, в ЕСИА;

— — ссылка на перечень (коллекцию) типов данных, указанных пользователем с данным oid, возможные значения:

— — внутренний идентификатор элемента (например, контакта или документа) пользователя в ЕСИА.

В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (либо scope http://esia.gosuslugi.ru/id_doc с параметрами, либо один или несколько scope, обеспечивающих доступ к персональным данным пользователя, с параметрами*(29)).

Пример запроса (вызов сервиса в среде разработки):

Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 6.

При отображении всех коллекций используется механизм paging.

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

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

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

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

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

Б.3 Проверка факта удаления учётной записи и связанных с ней персональных данных пользователя из ЕСИА

Вызов данной операции предоставляет интегрированным с ЕСИА информационным системам данные об удаленных пользователях в ЕСИА (идентификатор пользователя). Для получения перечня удаленных пользователей система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. В качестве этого ресурса используется стандартный идентификатор ресурса с персональными данными пользователей (/prns), возвращающий перечень зарегистрированных в системе пользователей (см. раздел Б.2). Специфика вызова данной операции состоит в том, что запрос должен содержать следующие параметры:

В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/tech_inf с параметрами).

Пример запроса (вызов сервиса в среде разработки):

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

Б.4 Предоставление данных из профиля организации

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

— — ссылка на перечень (коллекцию) типов данных организации с указанным oid, возможные значения:

— — внутренний идентификатор контакта, адреса, транспортного средства или филиала.

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

Пример запроса (вызов сервиса в среде разработки):

Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 7.

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

Пример ответа с контактными данными об адресах организации при использовании возможностей встраивания*(34) (разрывы строки даны для удобства чтения):

Б.5 Предоставление списка участников организации

Для получения данных об участниках организации система-клиент должна направить по в https-адрес REST-API системы ЕСИА*(35) запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. Идентификатор этого ресурса в ЕСИА имеет следующий вид для получения списка сотрудников организации необходимо использовать uri /orgs//emps/, где:

В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/org_emps с параметрами).

Пример запроса (вызов сервиса в среде разработки):

Данные, которые ЕСИА возвращает в ответ на запрос, представлены в таблице 8.

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

При отображении всех коллекций (orgs, emps) используется механизм paging.

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

Пример ответа с контактными данными о сотрудниках организации при использовании возможности встраивания*(36) (разрывы строки даны для удобства чтения):

Б.6 Предоставление сведений о вхождении пользователя в группы

Для получения данных о вхождении пользователя в группы организации система-клиент должна направить по в https-адрес REST-API системы ЕСИА*(37) запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные.

Пример запроса (вызов сервиса в среде разработки):

Данные, которые ЕСИА возвращает в ответ на запрос, представлены в Таблица 9.

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

Данная ссылка означает, что пользователь с идентификатором 1000000105 как сотрудник организации 1000000224 включен в группу администраторов профиля организации (ORG_ADMIN) системы ЕСИА (мномоника ESIA). Выполнив запрос по данной ссылке можно получить краткую информацию о группе, которая включает в себя.

— мнемонику группы (grp_id);

— название группы (name);

— описание группы (description);

— признак того, что группа является системной (system);

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

Если группа не является системной и не привязана ни к какой системе, то ссылка на нее имеет следующий формат:

В кратких данных об этой группе атрибут «system» будет иметь значение «false».

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

Б.7 Управление данными организации

Программные интерфейсы на основе REST обеспечивают возможность управления данными организации для информационных систем этой организации. Обеспечена возможность:

— изменять данные профиля организации;

— управлять приглашениями должностным лицам, зарегистрированным в ЕСИА, на

присоединение к учетной записи соответствующей организации;

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

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

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

— добавлять и изменять данные филиалов организации.

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

— маркер доступа, выданный системе на scope (в зависимости от полномочий системы) с параметром org_oid, принимающим значение идентификатора организации;

Пример метки изменяемого объекта (выделено полужирным шрифтом):

Б.7.1 Изменение данных профиля организации

Программный интерфейс позволяет выполнить следующие операции:

— задать (изменить) организационно-правовую форму организации;

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

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

— задать, изменить и удалить транспортные средства организации.

Б.7.1.1 Редактирование организационно-правовой формы организации

Для изменения организационно-правовой формы организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА*(38). В заголовке запроса должен быть указан маркер доступа и тег объекта (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs/). В тело запроса должны быть включены:

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

В качестве ответа ЕСИА возвращает данные организации с измененной организационно-правовой формой.

Б.7.1.2 Редактирование контактов организации

Для добавления контакта организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА*(39). В заголовке запроса должен быть указан маркер доступа и тег контейнера с адресами (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//ctts). В тело запроса должны быть включены:

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

Для изменения контакта организации должен быть выполнен запрос методом POST на https-адрес программного интерфейса ЕСИА*(40). В заголовке запроса должен быть указан маркер доступа и тег объекта (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//ctts/). В тело запроса должны быть включены:

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

Изменение контакта возможно и без указания в URL запроса идентификатора контакта, в этом случае контакт будет изменен, но ему будет присвоен другой идентификатор.

Для удаления контакта организации должен быть выполнен запрос методом DELETE на https-адрес программного интерфейса ЕСИА*(41). В заголовке запроса должен быть указан маркер доступа и тег удаляемого объекта.

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

Б.7.1.3 Редактирование почтового адреса организации

Для добавления почтового адреса организации необходимо сделать запрос методом POST на https-адрес программного интерфейса ЕСИА*(42). Заголовок запроса должен включать в себя маркер доступа и тег контейнера адресов (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//addrs).

Тело запроса должно включать следующие данные (указываются все данные, которые должны отображаться в адресе этого типа):

— тип адреса (type), принимает значение «OPS»;

— строка адреса (addressStr), например, «Москва город, Тверская улица»;

— почтовый индекс (zipCode);

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

Изменение адреса осуществляется по аналогии с добавлением, недопустимо делать запрос с указанием конкретного идентификатора адреса.

Для удаления почтового адреса организации необходимо сделать запрос методом DELETE на https-адрес программного интерфейса ЕСИА*(43). Заголовок запроса должен включать в себя маркер доступа и тег удаляемого адреса (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//addrs/).

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

Б.7.1.4 Управление транспортными средствами организации

Для добавления записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST*(44). Заголовок запроса должен включать в себя маркер доступа, тег контейнера транспортных средств (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//vhls).

Тело запроса должно включать следующие данные:

Для изменения записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST*(45). Заголовок запроса должен включать в себя маркер доступа, тег записи транспортного средства (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//vhls/).

Тело запроса должно включать следующие данные:

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

Для удаления записи о транспортном средстве необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE*(46). Заголовок запроса должен включать в себя маркер доступа, тег записи транспортного средства (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//vhls/).

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

Б.7.2 Управление приглашениями должностным лицам, зарегистрированным в ЕСИА, на присоединение к учетной записи соответствующей организации

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

— просмотр отправленных, но не принятых приглашений;

— формирование нового приглашения;

— отзыв ранее отправленного приглашения.

Для просмотра отправленных приглашений необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом GET*(47). Заголовок запроса должен включать в себя маркер доступа. Пример запроса:

В качестве ответа ЕСИА возвращает перечень приглашений на присоединение к данной организации. Пример ответа:

Для получения данных об отдельном приглашении необходимо выполнить запрос методом GET по адресу с данными конкретного приглашения. Каждое приглашение описывается следующими параметрами:

Пример описания приглашения:

Чтобы отправить приглашение, необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом PUT*(48). Заголовок запроса должен включать в себя маркер доступа, а тело запроса должно включать следующие данные:

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

Чтобы удалить приглашение, необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE*(49). Заголовок запроса должен включать в себя маркер доступа. Пример запроса:

Б.7.3 Управление служебными данными присоединенных сотрудников, а также блокировка и удаление должностных лиц организации

Тело запроса должно включать следующие данные (все параметры обязательны):

Если какой-либо параметр не будет указан, то он будет очищен.

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

Для удаления сотрудника необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом DELETE*(51). Заголовок запроса должен включать в себя маркер доступа. Пример запроса:

Б.7.4 Управление полномочиями должностных лиц посредством изменения их членства в группах доступа

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

Добавление сотрудника в группу осуществляется запросом методом PUT на следующий https-адрес программного интерфейса ЕСИА:

Данный запрос включает сотрудника с идентификатором 1000023747 в группу «Администраторы профиля организации», принадлежащей ЕСИА.

Для исключения сотрудника из группы нужно вызвать программный интерфейс ЕСИА по указанному выше адресу (адрес для добавления сотрудника в группу) методом DELETE. Пример запроса:

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

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

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

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

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

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

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

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

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

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

Б.7.6 Добавление и изменение данных филиалов организации

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

— добавить филиал организации;

— изменить данные филиала организации.

Для добавления записи о филиале необходимо сделать запрос на https-адрес программного интерфейса ЕСИА методом POST*(54). Заголовок запроса должен включать в себя маркер доступа, тег контейнера филиалов (метка, полученная при запросе ресурса https://esia-portal1.test.gosuslugi.ru/rs/orgs//brhs).

Тело запроса должно включать следующие данные:

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

Тело запроса должно включать следующие данные:

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

Б.8 Предоставление сведений о субъекте

Для получения данных субъекте система-клиент должна направить в https-адрес REST-API системы ЕСИА*(56) запрос методом GET. В настоящее время используется исключительно для получения данных об информационных системах. Если уникальный идентификатор ИС в ЕСИА (oid) неизвестен, то возможна идентификация системы по сертификату. В этом случае запрос должен содержать следующие сведения:

Система ЕСИА поддерживает следующие алгоритмы вычисления криптографического хэш-значения (fingerPrint сертификата):

Ниже приведен пример заполнения :

В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/sbj_inf).

Пример запроса (вызов сервиса в среде разработки):

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

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

Ответ содержит следующие данные о субъекте:

Пример ответа на запрос:

Получение данных этого ресурса осуществляется так, как это описано в Приложении Б.4. Scope http://esia.gosuslugi.ru/sbj_inf позволяет получить краткие данные об организации.

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

Б.9 Предоставление списка измененных пользователей или организаций за период времени

Вызов данной операции предоставляет интегрированным с ЕСИА информационным системам данные об измененных пользователях или организаций в ЕСИА. Для получения перечня измененных пользователей или организаций система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом GET. В запросе должен быть указан ресурс, содержащий необходимые данные. В качестве этого ресурса используется стандартный идентификатор ресурса с персональными данными пользователей (/prns), возвращающий перечень зарегистрированных в системе пользователей (см. раздел Б.2) или стандартный ресурс со списком организаций (/orgs), возвращающий коллекцию организаций (см. Б.4). Специфика вызова данной операции состоит в том, что запрос должен содержать следующий параметр:

В запрос должен быть добавлен header с маркером доступа, позволяющим получить доступ к данному ресурсу (scope http://esia.gosuslugi.ru/tech_inf).

Пример запроса списка измененных организаций (вызов сервиса в среде разработки):

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

Б.10 Импорт учетной записи пользователя

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

Рисунок 14. Алгоритм импорта учетной записи в ЕСИА

Для импорта учетных записей система-клиент должна направить в https-адрес REST-API системы ЕСИА запрос методом POST. В запросе должен быть указан ресурс /import.

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

В запрос должен быть добавлен header с ранее полученным маркером доступа, выданный на специальный scope (ext_imp), позволяющий осуществлять автоматический импорт учетной записи пользователя. Данный маркер выдается только доверенным системам, имеющим право импорта пользователей таким образом; выдача маркера осуществляется в рамках модели контроля доступа на основе полномочий системы-клиента (Приложение В.3), т.е. право на запрос такого маркера доступа устанавливается оператором эксплуатации ЕСИА.

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

Пример запроса (вызов сервиса в среде разработки):

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

• пользователь уже зарегистрирован в ЕСИА (подтвержденная учетная запись найдена по СНИЛС, данные паспорта и телефона совпадают);

• некоторые атрибуты не совпадают (учетная запись найдена по СНИЛС, но не все атрибуты совпадают, либо найдена упрощенная учетная запись);

• пользователь ЕСИА успешно подтвержден (найдена стандартная или готовая к подтверждению учетная запись по СНИЛС, данные паспорта и телефона совпадают, найденная учетная запись успешно подтверждена);

• пользователь ЕСИА успешно переподтвержден (найдена УЗ, подтвержденная через Почту России, данные паспорта и телефона совпадают, найденная учетная запись успешно переподтверждена);

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

В ответе передаются следующие параметры:

Далее приводятся варианты ответов сервиса, при завершении операции импорта.

Пример ответа на запрос (пользователь уже зарегистрирован в ЕСИА):

Пример ответа на запрос (пользователь ЕСИА успешно подтвержден):

Пример ответа на запрос (пользователь ЕСИА успешно переподтвержден):

Пример ответа на запрос (создана заявка на регистрацию):

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

Система, используя имеющийся идентификатор заявки на регистрацию пользователя, может узнать статус заявки, а также причину ошибки (при ее наличии). Для получения данных о ходе выполнения проверок система должна выполнить запрос методом GET в https-адрес REST-API системы ЕСИА*(57). Запрос также должен содержать маркер доступа системы. Пример запроса:

В качестве ответа ЕСИА возвращает json с параметрами, указанными в табл. 10.

Таблица 10. Параметры ответа на запрос о статусе проверки данных пользователя

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

ПРИЛОЖЕНИЕ В. СЕРВИСЫ ЕСИА, ОСНОВАННЫЕ НА ПРОТОКОЛЕ OAUTH2.0 И OPENID CONNECT 1.0

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

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

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

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

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

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

В.2 Модель контроля на основе делегированного принятия решения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В.2.2 Получение авторизационного кода

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

Эта ссылка должна содержать следующие обязательные параметры:

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

В случае ошибки сервис авторизации вернет в параметре error код ошибки (например, «access_denied») и не перенаправит пользователя по адресу, указанному в redirect_uri. Перечень возможных ошибок приведен в таблице 11.

В.2.3 Получение маркера доступа в обмен на авторизационный код

Когда авторизационный код получен, система-клиент может сформировать запрос методом POST на https-адрес ЕСИА для получения маркера доступа*(60). В тело запроса должны быть включены следующие сведения:

Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:

При невозможности выдачи маркера доступа возвращается код ошибки (Таблица 11).

В.2.4 Получение нового маркера доступа в обмен на маркер обновления

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

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

В.3 Модель контроля доступа на основе полномочий системы-клиента

В.3.1 Общие принципы

Эта модель контроля предполагает, что система-клиент самостоятельно обращается к сервису авторизации и получает маркер доступа (client-side flow) на основании имеющихся (и зафиксированных в сервисе авторизации) полномочий системы-клиента. Данная модель контроля доступа предполагает, что система-клиент при доступе к защищенному ресурсу непосредственно получает разрешение (в форме маркера доступа) со стороны сервиса авторизации. В общем виде схема взаимодействия выглядит следующим образом:

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

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

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

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

Данная модель контроля доступа проиллюстрирована на рисунке 16.

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

В.3.2 Получение маркера доступа

Для получения маркера доступа система-клиент должна направить по https-адресу сервиса авторизации (ЕСИА) запрос методом POST. Запрос должен содержать следующие сведения:

Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:

При невозможности выдачи маркера доступа возвращается код ошибки (Таблица 11).

В.4 Особенности указания области доступа (scope)

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

В ЕСИА используются следующие типы scope:

1. Данные о субъекте (http://esia.gosuslugi.ru/sbj_inf). Этот scope не параметризуется, т.к. субъект, данные о котором намерена получить система-клиент, явным образом указан в запросе, а также содержится в самом маркере доступа.

2. Данные о пользователе. В системе предусмотрены следующие scope, позволяющие получить данные о пользователе (Таблица 12).

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

Эти scope указываются в формате /scope?param1=value1&param2=value2, где

При запросе у сервиса авторизации ЕСИА маркера доступа на scope http://esia.gosuslugi.ru/id_doc или любого другого scope на получение данных о пользователе не нужно в качестве параметра указывать oid этого пользователя.

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

Scope «id_doc» и «foreign_passport_doc» позволяют получить Гражданство пользователя.

3. Данные об организации. В системе предусмотрены следующие scope, позволяющие получить данные об организации (Таблица 14).

Эти scope указываются в формате /scope?param1=value1&param2=value2, где

Наличие маркера с таким scope позволяет получить информацию о сотрудниках.

4. Данные для идентификации и аутентификации пользователя (openid). Этот scope используется в целях проведения аутентификации пользователя и получения маркера идентификации (см. Приложение В.6 и В.7). Он не параметризуется, т.к. до аутентификации у системы-клиента отсутствует информация об идентификаторе пользователя.

В.5 Сведения о структуре и проверке маркера доступа

Используемый ЕСИА маркер состоит из трех частей:

1. Заголовок (header), в котором содержится общая информация о типе маркера, в том числе об использованных в ходе его формирования криптографических операциях.

2. Набор утверждений (payload / claim set) с содержательными сведениями о маркере.

3. Подпись (signature), которая удостоверяет, что маркер «выдан» ЕСИА и не был изменен при передаче.

Части маркера разделены точкой, так что он имеет вид:

Маркер передается в виде строки в формате Base64url*(61).

Каждая часть маркера содержит набор утверждений (claims) трех типов:

Заголовок (header) содержит описание свойств используемого маркера:

1. Алгоритм шифрования («alg», стандартное обозначение); в настоящее время в ЕСИА поддерживается алгоритм электронной подписи RSA SHA-256, рекомендуемый спецификацией (соответствует значению «RS256»)*(62) и алгоритм электронной подписи ГОСТ Р 34.10-2001 (соответствует значению «GOST3410»);

2. Глобальный тип маркера («typ», стандартное обозначение), который в ЕСИА всегда имеет значение «JWT» (JSON Web Token);

Например, заголовок маркера доступа в ЕСИА будет иметь следующий вид:

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

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

1. Данные о маркере доступа:

— организация, выпустившая маркер («iss»), для маркеров ЕСИА всегда имеет определенное значение, которое совпадает с полем «субъект» используемого сертификата ЕСИА (http://субъект);

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

Соответственно, использовать маркер могут только системы с этой мнемоникой.

2. Данные о субъекте:

— идентификатор субъекта («urn:esia:sbj_id»), в качестве значения указывается oid, этот идентификатор уникален для каждого субъекта, зарегистрированного в ЕСИА;

Пример сообщения (payload) маркера доступа в ЕСИА:

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

Системе-клиенту, использующую механизмы REST и OAuth 2.0 для аутентификации пользователей, рекомендуется осуществлять проверку маркера доступа, используя данные о его подписи. В общем виде эта процедура включает в себя следующие шаги*(63):

1. Осуществление base64url-декодирования первых двух частей маркера. В header указан алгоритм шифрования (параметр alg).

2. Третья часть маркера доступа представляет собой подпись в формате PKCS#7 detached signature в кодировке UTF-8 от значений первых двух частей маркера доступа (HEADER.PAYLOAD). Необходимо осуществить проверку данной электронной подписи с использованием сертификата ключа проверки электронной подписи ЕСИА.

3. Проверка времени выдачи, начала и прекращения маркера.

4. Проверка организации, выпустившей маркер, а также адресата маркера.

В.6 Использование OpenID Connect 1.0 для аутентификации пользователя

В.6.1 Общие принципы

В общем виде схема аутентификация с использованием OpenID Connect 1.0 выглядит следующим образом:

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

— система-клиент отправляет запрос на аутентификацию в адрес сервиса авторизации ЕСИА;

— сервис авторизации аутентифицирует пользователя;

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

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

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

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

— система-клиент проводит валидацию маркера идентификации и извлекает из маркера идентификатор пользователя.

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

В.6.2 Получение авторизационного кода

В.6.2.1 Стандартный режим запроса авторизационного кода

Чтобы получить авторизационный код, система-клиент должна получить разрешение на проведение аутентификации пользователя*(64). Для этого система-клиент должна направить пользователя на страницу предоставления прав доступа в ЕСИА.

Эта ссылка должна содержать следующие обязательные параметры:

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

В.6.2.2 Проверка наличия аутентификации в фоновом режиме

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

Для этого вызывающая ЕСИА система должна использовать параметр prompt запроса на проведение аутентификации со значением «none». Пример запроса:

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

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

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

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

В.6.2.3 Вызов страницы аутентификации пользователя ЕСИА в новом всплывающем окне браузера

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

Для реализации этой возможности вызывающая ЕСИА система должна использовать параметр display запроса на проведение аутентификации со значением «popup». Пример запроса:

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

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

В.6.3 Получение маркера идентификации в обмен на авторизационный код

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

Если запрос успешно прошел проверку, то ЕСИА возвращает ответ в формате JSON:

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

В.6.4 Проверка маркера идентификации

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

1. Проверка идентификатора (мнемоники) ЕСИА, содержащейся в маркере идентификации.

2. Проверка идентификатора (мнемоники) системы-клиента, т.е. именно система-клиент должна быть указана в качестве адресата маркера идентификации.

3. Проверка подписи маркера идентификации (с использованием указанного в маркере алгоритма).

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

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

Детальные сведения о маркере идентификации представлены в Приложении В.7.

В.6.5 Выход из системы (логаут)

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

— протокол запроса должен быть https;

— путь в HTTP-запросе должен быть равен /idp/ext/Logout;

— запрос должен иметь параметр (query param) с именем client_id, содержащий мнемонику обращающейся системы, зарегистрированной в ЕСИА;

— запрос может иметь параметр (query param) с именем redirect_url, содержащий адрес, на который пользователь будет перенаправлен после успешного логаута.

В ЕСИА для интегрированной системы может быть определен параметр system.siteUrl, содержащий URL-адрес системы, на который будет возвращен пользователь после логаута. Redirect_url должен быть подстрокой system.siteUrl.

При обработке запроса производятся следующие проверки:

1. Проверка, что передан обязательный параметр client_id. Если он не передан, то возвращается HTTP-код «400 Bad Request».

2. Проверка, что система с мнемоникой, указанной в параметре client_id, зарегистрирована в ЕСИА. Если система не зарегистрирована, то возвращается HTTP-код «403 Forbidden».

После успешного выполнения этих проверок ЕСИА определяет URL переадресации после успешного логаута:

— Если для системы в настройках ЕСИА не задан параметр system.siteUrl, то запрос после логаута будет направлен на сайт ЕСИА.

— Если в запросе не задан параметр redirect_url, то запрос после логаута будет направлен по адресу, заданному в system.siteUrl.

— Если параметры redirect_url и system.siteUrl не соответствуют друг другу (redirect_url должен быть подстрокой system.siteUrl), то запрос после логаута будет направлен на сайт ЕСИА.

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

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

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

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

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

2) время прекращения действия («exp»), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;

3) идентификатор субъекта («sub»), в качестве значения указывается oid. Этот идентификатор уникален для каждого субъекта, зарегистрированного в ЕСИА, и остается неизменным при последующих аутентификациях; адресат маркера («aud»), указывается client_id системы, направившей запрос на аутентификацию;

4) организация, выпустившая маркер («iss»), указывается URL ЕСИА;

6) внутренний идентифивкатор сессии ЕСИА («urn:esia:sid»);

7) начало блока описания субъекта вызова сессии («urn:esia:sbj»);

12) способ авторизации («urn:esia:amd»), может принимать два значения: «DS» (электронная подпись) или «PWD» (пароль);время выдачи («iat»), указывается в секундах с 1 января 1970 г. 00:00:00 GMT;

13) метод аутентификации («amr», приватное обозначение), может принимать два значения: «DS» (электронная подпись) или «PWD» (пароль);

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

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

ПРИЛОЖЕНИЕ Г. СЕРВИС РЕГИСТРАЦИИ ПОЛЬЗОВАТЕЛЯ И ПОДТВЕРЖДЕНИЯ ЛИЧНОСТИ

Данный сервис ЕСИА поддерживает следующие функции:

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

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

— удаление учетной записи;

— инициирование регистрации подтверждённой учётной записи пользователя в ЕСИА на базе существующей упрощенной;

— регистрация данных о детях пользователя;

— проверка статуса выполняемой операции (по регистрации пользователя / восстановлению доступа)*(68);

— поиск учетной записи.

Г.1 Получение доступа к электронному сервису

Каждый орган/организация для использования программного интерфейса ЕСИА по регистрации пользователей должен:

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

2. Доработать (разработать) свою ИС, в которой будет предусмотрена функция регистрации пользователей ЕСИА.

3. Сгенерировать для ИС криптографические ключи и выпустить на них квалифицированный сертификат ЭП:

— Сертификат должен быть выпущен на юридическое лицо (содержит ОГРН и имя организации).

— Сертификат должен быть выпущен аккредитованным УЦ.

— Требования к ключевому контейнеру определяются эксплуатационной документацией на ИС, которая будет использовать ключи.

4. Зарегистрировать ИС в СМЭВ (согласно регламенту СМЭВ подается заявка на регистрацию ИС).

5. Получить для ИС в СМЭВ права на доступ к сервису ЕСИА в СМЭВ.

6. Зарегистрировать ИС в ЕСИА согласно п. 6 Регламента.

7. Зарегистрировать подключение ИС в тестовом контуре ЕСИА для отработки интеграции согласно п. 9 Регламента.

8. Зарегистрировать подключение ИС в продуктивном контуре ЕСИА для отработки интеграции согласно п. 10 Регламента.

9. Зарегистрировать в ЕСИА Центры обслуживания органа/организации. Для этого можно воспользоваться Технологическим порталом ЕСИА.

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

11. Специалистам Центров обслуживания, которые будут выполнять регистрацию пользователей в ЕСИА, нужно выпустить средства КЭП. В сертификатах обязательно должны быть ОГРН организации (из тех, что получили право выдачи ПЭП), СНИЛС сотрудника.

12. Дать доступ специалистам Центров обслуживания к ИС согласно ее эксплуатационной документации.

Г.2 Регистрация пользователей

Общая схема регистрации пользователя с использованием электронного сервиса включает в себя следующие шаги (Рисунок 17):

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

2. ЕСИА возвращает идентификатор заявки на регистрацию пользователя, а также передает пароль для первого входа.

3. ЕСИА проводит проверку данных пользователя в БГИР, если проверки пройдены успешно, то регистрирует учетную запись.

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

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

Г.2.1 Запрос на регистрацию новой подтвержденной учетной записи

Для инициирования регистрации новой подтверждённой учётной записи пользователя в ЕСИА необходимо вызвать метод «Зарегистрировать подтверждённую учётную запись в ЕСИА с выдачей пароля для первого входа».

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

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

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

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

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

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

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

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

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

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

Г.3 Подтверждение личности пользователя

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

Чтобы подтвердить свою учетную запись, пользователь должен предварительно создать упрощенную (непроверенную) или стандартную (проверенную) учетную запись. Это может сделать любой пользователь, имеющий номер мобильного телефона или адрес электронной почты, используя веб-интерфейс ЕСИА. Подтвержденная учетная запись создается пользователем из упрощенной (непроверенной) учетной записи в результате успешной проверки личных данных пользователя в базовых государственных информационных ресурсах (СНИЛС, ФИО, паспортные данные и др.) и подтверждения личности одним из доступных способов, в частности, посредством обращения в один из Центров обслуживания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Г.6 Запрос на регистрацию подтвержденно учетной записи на базе существующей упрощенной

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

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

В качестве выходных параметров метод возвращает результат выполнения операции (успешно или не успешно).

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

Г.7 Добавление данных о детях пользователя

Для добавления данных о детях в подтвержденную учетную запись пользователя в ЕСИА необходимо вызвать метод «Зарегистрировать данные о детях в подтверждённой учётной записи в ЕСИА».

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

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

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

Для поиска учетной записи пользователя в ЕСИА необходимо вызвать метод «Поиск учетной записи».

В качестве входных параметров метод получает идентификационные данные гражданина.

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

Г.9 Рекомендации по использованию сервиса

Г.9.1 Общие рекомендации

При обращении пользователя в Центр обслуживания*(72) рекомендуется выяснить основную цель обращения, в зависимости от этого выбрать метод сервиса ЕСИА. Основные сценарии представлены в таблице 15

Г.9.2 Рекомендации по выбору способа доставки пароля

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

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

Г.9.3 Рекомендации по сохранению данных пользователя

При формировании запроса на регистрацию пользователя рекомендуется сохранять:

— идентификатор заявки на регистрацию пользователя (requestId)

— все данные, переданные методу «Зарегистрировать подтверждённую учётную запись в ЕСИА с выдачей пароля для первого входа».

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

Г.9.4 Рекомендации по вызову метода «Подтвердить личность гражданина РФ или иностранного гражданина в ЕСИА»

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

При указании контактов необходимо передавать только один тип контакта (email или mobile) для идентификации заявки на подтверждение учетной записи.

Если пользователь не помнит номер мобильного телефона / адрес электронной почты, то можно предложить ему провести регистрацию учетной записи. Для этого следует вызвать метод «Зарегистрировать подтверждённую учётную запись в ЕСИА с выдачей пароля для первого входа».

ПРИЛОЖЕНИЕ Д. НЕРЕКОМЕНДУЕМЫЕ К ДАЛЬНЕЙШЕМУ ИСПОЛЬЗОВАНИЮ ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ ЕСИА

Д.1 Общие сведения

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

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

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

Д.2 Устаревшие утверждения SAML

Д.3 Устаревшие параметры сервиса регистрации

ПРИЛОЖЕНИЕ Е. ЕДИНЫЙ СЕРВИС УПРОЩЕННОЙ ИДЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЕЙ ЕДИНОЙ СИСТЕМЫ ИДЕНТИФИКАЦИИ И АУТЕНТИФИКАЦИИ

В целях идентификации пользователей и проверки корректности информации, которую они предоставляют об имеющихся у них документах, создан и опубликован в СМЭВ электронный сервис «Единый сервис упрощенной идентификации пользователей Единой системы идентификации и аутентификации»*(73). Сервис предназначен для использования финансовыми организациями во исполнение требований Федерального закона от 7 августа 2001 г. № 115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма» и Распоряжения Правительства Российской Федерации от 15 августа 2012 г. № 1471-р.

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

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

В режиме «проверка данных пользователя» выполняются следующие проверки:

— паспорта (соответствия ФИО и паспорта);

— СНИЛС (соответствия ФИО и СНИЛС);

— ИНН (соответствия ФИО и ИНН).

Единый сервис поддерживает следующие функции:

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

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

Е.1 Получение доступа к электронному сервису

Порядок и правила получения доступа к единому сервису упрощенной идентификации пользователей Единой системы идентификации и аутентификации приведен в документе «Регламент информационного взаимодействия Участников с Оператором ЕСИА и Оператором эксплуатации инфраструктуры электронного правительства». Информация содержится в пункте «Порядок согласования права использования Единого сервиса упрощенной идентификации пользователей Единой системы идентификации и аутентификации». Документ доступен по адресу http://minsvyaz.ru/ru/documents/4244/.

Е.2 Проверка данных пользователя

Проверка данных пользователя с использованием электронного сервиса включает в себя следующие шаги:

1. ИС отправляет запрос на проверку данных пользователя, включающий персональные данные пользователя;

2. сервис возвращает идентификатор заявки;

3. сервис инициирует проверку данных пользователя в БГИР;

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

5. сервис возвращает статус операции проверки данных пользователя. Если операция завершена то возвращается статус операции (данные валидны или данные не валидны).

Е.2.1 Запрос на идентификацию и проверку данных пользователя

Для инициирования проверки данных пользователя необходимо вызвать метод «Отправить запрос на проверку данных пользователя (без отправки пользователю запроса на разрешение)».

В качестве входных параметров метод получает персональные данные проверяемого пользователя (серия и номер паспорта, ФИО, СНИЛС, ИНН), необходимые для проведения операции.

В качестве выходных параметров метод возвращает статус выполнения операции (успешно или не успешно), идентификатор заявки на идентификацию пользователя и проверку его данных (requestId), поскольку проверка данных пользователя осуществляется в асинхронном режиме

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*(33) В настоящее время используются следующие коды:

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

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

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

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

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

*(39) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//ctts

*(40) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//ctts/

*(41) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//ctts/

*(42) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//addrs

*(43) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//addrs/

*(44) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//vhls

*(45) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//vhls/

*(46) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//vhls/

*(47) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//invts

*(48) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//invts

*(49) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//invts/

*(50) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//emps/

*(51) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//emps/

*(52) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//grps//perms

*(53) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//grps//perms

*(54) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//brhs

*(55) Сервис доступен по URL https://esia-portal1.test.gosulsugi.ru/rs/orgs//brhs/

*(56) Сервис доступен по URL: https://esia-portal1.test.gosulsugi.ru/rs/sbjs

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

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

*(60) Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te

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

*(62) См.: http://tools.ietf.org/html/draft-jones-json-web-token-10#section-8

*(63) Подробнее см.: 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

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

*(65) Адрес в тестовой среде: https://esia-portal1.test.gosuslugi.ru/aas/oauth2/te

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

*(68) Детальная информация о работе сервиса и получении к нему доступа содержится в Руководстве пользователя электронного сервиса СМЭВ «Сервис регистрации Единой системы идентификации и аутентификации».

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

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

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

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

Обзор документа

Разработаны методические рекомендации по использованию ЕСИА версии 2.20.

Так, уточнено описание электронного сервиса по регистрации пользователей; исключено приложение с описанием электронных сервисов ЕСИА для работы с должностными лицами органов госвласти. Более детально описан механизм аутентификации с использованием OpenID Connect 1.0.

Пересмотрено описание структуры маркера идентификации.

Источник