Интеграция и API ЭЦП на предприятии

Аутентификация по цифровым сертификатам


Всем привет!

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

Внедрение аутентификации по цифровым сертификатам заманчиво по следующим причинам:

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

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

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

Доработка веб интерфейса достаточно тривиальна, преимущественно сводится к дизайну страницы входа в систему и нескольким обращениям к NCALayer (либо KAZTOKEN mobile), детали будут приведены ниже.

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

API SIGEX позволяет значительно упростить реализацию серверных компонентов - все, что связано с управлением блоками уникальных данных и проверкой цифровых подписей, SIGEX берет на себя:

Схема аутентификации

Этапы:

  • (1) - Клиент запрашивает страницу входа у сервера ИС.
  • (2) - Сервер ИС запрашивает у SIGEX блок уникальных данных с помощью вызова POST /api/auth - аутентификация, подготовительный этап - получение блока случайных данных. Выдачей блоков уникальных данных занимается SIGEX для предотвращения атак типа Повтор.
  • (3) - SIGEX предоставляет блок уникальных данных.
  • (4) - Сервер ИС передает блок уникальных данных клиенту для подписания.
  • (5) - Клиент подписывает блок уникальных данных (в большинстве сценариев с помощью NCALayer или KAZTOKEN mobile).
  • (6) - Клиент передает серверу ИС подписанный блок уникальных данных.
  • (7) - Сервер ИС передает подписанный блок уникальных данных в SIGEX для проверки с помощью вызова POST /api/auth - аутентификация.
  • (8а) - SIGEX проверяет подписанный блок уникальных данных и, в случае выявления каких-либо проблем, возвращает серверу ИС ошибку.
  • (8б) - SIGEX проверяет подписанный блок уникальных данных и, в случае успешной проверки, возвращает серверу ИС результат аутентификации содержащий данные полученные из сертификата клиента (ФИО, ИИН, БИН и т.д.).
  • (9а) - В случае ошибки аутентификации сервер ИС отображает клиенту страницу ошибки аутентификации.
  • (9б) - В случае успешной аутентификации сервер ИС сверяется со списком контроля доступа (список контроля доступа может быть реализован как в самой ИС, так и в отдельной системе, такой как LDAP каталог) и проверяет разрешен ли данному клиенту доступ в ИС. Идентификацию клиента рекомендуется осуществлять по ИИН, либо по связке ИИН + БИН в том случае, если необходимо идентифицировать клиента как сотрудника определенной организации.
  • (10а) - В том случае, если клиенту разрешен доступ в ИС, сервер ИС отображает клиенту интерфейс ИС.
  • (10б) - В том случае, если клиенту не разрешен доступ в ИС, сервер ИС отображает клиенту страницу ошибки авторизации.

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

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

  • доработка дизайна страницы входа в систему;
  • взаимодействию с NCALayer (либо KAZTOKEN mobile, но тут дорабатывать ничего не нужно, так как он повторяет API NCALayer).

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

Взаимодействие с NCALayer (либо KAZTOKEN mobile) выглядит следующим образом:

  • отправить запрос kz.gov.pki.knca.commonUtils.getActiveTokens который вернет перечень типов подключенных аппаратных носителей ключевой информации;
  • в том случае, если ответ kz.gov.pki.knca.commonUtils.getActiveTokens свидетельствует о том, что обнаружены аппаратные носители, то разумно в следующем запросе указать тип аппаратного носителя для использования, иначе указывать зарезервированный для файловых хранилищ тип "PKCS12";
  • отправить запрос kz.gov.pki.knca.commonUtils.createCAdESFromBase64 с указанием выбранного на предыдущем этапе типа хранилища, параметром keyType установленным в "AUTHENTICATION", блоком уникальных данных в качестве подписываемых данных и параметром attached установленным в false;
  • полученные подписанные данные отправить SIGEX.

В случае использования нового модуля NCALayer (либо KAZTOKEN mobile) kz.gov.pki.knca.basics, взаимодействие проще:

  • отправить запрос kz.gov.pki.knca.basics.sign с блоком уникальных данных в качестве подписываемых данных;
  • полученные подписанные данные отправить SIGEX.

А еще проще использовать JS библиотеку с открытым исходным кодом https://github.com/sigex-kz/ncalayer-js-client.

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

Благодарим за внимание!

Разработано в ТОО "Множество" в 2024 году