Статья посвящена выполненной мной достаточно нетривиальной задаче по интеграции электронной цифровой подписи в веб-шаблоны SAP (Business Explorer Web Application), работающие в SAP NetWeaver.
Заранее извиняюсь, если в статье будут допущены ошибки в терминологии или в логике.
Общие сведение об ЭЦП можно получить в википедии ЭЦП
В чем заключалась задача
Есть SAP NetWeaver в роли хранилища данных Business Warehouse.
Все данные хранятся в кубах. В кубах же хранятся документы. Документом, по сути, является набор строк куба, имеющих одинаковый признак – номер документа. Работа с данными построена на базе веб-шаблонов Business Explorer Web Application. Содержимое документов отображаются в компоненте analisys item.
Несколько слов для незнакомых с Bex Web. Технология веб-шаблонов (веб форм) по сути напоминает собой ASP.NET. В дизайнере создаешь макет формы, используя компоненты, схожие с ASP (dataGrid, button и прочее). Навешиваешь с помощью мастеров обработчики событий (это могут быть определенные команды или произвольный ABAP код). При запуске веб-формы – она обрабатывается на сервере и клиенты отдается HTML страничка с JS. Реакция на действия пользователя – производиться на стороне сервера при обновлении страницы. В коде веб-шаблона обычно нет необходимости генерировать HTML, как в PHP.
В некой web-форме пользователи вводят данные в таблицу, представленную analisys item. Введенные данные сохраняются в куб. После ввода данных пользователь должен поменять их статус (например, со статуса «Новый» на «Обработано»: перевод статуса происходит с помощью функции repost по значениям признака хранящего статусы данных; этот признак также находится в этом же кубе).
Так вот, необходимо подписывать введенные данные с помощью ЭЦП после ввода/сохранения данных и перед тем, как пользователь переведет эти данные со статуса «Новый» на «Обработано» (подписывать должен тот пользователь, который ввел данные).
Поиск в сети показал, что использовать ЭЦП не так то просто, как хотелось бы. В большинстве стран существуют собственные законодательные акты, регулирующие применение средств криптозащиты. Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой подписи»
В частности устанавливаются алгоритмы, которые должны применяться при шифровании и генерации подписи. Например, алгоритм формирования и проверки электронной цифровой подписи ГОСТ Р 34.10-2001
Конечно же, не имеет смысла самим пытаться реализовать данные алгоритмы, поэтому смотрим, что предлагается на рынке.
Например, решения «ЛИССИ»
http://www.lissi.ru/solution/
Позиционируют себя спасителями на белом коне для SAP’овцев.Комплекс софта от них обойдется в сумму, превышающую 300 000 рублей. Программное обеспечение представляет собой API для продуктов SAP, обращаться к которому можно посредством ABAP.
Проблема в том, что данные продукты подразумевают подписание данных посредством кода ABAP. На клиенте же мы имеем только веб-страницу c JS. Исполнить код ABAP можно только на сервере, например с помощью AJAX запроса. Но возникает проблема – закрытый ключ пользователя доступен только на клиенте. Его пересылка на сервер не должна осуществляться. Решение «ЛИССИ» подразумевает работу на клиентской машине полновесного, не тонкого, клиента SAP, в котором возможно выполнение ABAP.
Поэтому я отказался от готовых решений и реализовал ЭЦП через CAPICOM CAPICOM
Реализация ЭЦП
Здесь описание того, как реализовал ЭЦП
1 Порядок применения ЭЦП
1) Администратор безопасности регистрирует сертификат в базе сертификатов. Сертификат необходимо получить от подлинного удостоверяющего центра.
2) Пользователь работает в системе, создает документ и подписывает его, используя свой секретный ключ на внешнем носителе. При этом:
а) Создается «слепок» документа (выбирается все его содержание).
б) Над содержимом производятся криптографические операции подписания, в результате получаем подпись.
в) Из сертификата подписывающего извлекается отпечаток и сравнивается с отпечатком, зарегистрированным на этого пользователя. В случае совпадения – подпись сохраняется в базе, иначе подпись отменяется.
3) При последующих просмотрах документа, подпись проверяется при открытии документа. Подпись извлекается из БД. Над подписью и содержимым документа проводятся криптографические операции верификации подписи.
4) Администратор безопасности может добавлять сертификаты пользователей в базу сертификатов, приостанавливать временно или постоянно их действие.
2 Реализация хранения данных
Подписи хранятся в плоской таблице «Подписи».
База сертификатов – набор из двух плоских таблиц:
Ключи – собственно сертификаты. В таблице храниться привязанный к ключу пользователь, дата начала и конца действия ключа, сам ключ, статус (блокирован или нет), описание.
Приостановки – набор возможных приостановок действия ключа. Хранит дату начало, конца и описание приостановки. Также хранит ID приостановленного ключа.
3 Архитектура системы цифровой подписи
Механизм цифровой подписи построен на основе следующих компонентов.
1) ActiveX компонент для доступа к криптографическому API. (CAPICOM)
2) С помощью JS получаем содержимое документа
3) Вызовом метода ActiveX компонента подписать данные.
4) Отправить подпись на сервер (классу ABAP) с целью разместить в базе подписей.
CAPICOM – библиотека от MS, предоставляющая интерфейс к крипто провайдерам.
1 – посредством JS кода, происходят обращения к библиотеке CAPICOM
2 – Веб шаблон формирует данные для подписи (XML, описывающий DataProvider).
3 – Полученная подпись, посредством AJAX передается ABAP классу, осуществляющему сохранение подписи в плоскую таблицу.
4 – взаимодействие крипто провайдера с eToken происходит автоматически.
4 Реализация API
Класс Signer – реализует пользовательские методы –
Подписать, проверить подпись, получить последнюю подпись
Класс CryptoProvider – враппер для Capicom.
ZCL_AJAX_DIG_SIGN – реализация интерфейсных методов через Ajax.
Z_DIGITAL_SIGNER – реализация методов сохранения и поиска подписи, методов проверки действительности публичного ключа по базе ключей.
5 Дополнительно словесное описание
Рассмотрим порядок подписанияпроверки документа.
Пользователь жмет на форме кнопку «Утвердить(сохранить) документ». JS собирает с с html кода шаблона контент документа, предварительно выгруженный туда. Обращается к CAPICOM, который просит у человека выбрать нужный сертификат. При выборе сертификата сделанного под криптоПро специально для работы в системе – CAPICOM обратиться к провайдеру КриптоПРО, тот же попросит токен с закрытым ключом. Когда токен вставят – контент документа будет подписан. Подпись по AJAX кидается в BSP приложение, оно передает подпись в интерфейсный класс Z_DIGITAL_SIGNER. Класс проверит сертификат из подписи, факт того, что именно такой сертификат привязан к данному залогинившемуся пользователю. В случае успеха проверки – запишет подпись в базу подписей. На форме произойдут изменения – появиться отметка о успешной подписи.
При открытии документа другим пользователем –появиться статус подписания. Это произойдет следующим образом. JS по AJAX запросит подписи для документа, получит подпись (априорно – она сделана нужным человеком и подпись сделана сертификатом из базы разрешенных сертификатов). Затем js дергает CAPICOM — метод «верификация подписи» с параметрами «подпись» и «контент документа». Если с документом и подписью все в порядке – метод вернет true, следовательно, документ подписан и корректен.
Также есть GUI для администратора безопасности – ведение базы активных сертификатов.
Подключение ЭЦП к веб-шаблону
1) подключить в XHTML веб шаблона ActiveX компонент CAPICOM, например
<object id="CapicomObj" codebase="bwmimerep:///sap/bw/mime/Customer/JS/bin/capicom.cab" classid="clsid:A996E48C-D3DC-4244-89F7-AFA33EC60679" VIEWASTEXT="" />
2) Создать новый провайдер данных с тем же запросом, что и основной. То есть, сделать копию провайдера. Таким образом получим выгруженный документ в HTML, который будем подписывать. Нельзя подписывать провайдер, который выводит документ в таблицу пользователя, потому что, при сортировки или фильтрации таблицы — данные в провайдеры будут меняться, а нам нужен документ в начальном виде.
3) Разместить на форме компонент «провайдер данных-информация».
Назовем его DATA_PROVIDER_TO_SIGN.
Синим- компонент «провайдер данных-информация», красным — он же в палитре компонентов, желтым — провайдер данных, поставляющий контент документа
4) Укажем в настройках DATA_PROVIDER_TO_SIGN:
Провайдер данных: Укажем созданную в шаге 2 копию провайдера.
Статус навигации — вывод: Off
Данные отчета: вывод: On
5) Размещаем на форме код
Здесь уже все зависит от вашей фантазии. Не буду постить ВЕСЬ свой код, включающий AJAX, ABAP, JavaScript, оставлю только простенький врапер для CAPICOM, который я сделал на основе примеров с сайта Microsoft.
И пример его использования
Подписание
SignerProv = new CryptoProvider(this.CapicomObj);
if (SignerProv.IsCAPICOMInstalled())
{
SignerProv.Init();
Sign = SignerProv.SignedData(DataToSign);
}
Проверка подписи
SignerProv = new CryptoProvider(this.CapicomObj);
SignerProv.VerifySert = true;//false – если не надо проверять сам сертификат на подлинность
if (SignerProv.IsCAPICOMInstalled())
{
var SRes = SignerProv.VerifySig(ContentToVerif, SignToVerify);
}
Автор: alexus_ru
