...

пятница, 13 сентября 2013 г.

Применение ЭЦП в web-шаблонах SAP NetWeaver

Статья посвящена выполненной мной достаточно нетривиальной задаче по интеграции электронной цифровой подписи в веб-шаблоны 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 Реализация хранения данных



Подписи хранятся в плоской таблице «Подписи».

image


База сертификатов – набор из двух плоских таблиц:


image


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


Приостановки – набор возможных приостановок действия ключа. Хранит дату начало, конца и описание приостановки. Также хранит ID приостановленного ключа.


3 Архитектура системы цифровой подписи



Механизм цифровой подписи построен на основе следующих компонентов.

1) ActiveX компонент для доступа к криптографическому API. (CAPICOM)

2) С помощью JS получаем содержимое документа

3) Вызовом метода ActiveX компонента подписать данные.

4) Отправить подпись на сервер (классу ABAP) с целью разместить в базе подписей.

image


CAPICOM – библиотека от MS, предоставляющая интерфейс к крипто провайдерам.

1 – посредством JS кода, происходят обращения к библиотеке CAPICOM

2 – Веб шаблон формирует данные для подписи (XML, описывающий DataProvider).

3 – Полученная подпись, посредством AJAX передается ABAP классу, осуществляющему сохранение подписи в плоскую таблицу.

4 – взаимодействие крипто провайдера с eToken происходит автоматически.


4 Реализация API



image

Класс 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.

image

Синим- компонент «провайдер данных-информация», красным — он же в палитре компонентов, желтым — провайдер данных, поставляющий контент документа


4) Укажем в настройках DATA_PROVIDER_TO_SIGN:

Провайдер данных: Укажем созданную в шаге 2 копию провайдера.

Статус навигации — вывод: Off

Данные отчета: вывод: On


5) Размещаем на форме код

Здесь уже все зависит от вашей фантазии. Не буду постить ВЕСЬ свой код, включающий AJAX, ABAP, JavaScript, оставлю только простенький врапер для CAPICOM, который я сделал на основе примеров с сайта Microsoft.


Код на pastebin


И пример его использования

Подписание



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);
}



This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Комментариев нет:

Отправить комментарий