Защита при помощи WebSphere RFID Information Center 1.0

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Исходные тексты примера Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Волльшайд Дирк, инженер по программному обеспечению, IBM

18.06.2007

IBM® WebSphere ® RFID Information Center (RFIDIC) представляет собой репозитарий данных, связанных с ярлыками радиочастотной идентификации (radio frequency identification, RFID) и контекстом событий, например, подробные сведения о маркированных продуктах или местоположении и позиции сенсорных элементов RFID. RFIDIC реализует стандарт EPCglobal для Information Services электронных кодов продуктов (electronic product code, EPC / EPC Information Services, EPCIS). Этот стандарт определяет репозитарий RFID-данных и сервисы (протоколы и интерфейсы) доступа к данным. Одной из отличительных функций RFIDIC является его гибкость и простота использования защитной среды. Стандарт позволяет владельцам системы EPCIS безопасно собирать RFID-данные и использовать полученную информацию совместно со своими торговыми партнерами в цепочке поставок. RFIDIC обеспечивает связь с криптографической защитой и групповое управление данными на ячеечном уровне на основе правил.

В этой статье показано, как разработчик ПО может настроить правила защиты таким образом, чтобы данные, передаваемые между партнерами в цепочке поставок, были доступны только в рамках служебной необходимости. Также представлен защитный сценарий, использующий RFIDIC. Разработчики могут использовать этот сценарий или изменять его в соответствии со своими требованиями.

Введение

Программный продукт IBM WebSphere RFIDIC предназначен для управления данными, связанными с EPC, например, RFID-данными сенсорных элементов, и основными данными, например, данными по физическому положению и данными продуктов, связанными с EPC.

Перед тем как применять функции безопасности RFIDIC, ознакомьтесь с данной статьей, представляющей вводную информацию по управлению RFID-данными.

Стандарт EPCIS и EPC

Термин EPC обозначает семейство схем кодирования ярлыков RFID. Это семейство разработано в соответствии с потребностями различных отраслей промышленности и гарантирует уникальность всех ярлыков, совместимых с EPC. Во всех кодах EPC имеется заголовок, определяющий применяемую схему кодирования. А это, в свою очередь, определяет длину, тип и структуру EPC. Как правило, схемы кодирования EPC содержат серийный номер, предназначенный для уникальной идентификации отдельного объекта. Пример кода EPC - "urn:epc:id:sgtin:1234567.654321.999", где "1234567" - идентификатор изготовителя, "654321" - класс продукта и "999" - серийный номер.

Технология RFID и схемы EPC составляют основу для новых приложений отслеживания местонахождения разнообразных физических компонентов, но чаще всего для отслеживания различных продуктов. Сторонам для сбора и совместного использования данных с целью увеличения ценности бизнеса требуются новые механизмы выполнения запросов к отслеживаемым данным. Помимо реализации бизнес-целей, компании смогут совместно использовать данные, если инфраструктура использования данных будет масштабируемой, защищенной и простой в использовании.

Консорциум EPCglobal разработал промышленные стандарты применения RFID-технологии в цепочках поставок. Сетевая архитектура EPCglobal описывает компоненты и интерфейсы обмена информацией, связанной с EPC, между серверами, на которых находятся сведения об объектах, определяемых номерами EPC. Этими серверами предоставляется один из таких компонентов - EPCIS. RFIDIC представляет собой реализацию EPCIS.

EPCIS обеспечивает доступ к репозитарию с данными о событиях и основными данными. Данные о событиях накапливаются в процессе выполнения бизнес-процессов и регистрируются с помощью интерфейса регистрации EPCIS для очередей сообщений. Эти события представлены в XML-формате и создаются регистрирующими приложениями или промежуточным ПО, например, IBM WebSphere RFID Premises Server, связанным со считывающими устройствами. Информация о событиях, накопленных в EPCIS, доступна для запросов при помощи интерфейсов запросов EPCIS.

Основные данные являются дополнительными и описывают контекст интерпретации данных о событиях. Эти данные доступны для запросов при помощи интерфейса управления запросами EPCIS, но в текущем стандарте EPCIS 1.0 не заданы способы ввода основных данных в систему. Другим интерфейсом запросов является интерфейс обратного вызова запросов для протоколов HTTP, HTTPS и Applicability Statement 2 (AS2). Этот интерфейс реализован получателем результатов подписки. AS2 представляет собой спецификацию транспортного протокола Интернет и, как правило, используется для отправки сообщений электронного обмена данными (EDI, Electronic Data Interchange).

