Применение ЭЦП в 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);
    }
    
    
    Поделиться публикацией

    Комментарии 1

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое