Pull to refresh

Comments 50

Подключение к ЕСИА бесплатное? Можно ли его интегрировать в свою услугу, например, для авторизации пользователей?
Там скоп документов нужен от организации. Просто к сайту прикрутить нельзя.
Это понятно, процесс подключения бумажный в 21 веке) Но после подключения — будет ли возможность получать данные о владельце учетной записи?
Да, конечно. Посмотрите документ http://minsvyaz.ru/common/upload/metod%5B1%5D.pdf
Только следует учитывать, что не любой организации дадут доступ к ЕСИА. На данный момент это могут делать только госушные организации, банки, финансовые и страховые компании и операторы связи. А остальные — нет.
Черт кроется в деталях. Это где-то описано? Может регулируют каким-то законопроектом с дорожной картой?
Регулируется разными законопроектами и «решениями подкомиссий» минсвязи. Но такого документа, в котором бы прописывалось, что этим можно, а этим нет — такого нет.

Т.е. тут правильнее искать законы и НПА, в которых сказано, кому можно.

Для госов — «ПОЛОЖЕНИЕ о федеральной государственной информационной системе «Единая система идентификации», для операторов связи — положения правительства 758 и 801, для финкомпаний и банков — 115ФЗ.
Список того кому точно можно указан в регламенте подключения (http://minsvyaz.ru/uploaded/presentations/esiareglament29.pdf). Смотрите примечание на странице 32 и потом уже перейти на страницу 95 и смотреть примечание там.
А остальным надо доступ согласовывать, либо через какой-нибудь федеральный НПА, либо через подкомиссию Минсвязи, как уже написал stasmat.
Да, можно в принципе по примерам организаций из формы заявки догадываться, что этим организациям можно, но опять же, там нет ни операторов связи, ни, например, территориальных фондов страхования. Там также написано что удостоверяющий центр может подключаться, но важно отметить, что только государственный.

Возможность работать с ЕСИА как правило пробивается различными «профсоюзами», типа НАУФОР для своеё сферы деятельности. Но во всех случаях это идет через внесение поправок сначала в федеральные НПА, а потом в подкомиссии минсвязи.
Да, все так и есть. Но и Минкомсвязь понять можно. Им не хочется менять каждый раз документ при добавлении нового участника. Проблему решил бы перечень, но, видимо, дело до него никому нет, уж больно редко кто-то «со стороны» жаждет получить доступ к ЕСИА :)
Подключение бесплатное, но есть ограничение по типу организаций. Государственные без проблем, банки тоже могу, а вот с коммерцией — нужно одобрением на правительственной подкомиссии по информатизации.

P.S. долго одобряли, выше уже написали то же самое.
Всё ленился написать про регистрацию OAuth2, а сейчас уже поздно. Точно всё не помню, а доступа к исходникам уже нет. Если у кого есть заинтересованность, пишите. Могу сказать сразу, лучше сначала потренироваться на Вконтакте, Одноклассниках и пр. Логика та же, только накручено ещё.
Спасибо за статью.
Ссылка на example.xml битая.
Надеюсь, статья будет действительно полезна. Ссылку поправил, спасибо
Добавлю пару моментов, с которыми мы столкнулись при подключении заказчика к ЕСИА:
1. SAML протокол доступен ТОЛЬКО для гос. организаций.
2. С февраля 2017 года минсвязь по протоколу SAML уже не подключает.

В общем, пока всё это выяснилось потеряли время. Нам нужно было срочно подключататься, некогда было разбираться в новых регламентах. В итоге нашли готовый модуль подключения к ЕСИА под свою платформу на esia.pro и заодно там с бюрократией минсвязи помогли всё порешать.
Можно, пожалуйста, ссылку на п.2?
Увы, в официальных документах этого нет. Выясняется только на этапе подачи заявки.
Аналогичные комментарии оставляют на 99% форумах, где задаются вопросы по интеграции ИС с ЕСИА, где все сводится к покупке готового решения на вышеуказанном сайте.
Основная цель данной статьи — показать и объяснить пользователям, что, несмотря на всю «бюрократию», подключение ЕСИА не требует каких-то сверхъестественных навыков.
А что касается вашего п.2, не поленился и посмотрел свежую методичку от 10 марта 2017, никто пока не собирался отказываться от стандарта SAML
Я ж говорю, что официально в документах этого нет. И выше еще один комментарий тоже об этом был. По факту, до февраля еще подключали, но ряда фич при этом в SAML не было. Делали запрос в минсвязи, получили такой ответ:
По Вашему обращению INC000001804782 сообщаем: для протокола SAML такой функциональности не предусмотрено, протокол SAML не планируется к развитию и в будущем будет выводиться из эксплуатации ЕСИА.
Вы можете использовать OpenId Connect, у которого предусмотрен механизм скрытой проверки авторизации пользователя.


Помимо «скрытой авторизации» нет также возможности использовать ряд новых полей из профиля в ЕСИА и прочих функций, которые требовались в системе. Сейчас не вспомню сходу, но если нужно могу раскопать.
То, что вы хотите прорекламировать свой сервис все уже поняли:)
К сожалению, не без этого :) Плохая была идея.
Но инфу про САМЛ пишу не ради рекламы, мы тоже с этим протоколом работали.

Если не секрет, вы когда производили подключение по SAML последний раз?
Подключение производили в декабре 2016 года.
Стало даже интересно, насколько далеко вы готовы зайти. Написали вчера в Минкомсвязи. Получили такой ответ:

Ваш запрос SCR#644101 переведен в статус Решен:
Описание решения: Сообщаем вам, что согласно Регламенту информационного взаимодействия Участников с Оператором ЕСИА и Оператором эксплуатации инфраструктуры электронного правительства (http://minsvyaz.ru/ru/documents/4244/) подключение ИС к ЕСИА по протоколу SAML осуществляется.

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

И спасибо большое, что не поленились написать в Минкомсвязи. Очень неприятно, когда продавец продукта тебе врет. Да и бизнес у него не очень идет — пропала ссылка, что они сидят в Ростове, повесили московский номер (мобильный?)… Сейчас продадут тебе «модуль», а завтра нужно будет что-то подкрутить — где найдешь эти Рога и Копыта?
Спасибо за настоящие аргументы.
А не осталось ли у вас чеклиста, по которому выбирали вариант доступа? Хотелось бы посмотреть на остальные плюсы и минусы обоих способов.
Честно говоря, это единственный важный пункт, который стоило добавить к ссылке из статьи (абзац «Если сравнивать 2 подхода, то по факту разницы между ними большой нет...»). У SAML действительно больше недостатков, и они там прописаны.

Хотя еще один плюс, помимо кейса с организациями, могу предложить: подключение по SAML соответствует стандарту. Это не просто слова. Здесь два преимущества:
1) Можно использовать готовые модули — SimpleSamlPHP, OIOSAML, что упрощает разработку. С OAuth такой фокус не пройдет, т.к. Минкомсвязи достаточно сильно исковеркало протокол. Когда мы оценивали разработку, то у нас получилось по цене сопоставимо с продуктом упомянутых ребят, подключающих к ЕСИА.
2) После интеграции по SAML сайт можно будет подключить в будущем не к ЕСИА, а к другому IdentityProvider почти без доработок. Грубо говоря, сейчас вы подключили сайт к ЕСИА, а завтра вы решили внедрить единую систему входа для всех своих порталов. Большинство таких SSO-систем поддерживает SAML.
Если еще что-то вспомню, напишу. И так многовато для понедельника :)
А какие несоответствия есть по OIDC? Я помню что там падало при указании скоупа openid :) Но скоро как раз по нему подключаться, так что собираю всю инфу заранее. Буду премного благодарен.
Извините, пропустил вопрос.
Главная проблема — это то, что client_secret в понимании rfc6749 — это просто строка, тогда как при взаимодействии с ЕСИА client_secret — это подпись запроса. И здесь возникает целый пласт работы с ключами электронной подписи, подписанием каждого запроса и пр.
Ну они на OIDC, то есть используется по идее OIDC#ClientAuthentication. У них подпись самого запроса? Или подпись jwt?
В ЕСИА client_secret – это подпись запроса в формате PKCS#7 detached signature от значений нескольких параметров запроса (scope, timestamp, client_id, state).
Мдя уж. Сложно было им по спеке то сделать :(
И еще одно обращение нашел.

Ваш запрос SCR#472512 переведен в статус Решен:
Описание решения: Развитие протокола SAML уже прекращено, вывод из эксплуатации рассматривается владельцем системы ФГИС ЕСИА -Минкомсвязью России. Сроки не определены.

Это был ноябрь 2016.
В регламенте сейчас об этом во множестве мест написано. Будет прекращено подключение с 1.1.2018.
https://github.com/fr05t1k/esia
оставлю это здесь, вдруг кому-нибудь пригодится, как мне в свое время.

Только надо уточнить, что saml предназначен только для госсистем. Да и то по спец связям. Иначе oauth.

Никаких спец. связей. Просто нужно быть государственной организацией.
Будь осторожны с сертификатами, у нас постоянно боком выходило из-за того что тестовый сертификат не правильно генерился
Что Вы имеете ввиду под «тестовый сертификат не правильно генерился»?
Кодировка нашего сертификата не проходила на ЕСИА -в Base64 обязательна
А еще эта чудесная ЕСИА прячет ошибку авторизации в верстку страницы с ошибкой (не обычную, а например о мто что токен просрочен). И нигде об этом не написано. А еще чтобы получить данные об организациях пользователя нужно два редиректа на ЕСИА, что в свою очередь повлияло на то что мы отказались от OAuth и взяли SAML 2.0.
Делал интеграцию авторизацию через ЕСИА на WebSphere Portal, самописный модуль (готовые модули в production? не-не)
В смысле в разметку? Можете пример привести? А то скоро то же интегрироваться с ними.
Была простая бага, на сервере где формировался запрос время отставало на 2 часа от «точного», ЕСИА отвечала «Ошибка авторизации», а если открыть верстку, то там будет 3-4 hidden инпута, где будет немного больше информации об ошибке, точнее о том что ошибка именно в проверки безопасности. При других багах на нашей стороне ошибки были также спрятаны в верстку, например о том что токен безопасности просрочен.
Именно в верстку или json? По спеке описание опционально. Например вот или вот. И ошибки могут быть либо сериализованы в json либо при некоторых flow в query string.
А у них есть проблемы с серверным временем?
Говорю же, в HTML верстку, в hidden input. Это ошибка именно IdP, не протокола. Проблема с серверным временем была у меня, не у них.
Спасибо за информацию.
Да, про то, что получить данные об организации получить проще и быстрее через SAML — подтверждаю. Написал об этом выше.

К сожалению, статья уже не актуальна:


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

Articles