В соответствии со спецификацией стандарта EPCglobal EPCIS, события, зарегистрированные EPCIS, как правило, отвечают на четыре основных вопроса: что, когда, где и почему. Код EPC собственно принадлежит к первой категории, поскольку указывает на то, что произошло. Поля данных eventTime и recordTime отвечают на второй вопрос, а поля readLocation и bizLocation - на третий. Атрибутом четвертой категории является "bizStep", описывающий бизнес-контекст. Примеры идентификаторов для этого поля данных указывают на "отгрузку" или "получение" объектов. Другим атрибутом четвертой категории является "action". Этот атрибут указывает тип операции, примененной к объекту, связанному с EPC. Как правило, события пересылаются из систем промежуточного ПО, например, IBM WebSphere RFID Premises Server, которые отфильтровывают и преобразуют исходные данные о событиях, поставляемые сенсорными элементами, такими как считывающие устройства RFID или сканеры 1D- или 2D-штрихкодов. Поэтому типовым значением атрибута action является OBSERVE. Другие значения включают ADD и DELETE, используемые для различных операций. Одним из примеров является объединение, когда набор EPC связывается с другим EPC. Объединение выполняется в случае, если объекты с RFID-ярлыками упакованы в контейнер, который также промаркирован с помощью RFID-чипа. Другим примером является ввод в действие новых объектов в цепочке поставок (ADD) и вывод из эксплуатации, как, например, при уничтожении в компакторе (DELETE). Схему событий можно расширить за счет дополнительных полей, связанных с бизнесом. Например, считывающее устройство может регистрировать температуру или радиоактивность объекта.

<ObjectEvent>
    <eventTime>2007-01-26T10:10:29.342Z</eventTime>
    <epcList>
        <epc>urn:epc:id:sgtin:1234567.000015.4</epc>
    </epcList>
    <action>OBSERVE</action>
    <bizStep>Receiving</bizStep>
    <disposition>Processing</disposition>
    <readPoint>
        <id>urn:epc:id:sgln:0503030.0623.39</id>
    </readPoint>
    <bizLocation>
        <id>urn:epc:id:sgln:0614141.07346.43</id>
    </bizLocation>
    <batchNumber>218</batchNumber>
</ObjectEvent>

EPCIS может запрашиваться другими системами EPCIS, системами извлечения-преобразования-загрузки (ETL, extract-transform-load), извлекающими данные из EPCIS и импортирующими их в хранилище данных для приложений бизнес-логики, или другими пользовательскими приложениями, непрерывно отслеживающими события. EPCIS включает интерфейс для выполнения гибких запросов, а также для передачи "постоянных" запросов, периодически доставляющих новые результаты.

Стандарт EPCglobal для EPCIS не требует принудительной авторизации запросов с использованием EPCIS Query Control API. Однако, в нем предполагается несколько способов реагирования EPCIS и предоставления авторизации. Среди этих действий, описанных в стандарте и сформулированных с использованием предиката "may (может)", имеются следующие:

• Сервис может полностью отклонить запрос при помощи ответа с SecurityException. Метод управления обнаружением RFIDIC реализует это предположение за счет предоставления специальных правил авторизации, назначающих право на выполнение определенных типов запросов для заданных групп пользователей;
• Сервис может предоставлять меньше данных, чем запрошено. Это реализуется методом, используемым RFIDIC, как часть условий, которые можно выразить в правилах обнаружения для отфильтровывания нежелательных объектов результатов. В частности, разрешено выражать условия с использованием основных данных;
• Сервис может скрывать информацию. Опять же, метод, используемый RFIDIC, реализует это как часть правил обнаружения, где атрибуты (событий или основных данных) определяются таким образом, что могут отображаться в результатах запросов.

Обзор продуктов RFIDIC

WebSphere RFIDIC представляет собой реализацию спецификации EPCIS. Также имеется несколько усовершенствований, выходящих за рамки спецификации.

Реализованные и поддерживаемые интерфейсы:

• Интерфейс регистрации для очередей сообщений (JMS по MQ);
• Интерфейс управления запросами для HTTP и HTTPS;
• Интерфейс обратного вызова запросов для HTTP, HTTPS и AS2;
• XML-схемы основных запросов и событий.

Функции RFIDIC:

• Поддержка импорта и ссылок на основные данные, например, продуктов, местоположений, их иерархий и категорий;
• Гибкий механизм определения расширений атрибутов для схем событий, продуктов и местоположений;
• Определение защиты на основе правил;
• Расширяемый механизм выполнения пользовательской проверки зарегистрированных компонентов и обработка сбоев проверки;
• Способ определения запросов к системе, более эффективных в сравнении с простыми запросами, определенными в спецификации EPCglobal;
• Пользовательские интерфейсы для просмотра основных данных и событий и для управления сбойными событиями;
• Alphablox в качестве инструмента создания отчета.

RFIDIC поддерживает импорт продуктов и основных данных местоположения и их объединение с данными о событиях. Основные данные можно экспортировать из таких систем, как IBM WebSphere Product Center или из наследуемых систем хранения данных о продуктах и местоположении. Разработчик системы может определить атрибуты продуктов и местположения в формате метаданных. Отношения между этими объектами могут представлять собой иерархию, наборы или категории. Моделирование нескольких иерархий, наборов и категорий является концепцией, расширяющей спецификацию EPCglobal относительно основных данных.

