Здравствуйте. Уже несколько недель хожу вокруг да около интеграции. Перечитал кучу ресурсов, кучу форумов, и все попытки разобраться разбиваются наглухо об недостаточность информации..
Из того что я понял:
есть два шага интеграции ЕСИА. Это технический и организационный.
Организационным шагом будет получение ЭЦП на руководителя, регистрация в госуслугах этого руководителя, добавление организации в профиль руководителя, авторизация в организацию, добавление интернет портала в личный кабинет юридического лица, получение мнемоники для технических запросов.
В техническом моменте указаны урлы запросов, набор данных, и ответ от сервера.
По документации что от ЕСИА я понял что для запросов есть два варианта: SAML и OpenID. Первый вроде как не доступен, и можно только через второй способ делать запросы.
Но фактический весь алгоритм ломается еще на этапе добавления интернет портала в личный кабинет организации. Нигде нет никаких подробных инструкций как это сделать. В руководстве сказано что нужно добавить, но как - не понятно. Не говоря уже про получение мнемоники..
С технической частью тоже не получается разобраться. Для метода SAML есть классы для работы в PHP, но им всем нужно отдавать открытый и закрытый ключ ЭЦП. В дебрях этой истории крутится докер контейнер, который подписывает электронной подписью запросы. Но из ЭЦП сейчас так просто не добыть закрытый ключик, подозреваю именно по этому данный метод в официальной документации ЕСИА помечен как устаревший.
Как работать с OpenID вообще не понятно. Гипотетический это должен быть REST, с какой-то авторизацией, например basic auth. Но опять таки, по официальной документации не понятно..
Подскажите пожалуйста, кто-то последнее время сталкивался с подобной задачей?
Вот за ссылку на апи грандиозная благодарность. Стыбзил от туда сваггер, и все с технической частью стало понятно. Не понятно только для чего автор статьи использовал крипту, и планировал ее упаковать в докер. В документации явно сказано:
– подпись запроса в формате PKCS#7 detached signature
в кодировке UTF-8 от значений четырех параметров HTTP-запроса: scope,
timestamp, clientId, state (без разделителей). должен быть
закодирован в формате base64 url safe. Используемый для проверки подписи
сертификат должен быть предварительно зарегистрирован в ЕСИА и привязан
к УЗ системы-клиента в ЕСИА. ЕСИА использует сертификаты в формате
X.509 и взаимодействует с алгоритмами формирования электронной подписи
ГОСТ Р 34.10-2012 и криптографического хэширования ГОСТ Р 34.11-2012;
Но в апи что вы скинули указана другая информация:
хабр скушал теги и не дает отредактировать комментарий чтобы исправиться)
используй кнопку </>
Стыбзил от туда сваггер, и все с технической частью стало понятно. Не понятно только для чего автор статьи использовал крипту, и планировал ее упаковать в докер. В документации явно сказано:
запрос на получение токена доступа что в статье на хабре, что в описании апи один и тот же. генерировать client_secret вручную в твоем случае не нужно