Для различных отраслей можно расширить спецификацию EPCIS для определения собственных типов событий, EPC и расширений событий. Имеется набор стандартных событий, например, ObjectEvent и TransactionEvent, но система позволяет определить новые типы событий с собственным набором атрибутов. У стандартных событий и основных данных могут иметься расширенные атрибуты, различные в разных системах. Примерами таких расширений являются название улицы для местоположения или уникальный идентификатор микросхемы в событиях, отчеты о которых предоставляются считывающим устройством RFID. Расширения для событий и MDM-данных определены в файле метаданных RFIDIC. Метаданные используются при создании схемы базы данных для событий регистрации и запросов. Если событие содержит не описанный в метаданных атрибут, RFIDIC регистрирует это событие, но рассматривает этот атрибут как неожиданный. Этот атрибут сохраняется в событии базы данных, хотя он не соответствует предварительно заданной схеме событий и базы данных.

Систему RFIDIC можно сконфигурировать для проверки атрибутов событий относительно имеющихся основных данных во время регистрации. Например, атрибут readPoint проходит тест, если соответствует одному из импортированных местоположений считывающего устройства. Если тест неудачен, событие сохраняется как неудачное и может снова передаваться позднее после импорта местоположения. Пользовательский интерфейс Failed Event позволяет пользователям просматривать неудачные события и выбирать соответствующее действие.

Спецификация EPCglobal также позволяет определять собственные форматы EPC в различных отраслях промышленности. Зачастую в различных компаниях для продуктов и местоположений используются разные идентификаторы. Примеры идентификаторов продуктов - "SKU123" или "ISBN67870." Идентификаторы для основных данных в RFIDIC называются внешними идентификаторами и назначаются заказчиками. Система RFIDIC также назначает этим объектам собственные идентификаторы, которые называют внутренними. Для объединения EPC и основных данных необходимо создать специальный компонент кода системы, называемый обработчиком (handler), предназначенный для интерпретации EPC и поиска соответствующего объекта MDM с внешним идентификатором. Этот фрагмент кода требуется, например, для преобразования GTIN в ISBN. Сбой во время поиска рассматривается как сбой события (см. описание выше). Дополнительное преимущество заключается в хранении в базе данных только внутренних идентификаторов вместо полных EPC.

Часто в системах используются различные требования для действий, предпринимаемых при регистрации событий. Это может быть дополнительная проверка событий, не включенных в проверку схемы, обновление товарно-материальных запасов или уведомление пользователей о поступлении определенных типов продуктов. Для согласования таких действий система RFIDIC использует при регистрации IBM Tivoli Directory Integrator (TDI) . TDI позволяет пользователям определить конвейер, включающий действия, предпринимаемые при регистрации события. В конвейере объединены закодированные действия RFIDIC (коннекторы), например, считывание событий из MQ (коннектор MQ), их анализ (коннектор событий) и сохранение в базе данных (коннектор базы данных) или коннекторы, связанные с системой, например, указанные выше. TDI также обеспечивает масштабируемость выполнения этих шагов в многопоточной среде.

Компонент запросов системы RFIDIC реализует интерфейс управления запросами, состоящий из синхронного и асинхронного интерфейса запросов. Оба интерфейса могут использоваться в качестве механизма доставки для протоколов HTTP, HTTPS и AS2. В асинхронном режиме запрос передается для более позднего и, возможно, повторного выполнения. В синхронном режиме результаты запроса возвращаются немедленно. В системе RFIDIC правила защиты применяются к обоим режимам. Язык запросов, определенный в спецификации EPCIS, позволяет использовать в запросах только простые предикаты. Если разработчику системы необходимо использовать более сложные или пользовательские запросы, можно использовать системный механизм запросов RFIDIC. Поддерживаются два типа запросов: системные запросы событий, возвращающие только события, и ответные системные запросы, которые могут возвращать любые данные, отличные от событий, или агрегированные результаты. Оба типа запросов определены в файле SolutionQueries.xml. Механизм ответных запросов представляет собой расширение стандартного механизма запросов. Ответные системные запросы, как и стандартные запросы, выполняются в соответствии с правилами защиты. Но в данный момент они не управляются данными.

В состав системы RFIDIC входят три пользовательских интерфейса: браузер данных (Data Browser), пользовательский интерфейс неудачных событий (Failed Event UI) и редактор правил защиты (Security Policy Editor), доступ к которому выполняется из Web-браузера. Редактор правил защиты используется разработчиками для создания правил защиты. Далее этот вопрос рассматривается подробнее. Браузер данных позволяет создавать запросы, подобные запросам в спецификации EPCIS, и сохранять их для дальнейшего применения. Результаты запросов могут быть представлены в формате HTML или в виде файлов Microsoft® Excel. Браузер данных можно использовать для проверки входящих событий и выполнения гибких запросов. Его также можно использовать для проверки влияния новых или измененных правил защиты. Для разработки более сложных требований к созданию отчетов можно использовать Alphablox. Помимо запросов к репозитарию EPCIS браузер данных позволяет отображать основные данные. Например, можно просмотреть иерархию продуктов и местоположений (если она доступна).

Пользовательский интерфейс Failed Event служит для просмотра неудачных событий и для их повторной отправки или удаления в зависимости от сущности сбоя. Также имеется интерфейс Failed Event API, который можно применять для обработки неудачных событий без вмешательства пользователей.

Функция Shipment Verification представляет собой компонент RFIDIC, который можно установить отдельно для обработки счетов на отгрузку между грузоотправителем и грузополучателем. В этом сценарии грузоотправитель отправляет розничному продавцу предварительные уведомления об отгрузке, а грузополучатель отправляет обратно грузоотправителю приемные квитанции. Одно из преимуществ данной функции заключается в возможности отслеживания доставки. Например, можно отследить время доставки и определить потенциальные потери или случаи воровства. Функция Shipment Verification включает две инструментальные панели, одна из которых предназначена для грузоотправителя, другая - для грузополучателя. Эти панели содержат все сведения о процессах доставки.

Защитный сценарий обмена данными между изготовителем и розничным продавцом

Функции защиты системы RFIDIC показаны на примере сценария для двух торговых партнеров - изготовителя гитар Ralf's Guitars и розничного продавца DirkMart, помимо прочего торгующего музыкальными инструментами.

В DirkMart реализована стратегия RFID, включающая EPCIS и инфраструктуры считывания RFID. В компании Ralf's Guitars нет считывающих устройств RFID, но на каждое произведенное изделие ставится ярлык RFID. Это вызывает дополнительные расходы, но в обмен на это DirkMart предоставляет компании Ralf's Guitars ограниченный доступ в репозитарий EPCIS к данным о событиях, связанных с ярлыками RFID изготовителя. С помощью этой информации компания Ralf's Guitars может определить, сколько изделий находится на складах магазинов DirkMart, и может отслеживать прибытие отгруженных товаров в DirkMart.

Результат такого управления можно просмотреть в браузере событий. Пользователи в этом сценарии предъявляют к информации следующие требования:

• Стив (Steve): начальник отдела защиты информации компании DirkMart имеет доступ к редактору правил защиты. Он определяет правила для всех партнеров DirkMart в цепочке поставок, которым требуется доступ к EPCIS, а также правила доступа для пользователей своей компании;
• Крейг (Craig): работает в отделе маркетинга DirkMart. В данное время Крейг занимается анализом продаж музыкальных инструментов. Доступ к информации о будущих событиях RFID ему не требуется;
• Ральф (Ralf): сотрудникам Ralf's Guitars необходимо просматривать информацию о событиях, связанных с продукцией, отгруженной для DirkMart. Ральф имеет доступ к EPCIS из приложений с интерфейсом Web-сервисов. Стив знает, что все коды EPC, назначенные Ralf's Guitars, имеют одинаковый префикс. Поэтому Ральф может просматривать только результаты запросов, имеющие отношение к кодам EPC с данным префиксом. У него нет прав для просмотра другой информации из EPCIS.

Каждый пользователь принадлежит к определенной группе пользователей. Поэтому Стив создает правила защиты для каждой группы. Далее показаны два примера правил для групп пользователей компании Ralf's Guitars. Прежде всего необходимо рассмотреть функции IBM WebSphere Application Server, необходимые для того, чтобы Стив мог определять и применять правила защиты для EPCIS.

Защита в RFIDIC

Функции защиты системы RFIDIC:

• Инфраструктура защиты WebSphere Application Server, например, ролевой контроль доступа и шифрование;
• Управление данными для запросов относительно репозитария, например, простые запросы к событиям в соответствии со стандартом EPCIS EPCglobal.

Уже было показано, что система RFIDIC состоит из двух основных защищаемых компонентов: регистрация и запросы. При регистрации необходимо убедиться, что можно защитить доступ к очереди сообщений MQ, чтобы недопустимые сообщения не отправлялись в систему RFIDIC. Защита запросов является более сложной. Можно защитить механизмы транспортировки соообщений запросов, особенно протокол HTTP для Web-сервисов и MQ для AS2. В системе также можно защитить запрошенные данные с помощью механизма обнаружения на основе правил. Второй уровень основан на защите транспорта, поскольку используется авторизация, предоставляемая в транспорте. Одно ограничение заключается в том, что в AS2 нет механизма слабой идентификации вызывающей программы (нет проверки идентичности или пароля), поэтому защитные правила не применяются.

Сервер приложений и защита J2EE

WebSphere Application Server обеспечивает защиту Web-сервисов и пользовательских Web-интерфейсов. На уровне транспорта сервиса применяются следующие концепции защиты:

• Аутентификация: пользователи должны подтвердить свою идентичность, как правило, с помощью идентификатора пользователя и пароля;
• Авторизация: доступ к определенным ресурсам предоставляется на основе идентичности пользователя. В данном случае, это RFIDIC + Web-сервисы и пользовательские Web-интерфейсы;
• Целостность сообщений и конфиденциальность: механизм обеспечения невозможности чтения или изменения сообщений при их передаче сторонними лицами, фактически определяется запрашивающей стороной. Как правило, в этих целях используется SSL-шифрование.

В отношении аутентификации на сервере WebSphere Application Server используется концепция пользовательских реестров, в которых хранятся сведения о пользователях. WebSphere Application Server поддерживает локальную операционную систему, протокол LDAP, а также программный способ предоставления пользовательских данных. В данной статье LDAP используется в качестве реестра пользователей, WebSphere Application Server получает всю информацию о пользователях и ролях, хранящуюся в этом реестре.

В Enterprise Application Archive (EAR), входящем в систему RFIDIC, разработчик найдет уже определенные роли и ограничения безопасности, обеспечивающие защиту Web-сервисов и пользовательских Web-интерфейсов. При развертывании EAR в среде разработки эти роли необходимо сопоставить пользователям и ролям в LDAP (или в реестре пользователей). Уже определенные роли:

• Administrator: пользователи данной роли могут выполнять любой запрос в браузере данных, создавать правила защиты, просматривать и повторно отправлять сбойные события;
• SecurityAnalyst: пользователи данной роли могут создавать правила защиты;
• Operator: пользователи этой роли могут просматривать и повторно отправлять сбойные события;
• EPCISQuery: пользователи данной роли имеют доступ к Web-сервису с помощью стандартных EPCIS-запросов, включая системные запросы событий;
• NamedAnswerQuery: пользователи данной роли имеют доступ к Web-сервису для выполнения ответных системных запросов;
• DataBrowserAdmin: пользователи данной роли могут выполнять любой запрос в браузере данных.

Теперь после рассмотрения процессов аутентификации и авторизации проще понять концепцию целостности сообщений. В EAR-файле уже включено шифрование SSL для всех из вышеперечисленных интерфейсов. По умолчанию в SSL используется сертификат с автоматической подписью. Для изменения параметров по умолчанию см. документацию к WebSphere. Это означает, что все сообщения шифруются, их невозможно прочитать или подделать. Другой способ обеспечения целостности сообщений заключается в применении WS-Security для Web-сервисов. Но эта тема в данной статье не рассматривается. За более подробной информацией обратитесь к документации WebSphere Application Server и справочникам формата "красная книга" IBM (Redbooks).

Использование правил для определения авторизации запросов и открытия данных

Если в WebSphere Application Server включена глобальная защита, доступ к системе RFIDIC подлежит авторизации в соответствии с правилами защиты. Все правила защиты, определенные в RFIDIC, имеют семантику ALLOW, то есть правила определяют, какие будут открыты данные. Таким образом, при отсутствии правила для определенных данных просмотреть эти данные будет невозможно. Правила применяются к запросам независимо от типа их отправки: незапланированные или по подписке.

Имеется два типа правил, которые пользователи могут создавать для защиты данных о событиях и основных данных от нежелательного раскрытия. Первый тип, правила авторизации запросов, определяет, запросы какого типа могут выполнять пользователи. Например, торговый партнер может выполнять только простые запросы к событиям. Второй тип правил защиты, называемый правилами раскрытия, определяет информацию, раскрытую в результате выполнения запроса и условия, при которых результирующие объекты раскрываются. Например, торговому партнеру может быть разрешено просматривать данные о количестве, но только для событий, связанных с музыкальными инструментами.

Для одной группы пользователей можно определить несколько правил. Это позволяет администратору службы безопасности реализовывать более сложные способы организации доступа к данным с помощью нескольких правил, каждое из которых является относительно простым и интуитивно понятным. Результат применения двух правил будет показан в этой статье позднее (см. рисунок 12). Значение атрибута отдельного объекта результата запроса раскрывается в том случае, если его раскрытие разрешено хотя бы одним правилом. Другими словами, если требуется защитить какую-то информацию, следует проследить, чтобы эти значения были исключены во всех правилах для данной группы пользователей.

Редактор правил защиты

Редактор правил защиты системы RFIDIC представляет собой инструмент для определения правил раскрытия данных при помощи интерфейсов запросов RFIDIC. Пользователь может выполнять следующие действия:

• Cоздание, удаление и изменение правил;
• Включение и отключение выбранных правил;
• Импорт и экспорт выбранных правил в XML-файл.

Система RFIDIC отличается интуитивным подходом к определению в правилах данных для раскрытия. Как уже было указано, события характеризуются двумя контекстными измерениями: продукт и местоположение. Следовательно, пользователь в редакторе правил защиты может задать три типа правил раскрытия:

• Правило раскрытия событий;
• Правило раскрытия продуктов;
• Правило раскрытия местоположения.

Администратор может ограничить данные результатов запроса для правил раскрытия при помощи задания следующих элементов:

• Атрибуты: значения атрибутов, которые могут быть раскрыты в объектах результатов;
• Условия: объект должен соответствовать этим условиям для включения в результат запроса.

Три типа правил раскрытия вступают в силу, если пользователю разрешено выполнять запрос. Четвертый тип правил, называемый правилом авторизации, определяет в редакторе правил защиты уровень привелегий выполнения запроса.

Реализация защиты

В этом разделе показано, как реализовать описанный выше сценарий:

1. Настройка сервера LDAP и импорт примеров данных;
2. Настройка защиты WebSphere Application Server и сопоставление ролей;
3. Использование редактора правил защиты для определения правил раскрытия в сценарии защиты;
4. Тестирование сценария защиты.

Предполагается, что установлен пакет RFIDIC и IBM Tivoli Directory Server 6.0 (в качестве LDAP-сервера). Если требуется использовать операционную систему в качестве реестра пользователей, необходимо выполнить действия, описанные в документации RFIDIC. Вместо импорта в каталог данных можно добавить пользователей и группы в операционных системах. Если не указано другое, следующие шаги должны выполняться под учетной записью "rfidic", которая является идентификатором администратора RFIDIC.

Настройка пользовательского репозитария в LDAP

1. Запустите программу настройки LDAP под учетной записью root: idsxcfg;
2. Дважды нажмите Administrator DN/password в дереве меню слева и отредактируйте значения в полях. Пример: Предполагается, что администратором является пользователь root операционной системы, под управлением которой запущен LDAP-сервер:
   1. Administrator DN: cn=root;
   2. Administrator password: rootpassword;
   3. Confirm password: rootpassword;
   4. Нажмите кнопку OK.
3. Дважды нажмите Configure Database в дереве меню слева и отредактируйте соответствующие значения в полях;
4. Дважды нажмите Manage suffixes:
   1. Введите значение в поле Suffix DN. Пример: dc=dirkmart, dc=com Обратите внимание, что данный текст точно соответствует строке, определенной в процедуре раздела "Использование редактора правил защиты";
   2. Нажмите Add;
   3. Нажмите OK.
5. Дважды нажмите Import LDIF data:
   1. Нажмите Browse и выберите файл LDIF для импорта. Пример файла LDIF можно найти в разделе Downloads;
   2. Другие параметры оставьте неизменными;
   3. Нажмите Import;
   4. В последней строке текстовых сообщений должно находиться сообщение, подобное следующему:
      ldif2db: 79 entries have been successfully added out of 79 attempted.
6. Запустите LDAP-сервер под учетной записью root: ibmslapd.

Настройка защиты WebSphere Application Server и Web-приложения

В данном разделе показано, как включить защиту WebSphere Application Server и как сопоставить роли ролям и пользователям в LDAP. Конфигурация защиты WebSphere Application Server выполняется из консоли администрирования WebSphere Application Server. Сопоставление ролей также можно выполнить в консоли администрирования WebSphere Application Server.

Прежде всего, перейдите в консоли администрирования WebSphere Application Server к элементу Security > Global Security > User Registries > LDAP. Введите dirk в качестве идентификатора пользователя и just4now в качестве пароля. Это идентификатор пользователя, используемый для подключения к LDAP. В файле примера LDIF для LDAP-сервера Дирк (Dirk) является членом группы пользователей отдела информационных технологий. Это также означает, что данный пользователь по умолчанию является администратором WebSphere Application Server и его учетную запись можно использовать для входа в консоль администрирования WebSphere Application Server. Укажите имя узла и порт, на котором выполняется LDAP-сервер. Используйте dc=dirkmart,dc=com в качестве основного значимого имени и нажмите OK.

Далее перейдите к элементу Security > Global Security, установите флажок Enable Global security и снимите флажок Enforce Java 2 security. В качестве активного реестра пользователей выберите LDAP. После нажатия кнопки OKсервер WebSphere Application Server подключается к LDAP и проверяет доступность LDAP-сервера. Если все в порядке, сохраните настройки.

После изменения параметров LDAP перезапустите сервер WebSphere Application Server с помощью команды /opt/ibm/WebSphere/RFIDIC/bin/stopRFIDIC.sh -components=was и /opt/ibm/WebSphere/RFIDIC/bin/startRFIDIC.sh -components=was. При регистрации в консоли администрирования WebSphere Application Server выдается запрос на ввод пароля. Введите идентификаторы пользователей, используемые в параметрах защиты WebSphere Application Server, введите в качестве пароля just4now. Обратите внимание, что после включения защиты для остановки WebSphere Application Server требуется ввести пароль. Команда остановки /opt/ibm/WebSphere/RFIFIC/bin/startRFIDIC -components=was -was_username dirk. Сценарий выдает запрос на ввод пароля.

Далее сопоставьте роли, определенные для интерфейсов, пользователям и группам в каталоге LDAP. Откройте консоль администрирования WebSphere Application Server и перейдите к элементу Application > Enterprise Application > com.ibm.rfidic.webEAR > Additional Properties > Map security roles to users/groups. В пользовательском интерфейсе отображаются роли J2EE, указанные выше, и элементы, которым они сопоставлены (изначально роли были не сопоставлены). Установите флажок SecurityAnalystи нажмите Lookup Users. В следующем диалоговом окне выполняется поиск пользователей в LDAP. Каталог является довольно маленьким, дальнейший поиск не ограничен, поэтому нажмите Search. Должны отображаться все пользователи, ранее импортированные в каталог. Добавьте пользователей steve и dirk к выбранным пользователяем и нажмите OK. Такие же действия выполните для каждой роли и сопоставьте роли набору групп или набору пользователей; можно также оставить роли несопоставленными. В последнем случае роли не сопоставлены пользователям, интерфейсы будут недоступными. После этого сохраните конфигурацию.

В представленном выше примере роль NamedAnswerQuery осталась несопоставленной, поэтому невозможно использовать Web-сервис ответных запросов. Группе "cn=EPCIS access,cn=roles,o=ralfsguitars,cn=partners,dc=dirkmart,dc=com" предоставлен доступ к Web-сервису EPCIS, поэтому приложения компании Ralf's Guitars имеют доступ к Web-сервису и могут получать информацию о своих продуктах.

Использование редактора правил защиты

Для просмотра влияния управления раскрытием данных с помощью определения и включения правил необходимо отправить в систему RFIDIC несколько простых событий при помощи интерфейса регистрации для очередей сообщений. RFIDIC включает программу, считывающую события из файла и ставящую их в очередь сообщений событий RFIDIC. Файл с примерами событий objectevents.xml можно найти в разделе Downloads. В ОС Linux зарегистрируйтесь как rfidic и введите java "-DRFIDIC_HOME=${RFIDIC_HOME}" com.ibm.rfidic.utils.mq.PutQueue myeventq objectevents.xml Эту команду также можно загрузить в качестве сценария оболочки putqueue.sh в разделе Downloads. Убедитесь, что файл objectevents.xml и сценарий находятся в одной папке и сценарий является выполнимым. Сделать выполнимым сценарий можно при помощи команды chmod u+x putqueue.sh.

Требования к защите, указанные в предыдущем сценарии, можно реализовать при помощи редактора правил защиты. Для этого выполните следующее. Стиву, ответственному за определение правил, требуется убедиться, что персонал маркетингового отдела DirkMart может выполнять только простые запросы SimpleEvent. К тому же должны представляться сведения только о событиях, связанных с продукцией Ralf's Guitars.

1. Введите в адресной строке браузера http://localhost:9080/com.ibm.rfidic.web/ и зарегистрируйтесь как пользователь steve с паролем just4now. На домашней странице RFIDIC выберите Security Policy Editor;
2. Настройте правило защиты для торгового партнера Ralf's Guitars. В списке групп LDAP выберите CN=EPCIS ACCESS,CN=ROLES,O=RALFSGUITARS,CN=PARTNERS,DC=DIRKMART,DC=COMи назначьте группе уникальное описательное имя, например, Only receiving;
3. Создайте несколько правил защиты:
   1. Выберите authorization rule из списка доступных типов правил;
   2. Снова задайте понятное имя и выберите SimpleEventQuery в списке доступных запросов;
   3. Сохраните это правило и создайте следующий тип правил event disclosure rule с именем Events. Этот шаг представлен на рисунке 5;
   4. Выберите все типы событий и все соответствующие доступные атрибуты;
   5. Ограничьте тип объектов результатов с помощью добавления следующих условий:
      • Имя атрибута epc, оператор Match или Like. Введите значение urn:epc:id:sgtin:1234567.*;
      • Имя атрибута bizStep, оператор Equal. Введите значение Receiving.
   6. Нажмите Save;
   7. Сохраните все правило. Автоматически выполняется возврат к панели с итоговыми данными о правилах, доступных для EPCIS.

Использование редактора правил защиты: Правило "All events, no action and disposition"

В целях эксперимента создайте другое правило, аналогичное созданному ранее правилу "Only receiving". Но вместо ограничения раскрытия для событий с помощью bizStep=Receiving разрешите раскрытие всех событий. Но при этом запретите раскрытие значений атрибутов всех событий, за исключением action и disposition. Панель определения правил раскрытия событий представлена на рисунке 9. Данные о двух определенных правилах показаны на рисунке 11. Теперь можно отключить одно правило и включить другое. Результат отображения всех ObjectEvents в браузере данных в предыдущем примере (см. рисунок 7), когда включено только новое правило "All events, no action and disposition", показан на рисунке 10. В противоположность этому на рисунке 8 представлен результат для правила "Only receiving" (см. рисунок 5). Если включить оба правила, будут отображаться различные результаты, как это показано на рисунке 12. Почему так происходит? Если включены оба правила, определяются все события с bizStep=Receiving (поскольку включено правило "All events, no action and disposition"). Но значения для действия и положения возвращаются только для событий с bizStep=Receiving (поскольку включено правило "Only receiving"). На рисунке 12 показано, почему метод раскрытия данных RFIDIC структурирован на ячеечном уровне.

Рисунок 6. Обзор правил защиты

Рисунок 7. Определение запроса ObjectEvents в браузере данных

Рисунок 8. Результат запроса в браузере данных, когда включено только правило "Only receiving"

Рисунок 9. Определение правила раскрытия событий All events, no action and disposition для компании Ralf's Guitars

Рисунок 10. Результат запроса в браузере данных, когда включено только правило "All events, no action and disposition"

Рисунок 11. Обзор правил

Рисунок 12. Результат запроса в браузере данных при включенных правилах "All events, no action and disposition" и "Only receiving"

Тестирование защиты

При тестировании параметров защиты также протестируйте два различных уровня защиты. Сначала необходимо протестировать защиту J2EE с авторизацией URL-ресурсов , затем следует убедиться, что данные, возвращаемые запросами, соответствуют активным правилам защиты.

Защиту J2EE можно протестировать при помощи ввода URL-адресов в браузере. Например, если в адресной строке браузера задать результирующую страницу системы RFIDIC для пользователя ralf, ссылки на браузер данных, редактор правил защиты и браузер неудачных событий должны быть недоступны. Закройте браузер и зарегистрируйтесь в системе как пользователь steve. Вы должны иметь доступ к браузеру данных (поскольку Стив является членом группы отдела информационных технологий, сопоставленную роли Data Browser) и к редактору правил защиты (для этого пользователя выполнено сопоставление роли security analyst).

Для тестирования доступа к Web-сервисам необходимо создать клиент Web-сервиса (например, с помощью языка описания Web-сервисов [WSDL, Web Services Description Language] в IBM Rational Software Architect или IBM Rational Software Developer), а затем задать идентификатор пользователя, пароли и соответствующие параметры SSL (для доступа к сертификату с автоматическим подписыванием). Существует более легкий способ доступа к URL-адресам, определенным WSDL, в браузере. URL-адрес http://localhost:9080/com.ibm.rfidic.web/services/EPCglobalEPCISService предназначен для Web-сервисов EPCIS, http://localhost:9080/com.ibm.rfidic.web/services/AnswerSolutionQueriesServicePort - для ответного Web-сервиса. Обратите внимание, что если включена защита, эти URL-адреса автоматически передаются в соответствующие URL-адреса, где используется HTTPS и другой порт. При получении доступа выводится сообщение о доступности Web-сервиса. В противном случае выводится сообщение о неисправности с ошибкой авторизации 403. С помощью повторного открытия браузера и входа в систему под другой учетной записью можно убедиться, что, например, пользователь ralf имеет доступ к Web-сервису EPCIS, а доступ к ответному Web-сервису запрещен для всех пользователей.

Протестировать правила раскрытия можно вручную при помощи браузера событий системы RFIDIC, избирательно включая и отключая правила защиты в редакторе правил защиты. Скрываемые данные должны представляться в виде пустых ячеек в таблице результатов запросов в браузере событий, как это показано на рисунках 10 и 12. Особое внимание следует уделить ситуациям, когда для пользователя или группы включено несколько правил. Запомните, что значение объекта результатов раскрывается в том случае, если любое из включенных правил разрешает раскрытие этого значения.

Заключение

Поделитесь мнением... Отзыв на digg.com Публикация на del.icio.us Публикация на slashdot

В данной статье описаны функции защиты IBM WebSphere RFID Information Center 1.0. В статье представлены примеры включения защиты на сервер WebSphere Application Server и показано, как назначать роли защиты LDAP и как определять правила защиты. В статье также показаны результаты применения контроля раскрытия данных в запросах. Использование данных функций защиты позволяет компании использовать информацию, хранящуюся в репозитарии EPCIS, совместно с партнерами в цепочке поставок в соответствии с определенными требованиям к защите.

В начало

Загрузка

	Информация о методах загрузки

Ресурсы

• Оригинал статьи: Security with WebSphere RFID Information Center 1.0;
  
  
• Документация к IBM RFIDIC, размещенная в Интернете: Использование RFID Information Center для применения технологии RFID в целях преобразования бизнеса, начиная с бизнес-стратегии, через пилотное выполнение и реализацию, до интеграции процесса;
  
  
• Cправочники по защите WebSphere формата "красная книга" (Redbooks): Подробные технические сведения о проектировании и реализации решений по защите при помощи WebSphere;
  
  
• Web-сайт EPCglobal: Более подробная информация о EPCglobal;
  
  
• Раздел сайта developerWorks, связанный с архитектурой: Загрузите ресурсы, необходимые для повышения квалификации в области архитектуры;
  
  
• Просмотрите в специализированном книжном магазине книги по данной и другим темам;
  
  
• Раздел Information Management портала developerWorks: Узнайте больше о DB2. Здесь вы найдете техническую документацию, обучающие статьи, информацию о курсах, продукты для загрузки, информацию о продуктах и многое другое;
  
  
• Следите за техническими событиями и новыми материалами на Web-сайте developerWorks.
  
  

• Загрузите оценочные версии программных продуктов IBM и овладейте инструментами разработки приложений и связующим ПО для DB2, Lotus®, Rational®, Tivoli®, и WebSphere;
  
  
• Используйте в следующем проекте по разработке ознакомительные версии ПО IBM, которые можно загрузить непосредственно с портала developerWorks.

• Примите участие в обсуждении материала на форуме.
  
  
• Примите участие в форуме по Information Management;
  
  
• Просмотрите блоги developerWorks и присоединяйетсь к сообществу developerWorks.
  
  

Об авторе

		Дирк Волльшайд (Dirk Wollscheid) является инженером-консультантом в группе интеграции приложений и Web-сервисов DB2 в лаборатории IBM Silicon Valley Lab в Сан-Хосе. Он также является ведущим техническим архитектором в отделе Web-сервисов Information Integrator. Он занимается DB2, серверами приложений, XML и Web-сервисами.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало