 | Level: Intermediate Ralf Rantzau (rrantza@us.ibm.com), Software Engineer, IBM
Dirk Wollscheid (wollsch@us.ibm.com), Software Engineer, IBM
08 Mar 2007
IBM® WebSphere ® RFID Information Center (RFIDIC) is a repository for data related to radio frequency identification (RFID)-tagged items and the context about the events, such as detailed information about the tagged products or the location and position of RFID sensors. RFIDIC implements the EPCglobal standard for electronic product code (EPC) Information Services (EPCIS), which defines a RFID data repository and the services (protocols and interfaces) to access the data. One of the distinct features of RFIDIC is its flexible and easy-to-use security framework. It allows owners of an EPCIS system to securely collect RFID-related data and to securely share information with their trading partners in the supply chain. RFIDIC provides encrypted communication and group-based, policy-driven, cell-level data disclosure control.
This article explains how a solution developer can set up a security policy so that data exchanged between partners in a supply chain is only made available on a need-to-know basis. It also shows the implementation of a security scenario using RFIDIC that developers can reproduce and customize to their needs.
Introduction
IBM WebSphere RFIDIC is a software product for managing data related to EPCs, such as RFID sensor data, and the master data, such as location and product data, associated with the EPCs.
Before examining how to use the security features of RFIDIC, this article reviews some background information on RFID data management.
EPC and the EPCIS standard
The term EPC denotes a family of coding schemes for RFID tags. It is designed to meet the needs of various industries, while guaranteeing the uniqueness for all EPC-compliant tags. All EPC numbers contain a header identifying the encoding scheme that has been used. This in turn dictates the length, type, and structure of the EPC. EPC coding schemes typically contain a serial number that can be used to uniquely identify a single object. An example EPC is "urn:epc:id:sgtin:1234567.654321.999", where "1234567" is a manufacturer identifier, "654321" is a product class, and "999" is a serial number.
The RFID technology and EPC schemes provide the basis for new traceability applications for many types of physical items, but most typically products. Parties that want to collect and share their data in order to create increased business value need new mechanisms for querying traceable data. In addition to business considerations, companies are more likely to share their data if the information sharing infrastructure is easy to use, scalable, and secure.
The EPCglobal consortium develops industry standards for the use of RFID technology in supply chains. The EPCglobal network architecture describes components and interfaces for the EPC-related information interchange between servers that contain information related to items identified by EPC numbers. One of these components, EPCIS, is provided by these servers. RFIDIC is an implementation of EPCIS.
Figure 1. EPCglobal architecture and corresponding IBM software products
EPCIS provide access to a repository that contains event data and master data. Event data arises in the course of carrying out business processes, and is captured through the EPCIS capture interface for message queues. These events are represented in the XML that is generated by capture applications or middleware, such as IBM WebSphere RFID Premises Server, which is communicating with the readers. The events collected in the EPCIS are made available for query through the EPCIS query interfaces.
Master data is additional data that describes the context for interpreting event data. It is available for query through the EPCIS query control interface, but the means by which master data enters the system is not specified in the current EPCIS 1.0 standard.
Another query interface is the query callback interface for the HTTP, HTTPS, and Applicability Statement 2 (AS2) protocols. It is implemented by the receiver of subscription results. AS2 is a transport protocol specification for the Internet, and is typically used to send Electronic Data Interchange (EDI) messages.
According to the EPCglobal EPCIS standard specification, the events that are captured by EPCIS typically answer four basic questions: what, when, where, and why. The EPC code itself belongs to the first category, since it indicates what was observed. The data fields eventTime and recordTime answer the second question, while readLocation and bizLocation answer the third. An attribute of the fourth category is "bizStep", which describes the business context. Example identifiers for this data field indicate "shipping" or "receiving" of items. Another attribute of the fourth category is "action". That indicates the type of operation applied to the item associated with the EPC.
Events are typically submitted from middleware systems, such as IBM WebSphere RFID Premises Server that apply filtering and transformation on the raw events delivered by the sensors, like RFID readers and 1D- or 2D-barcode scanners. Therefore, the typical value for the action attribute is OBSERVE. Further values include ADD and DELETE, which are used for miscellaneous operations. One example use is aggregations, where a set of EPCs is associated with another EPC. An aggregation occurs when RFID-tagged items are packed into a container, which is itself tagged with an RFID chip. Another example is the commissioning of new items in a supply chain (ADD), and the decommissioning such as the destruction of a case in a compactor (DELETE). The event schema can be extended by additional, business-specific fields. For example, a reader may also capture the temperature or radioactivity of an item.
Listing 1. Example of an ObjectEvent:
<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 can be queried by other EPCIS systems, by extract-transform-load (ETL) systems that extract bulk data from the EPCIS and import it into a data warehouse for business intelligence applications, or by other, customized applications that continuously observe events. EPCIS provide an interface for executing ad-hoc queries as well as for submitting "standing" queries that deliver new results periodically.
The EPCglobal standard for EPCIS does not require that authorization of queries using the EPCIS Query Control API are actually enforced. However, the standard suggests several ways how EPCIS can react in order to provide some notion of authorization. Among the reactions described in the standard document, which are formulated using the "may" predicate, are:
-
The service may refuse to honor the request altogether, by responding with a SecurityException. The disclosure control method of RFIDIC realizes this suggestion by providing special authorization policy rules that assign the right to execute certain types of queries to certain user groups.
-
The service may respond with less data than requested. The method used by RFIDIC realizes this as part of the conditions that can be expressed inside disclosure policy rules that filter out unwanted result objects. In particular, expressing conditions using master data is allowed.
-
The service may hide information. Again, the method used by RFIDIC realizes this as part of the disclosure policy rules, where the attributes (of events or master data) are defined that may be displayed in query results.
Using these methods, all of the above suggestions about "query authorization" of the current EPCIS standard are fulfilled.
RFIDIC product overview
WebSphere RFIDIC is an implementation of the EPCIS specification. There are also some enhancements that go beyond the specification.
The interfaces that are implemented or supported are:
- Capture interface for message queues (JMS over MQ),
- Query control interface for HTTP and HTTPS,
- Query callback interface for HTTP, HTTPS, and AS2, and
- Core query and event XML schemas
RFIDIC specific features are:
- Support for importing and referencing of master data such as product, locations, and their hierarchies and categories
- A flexible mechanism to define attribute extensions to the event, product, and location schemas
- The definition of rule-based security
- An extensible mechanism for executing custom validation in the capture component and handling failures of such validation
- A way to define solution queries that are more powerful than the simple queries defined in the EPCglobal specification
- User interfaces for browsing master data and events and managing failed events
- Alphablox as a reporting tool
RFIDIC supports the import of product and location master data, and combining them with the event data. Master data can be exported from a system like
IBM WebSphere Product Center or a legacy system storing product and location data. A solution developer can define the attributes
of products and location in a meta data format. Relationships between those entities can be hierarchies, sets, or categories. Modeling multiple hierarchies,
sets and categories are concepts that extend the EPCglobal specification on master data.
The EPCIS specification is extensible for industries to define their own event types, EPCs, and event extensions. There is a set of standard events,
such as ObjectEvent and TransactionEvent, but solutions can define new event types with their own set of attributes. Standard events, new events, and master data can have
extension attributes that can vary from one solution to another. An example for such extensions are the street name for a location or the chip UID in events that might be reported by the RFID reader.
The extensions for events and MDM data are defined in the RFIDIC meta data file. The meta data is used to create a database schema to capture and query events.
If an event contains an attribute that is not described in the meta data, RFIDIC still captures this event, but considers this attribute a surprise attribute.
This attribute is stored in the database event, although it does not comply with the predefined event and database schema.
During capture, the RFIDIC system can be configured to validate the event attributes against existing master data. For instance, the readPoint
attribute would pass the test if it matches one of the imported reader locations. If that test fails, the event is stored as a failed event and can be resubmitted
at a later point when that location was imported. The Failed Event UI lets users browse failed events and decide on the appropriate action.
The EPCglobal specification also allows industries to define their own EPC formats. Different companies often use different identifiers for products and locations.
Examples of product identifiers would be "SKU123" or "ISBN67870." The identifiers for master data in RFIDIC are called external IDs, which are customer assigned. The RFIDIC system also assigns its own identifiers to those entities that are referred to as internal IDs.
In order to combine the EPC and the the master data, a solution-specific code component called handler needs to be written to interpret the EPC and look up
the correct MDM entity with an external ID. This piece of code needs to be able, for example, to transform a GTIN to an ISBN. A failure in the look-up is treated as an event failure as described above. An additional advantage is the storage of the internal IDs instead of the full EPCs in the database.
Solutions often have different requirements for actions being taken when an event is captured. This can be additional validation of events that goes beyond schema
validation, updating inventories, or notifying users that certain types of products have arrived. In order to accommodate for this, RFIDIC uses IBM Tivoli Directory Integrator (TDI)
in capture. TDI lets the user define an assembly line that contains the steps that are taken when an event is captured. In an assembly line, one combines the RFIDIC coded actions (connectors), such as reading events from MQ (MQ connector) and parsing them (event connector) and storing them in the database (database connector) or solution specific connectors like the ones mention above. TDI also allows for scalability by
executing those steps in a multi-threaded environment.
The RFIDIC query component implements the query control interface, which consists of the synchronous query interface and the asynchronous interface. Both can
be used with HTTP, HTTPS, and AS2 as message delivery mechanisms. In the asynchronous mode, the query is submitted for a later, possibly repeated, execution. In the synchronous
mode, the query results are returned immediately. In RFIDIC, the security rules are applied in both modes. The query language defined in the EPCIS specification only allows to use simple predicates in a query. If the
solution developer needs more complex and customized queries, he can use the solution query mechanism in RFIDIC. The two kinds of queries that are supported are:
event solution queries, which return only events and the answer solution queries, which can return any non-event data or aggregated results. Both kinds
of queries are defined in the SolutionQueries.xml file. The answer query mechanism is an extension to the standard. Like standard queries, answer solution queries are subject to query execution enforcement as specified by security policies. However, currently they are not subject to data disclosure control.
The three user interfaces that come with RFIDIC are the Data Browser, the Failed Event UI and the Security Policy Editor, which can be accessed with a Web browser. The Security Policy Editor allows a developer
to create security policies. This is discussed in more detail below. The Data Browser allows you to create queries similar to the ones in the EPCIS specification and store them for later usage. Results can be retrieved as
HTML or as a Microsoft® Excel spreadsheet. The Data Browser can be used to verify incoming events and do ad-hoc queries. It can also be used to verify the effect of a new or changed security policy. For more elaborate reporting requirements, Alphablox can be used. Besides querying the EPCIS repository, the Data Browser allows you to display the master data. For example, you can explore the product and location hierarchies, if available.
The Failed Event UI allows browsing failed events and resubmitting or deleting them depending on the nature of the failure. There is also a Failed Event API that can be used to process failed events without user interaction.
The Shipment Verification feature is an RFIDIC component that can be installed separately to handle shipment receipts between a shipper and a receiver.
In this scenario, the shipper sends the retailer advance shipment notice events and the receiver sends back receipt notices to the shipper. Among the advantages of this feature is that the shipment can be tracked. For example, the amount of time for shipments can be observed and potential losses or theft be identified. The Shipment Verification feature provides two dashboards, one for the shipper and one for the receiver, that report all details about the shipment processes.
Security scenario with data exchange between manufacturer and retailer
The security features of RFIDIC are illustrated using a scenario with two trading partners, a manufacturer of guitars called Ralf's Guitars and a retailer called DirkMart that sells musical instruments and more.
DirkMart has implemented an RFID strategy that comprises EPCIS and an RFID reader infrastructure. While Ralf's Guitars has no RFID readers installed yet, they already attach RFID tags to each of their products. This incurs some additional cost, but in exchange DirkMart allows Ralf's Guitars a restricted access to its RFID event data in the EPCIS repository. By using this information, Ralf's Guitars can now find out which products are still on the store floor at DirkMart stores and can also track whether and when its shipments arrive at DirkMart.
The effects of disclosure control are shown in the event browser. The users in this scenario have the following information requirements:
-
Steve: The chief information security officer of DirkMart has access to the Security Policy Editor. He defines the policy rules for each supply chain partner of DirkMart that needs access to the EPCIS as well as for internal users.
-
Craig: Is working in the marketing department of DirkMart. Currently, Craig has been assigned to analyze the sales of musical instruments. He does not need to have access to information about further RFID events.
-
Ralf: Who works at Ralf's Guitars, needs to see information about events that pertain to products that they shipped to DirkMart. He accesses the EPCIS through applications that use the Web service interface. Steve knows that all EPCs issued by Ralf's Guitars have all the same prefix. Therefore, Ralf is allowed to see only query results involving events pertaining to EPCs starting with this prefix. He is not entitled to retrieve any other information from the EPCIS.
Each user belongs to a different user group. Therefore, Steve creates a security policy for each group. Two example policies for the user group Ralf's Guitars are presented later. First, the security features of IBM WebSphere Application Server that are needed to be in place before Steve is able to define and enforce the security policies for the EPCIS are explained.
Security in RFIDIC
The security features of RFIDIC comprise of the following:
- Security infrastructure of WebSphere Application Server, such as role-based access control and encryption
- Data disclosure control for queries against the repository, for example, the simple event queries according to EPCglobal's EPCIS standard
It has already been discussed that RFIDIC consists of two major components that can be secured: capture and query. For capture you want to ensure that the access to MQ message queue can be secured so that no
invalid messages can be sent to RFIDIC. Query security is more complex. You can secure the transports where query request messages can be sent on, specifically HTTP for Web services and MQ for AS2. And there is
also the queried data in the system that can be protected with the rule-based disclosure mechanism. The second level builds on the transport security, because you use the authorization that is
provided in the transport. One restriction is that since AS2 does not have any mechanism to provide weak identity of the caller (no proof of identity or password is provided), the security rules are not applied.
Application server and J2EE security
WebSphere Application Server secures the Web services and Web UIs.
On the service transport level, there are the following security concepts:
-
Authentication: A user needs to provide proof of his or her identity, usually a user ID and password.
-
Authorization: Based on a user's identity, access is is granted to certain resources. In this case, it is RFIDIC + Web services and Web UIs.
-
Message integrity and privacy: A mechanism to ensure that messages cannot be read or modified by third parties during transmission, and that it is actually coming
from the requester. A common mechanism for this is the use of SSL encryption.
In terms of authentication, WebSphere Application Server has the concept of user registries where information about users is stored. WebSphere Application Server supports the local operating system, Lightweight Directory Access Protocol (LDAP), and
also a programmatic way of providing user information. In this article, LDAP is used as a user registry and WebSphere Application Server takes all user and role information
that is stored in there.
When the developer looks at the Enterprise Application Archive (EAR) that comes with RFIDIC, he or she finds that there are already roles and security constraints defined
that secure the Web services and Web UIs. When deploying the EAR in his or her environment, he or she has to map those roles to the users and roles in LDAP (or whatever
user registry is chosen). The roles that are defined are:
-
Administrator: Users in this role can run any query in the Data Browser, create security policies, and browse and resubmit failed events.
-
SecurityAnalyst: Users in this role can create security policies.
-
Operator: Users in this role can browse and resubmit failed events.
-
EPCISQuery: Users in this role can access the Web service for standard EPCIS queries, including solution event queries.
-
NamedAnswerQuery: Users in this role can access the Web service for solution answer queries.
-
DataBrowserAdmin: Users in this role can run any query in the Data Browser.
During deployment of the EAR file, you map these groups to users in the LDAP directory.
This means that only users in the role EPCISQuery are able to invoke the EPCIS Web service. For example, since user ralf needs to access the EPCIS query interface, he is one of the users or groups that
are mapped to the EPCISQuery role.
Now that authentication and authorization has been covered, the message integrity part is easy. The EAR file has already turned SSL on for all of the above
interfaces. The default SSL settings use a self-signed certificate, and this can be changed, refer to the WebSphere documentation for that.
This means that all messages are encrypted and they cannot be read or tampered with.
Another way of using message integrity is using WS-Security for the Web services. But this is beyond the scope of
this article. For more information, refer to the WebSphere Application Server documentation and IBM Redbooks.
Use policies to define authorization for queries and disclosure of data
If global security is enabled in WebSphere Application Server, access to RFIDIC is subject to authorization as specified in security policies. All security policies defined with RFIDIC have ALLOW semantics, meaning, the policies define what data can be disclosed. Therefore, the absence of a policy for certain data prohibits its disclosure. The policies apply to queries irrespective of whether they are submitted in an ad-hoc manner or if the queries are subscriptions.
There are two types of rules that a user can create in a security policy to protect event data and master data from unwanted disclosure. The first type, query authorization rules, specify which type a queries a user may execute. For example, a trading partner may only execute simple event queries. The second type of security policy rules, called disclosure rules, specifies what information can be disclosed in a query result and the conditions under which result objects are disclosed. For instance, a trading partner may be allowed to see quantity information but only for those events that are about musical instruments.
It is possible to define multiple policies for the same user group. This allows the security administrator to compose more complex disclosure effects by enabling several policies, while each individual policy is relatively simple and intuitive. You will see the effects of two enabled policies later in this article (see Figure 12). An attribute value of a particular query result object is disclosed if there is at least one policy that allows its disclosure. In other words, if certain information has to be protected, one must pay attention that all policies for the given user group exclude these values.
The Security Policy Editor
The RFIDIC Security Policy Editor is a tool for specifying the rules under which data can be disclosed by the RFIDIC query interfaces. A user can:
- Create, delete, and modify policies
- Enable and disable selected policies
- Import and export selected policies to an XML file
RFIDIC provides an intuitive approach of specifying in the policies the data that may to be disclosed. As mentioned before, events are characterized by the two contextual dimensions product and location. Therefore, a user can specify three types of disclosure rules in the Security Policy Editor:
- Events disclosure rule
- Products disclosure rule
- Locations disclosure rule
For disclosure rules, the administrator can restrict the query result data by specifying:
-
Attributes: Whose values can be revealed in result objects
-
Conditions: That an object has to fulfill to be included in the result
The three types of disclosure rules are enforced once the user is granted execution of a query. A fourth type of policy rule, called an authorization rule, in the Security Policy Editor specifies the query execution privilege.
Implementation of security
This section shows how the scenarios outlined above can be implemented:
- Set up the LDAP server and import sample data
- Set up WebSphere Application Server security and map the roles
- Use the Security Policy Editor to define disclosure rules for the security scenario
- Test the security scenario
It is assumed that the RFIDIC product and the IBM Tivoli Directory Server 6.0 (as LDAP server) are installed. If you want to use the operating system as a user
registry, make sure you follow the steps in the RFIDIC documentation. Instead of importing the data into the directory, you would
add users and groups in the operating systems. The following steps are meant to be executed as user "rfidic", which is the administrator user ID of RFIDIC, if not mentioned otherwise.
Set up a user repository in LDAP
- As user root, start the LDAP configuration tool: idsxcfg
- Double-click Administrator DN/password in the menu tree on the left, and edit the fields.
Example: It is assumed that the administrator is the root user of the operating system where the LDAP server is running.
- Administrator DN: cn=root
- Administrator password: rootpassword
- Confirm password: rootpassword
- Click OK.
- Double-click Configure Database in the menu tree on the left, and edit the fields appropriately.
- Double-click Manage suffixes.
- Type in the field Suffix DN.
Example: dc=dirkmart, dc=com
Note that this text is exactly the same string that is specified in the procedure in the Use the Security Policy Editor section.
- Click Add.
- Click OK.
- Double-click Import LDIF data.
- Click Browse to find the LDIF file that you want to import.
A sample LDIF file can be found in the Downloads section.
- Leave all other settings unchanged.
- Click Import.
- The last line of the text messages should show a message similar to the following:
ldif2db: 79 entries have been successfully added out of 79 attempted.
- Also, as user root, start the LDAP server: ibmslapd
Configure WebSphere Application Server security and the Web application
This section shows how to switch on the WebSphere Application Server security and how to map the roles to the roles and users in LDAP.
The WebSphere Application Server security configuration is done in the WebSphere Application Server administration console. For the role mapping, you also see how this is done in the
WebSphere Application Server administration console.
First, in the WebSphere Application Server administration console, navigate to Security > Global Security > User Registries > LDAP. Enter dirk as user ID and just4now as the password. This will be the user ID
that is used to connect to LDAP. Dirk is a member of the IT staff user group in the LDIF sample file for the LDAP server. It also means that this user is a WebSphere Application Server administrator as default, and can be used to log into the WebSphere Application Server administration console once you are done. Specify the hostname and
port where the LDAP server runs. Use dc=dirkmart,dc=com as a base distinguished name, and click OK.
Figure 2. Set up the WebSphere Application Server user and LDAP server settings
Next, navigate to Security > Global Security, check Enable Global security and uncheck Enforce Java 2 security. Choose LDAP as an active user registry. When you click OK, WebSphere Application Server connects to LDAP and checks if it can access the LDAP server.
If that works, make sure you save the settings.
Figure 3. Enable WebSphere Application Server global security.
After changing the LDAP settings, restart WebSphere Application Server with /opt/ibm/WebSphere/RFIDIC/bin/stopRFIDIC.sh -components=was and /opt/ibm/WebSphere/RFIDIC/bin/startRFIDIC.sh -components=was. When you log into
the WebSphere Application Server administration console you are now being asked for a password. Enter the user IDs you used in the WebSphere Application Server security settings and use just4now as a password. Note that after enabling security, WebSphere Application Server requires a password to stop. The stop command is /opt/ibm/WebSphere/RFIFIC/bin/startRFIDIC -components=was -was_username dirk.
The script prompts you for a password.
As a next step, map the roles that are defined for the interfaces to users and groups in the LDAP directory. Open the WebSphere Application Server
administration console and navigate to Application > Enterprise Application > com.ibm.rfidic.webEAR > Additional Properties > Map security roles to users/groups.
The UI shows the J2EE roles mentioned above and show what they are mapped to, which is none at the beginning. Select the
check box for SecurityAnalyst, and click Lookup Users. The next dialog lets you search for users in LDAP. Because your directory is very small,
you are not restricting the search further, so just click Search. All the users previously imported into the directory should show up. Just add steve and dirk to
the selected users, and click OK. You would do the same thing for each role, and map them either to a set of groups or a set of users, or you could leave it unmapped.
In the latter case, that role will not match any users and the interface might be inaccessible. Once you are done, save the configuration.
Figure 4. Map RFIDIC roles to users and groups
In the example above, the NamedAnswerQuery role has been left unmapped so the answer query Web service cannot be used. The group "cn=EPCIS access,cn=roles,o=ralfsguitars,cn=partners,dc=dirkmart,dc=com" has been given access to the EPCIS Web service, so Ralf's Guitars applications can access the Web service and retrieve information about their product.
Use the Security Policy Editor
In order to show the effects of data disclosure control by defining and enabling security policies, you need to send a few sample events to RFIDIC by using its capture interface for message queues. RFIDIC provides a program that reads events from a file and enqueues it into the RFIDIC event message queue. The sample event file, objectevents.xml, can be found in the Downloads section. In Linux, log in as rfidic and type java "-DRFIDIC_HOME=${RFIDIC_HOME}" com.ibm.rfidic.utils.mq.PutQueue myeventq objectevents.xml This command can also be downloaded as a shell script, putqueue.sh, from the Downloads section. Make sure that the file, objectevents.xml, and the script, are in the same directory and ensure that the script is executable. You can make it executable by typing chmod u+x putqueue.sh.
The security requirements mentioned in the previous scenario can be realized using the Security Policy Editor as follows. Steve, who is responsible for defining policies, wants to ensure that the DirkMart marketing staff can execute only SimpleEvent queries. Furthermore, only events about the fact that Ralf's Guitars products have been received are disclosed.
- Point your Web browser to http://localhost:9080/com.ibm.rfidic.web/ and log on as user steve with password just4now. Select the Security Policy Editor on the RFIDIC home page.
- Set up a security policy for the trading partner Ralf's Guitars. From the list of LDAP groups, select CN=EPCIS ACCESS,CN=ROLES,O=RALFSGUITARS,CN=PARTNERS,DC=DIRKMART,DC=COM, and assign the group a unique intuitive name such as Only receiving.
- Proceed by creating several policy rules.
- Select an authorization rule from the list of available policy rule types.
- Again, specify an intuitive name, and select SimpleEventQuery from the list of available queries.
- Save this rule and create the next type of rule, an event disclosure rule with the name Events. This step is illustrated in Figure 5.
- Select all types of events and all available corresponding attributes.
- Restrict the type of result objects by adding the following conditions:
- Attribute name epc, operator Match or Like. Type in the value urn:epc:id:sgtin:1234567.*
- Attribute name bizStep, operator Equal. Type in the value Receiving.
- Click Save.
- Save the entire policy. You automatically return to the panel that summarizes the policies available for the EPCIS.
Use the Security Policy Editor: Policy "All events, no action and disposition"
For experimental purposes, create another policy that is similar to the policy "Only receiving" that you created before. Now, instead of restricting the disclosure to events with bizStep=Receiving, allow the disclosure of all events. However, do not allow to disclose the attribute values of all events, but exclude action and disposition. The panel of the event disclosure rule definition is illustrated in Figure 9. The two policies that are therefore defined, are summarized in Figure 11. You can now disable one policy and enable the other. The effect of displaying all ObjectEvents in the Data Browser as before (see Figure 7) when only the new policy "All events, no action and disposition" is enabled, is shown in Figure 10. Contrast this to Figure 8 for the policy "Only receiving" (see Figure 5). Now, if you enable both policies, a different result is displayed, as shown in Figure 12. Why is that? When both policies are enabled, all events with bizStep=Receiving are qualifying (since policy "All events, no action and disposition" is enabled). However, the values for action and disposition are returned only for events with bizStep=Receiving (since policy "Only receiving" is enabled). Figure 12 also illustrates, why the data disclosure control method of RFIDIC has cell-level granularity.
Figure 5. Define an events disclosure rule in a security policy "Only receiving" for Ralf's Guitars
Figure 6. Rules overview of a security policy
Figure 7. Define an ObjectEvents query in the Data Browser
Figure 8. Query result in Data Browser when only policy "Only receiving" is enabled
Figure 9. Define an events disclosure rule in a security policy "All events, no action and disposition" for Ralf's Guitars
Figure 10. Query result in Data Browser when only policy "All events, no action and disposition" is enabled
Figure 11. Policies overview
Figure 12. Query result in Data Browser when both policy "All events, no action and disposition" and "Only receiving" are enabled
Test security
When testing security settings, also test the two different levels of security. First, you have to test whether J2EE security with the authorization on the URL resources
is correct, and then you have to test that the data that is returned from queries complies with the security policies that are active.
The J2EE security can be tested by accessing the URLs with a browser. For example, if you point the browser to the RFIDIC landing page as user ralf,
the Data Browser, Security Policy Editor, and failed event browser links should be grayed out. Close the browser and log in as user steve. You should be
able to access the Data Browser (because he is in the IT staff group, which is mapped to the Data Browser role) and the Security Policy Editor
(because he is the mapped to the security analyst role).
For testing Web service access, you would have to write a Web service client (for example, by generating one from the Web Services Description Language [WSDL] with IBM Rational Software Architect or IBM Rational Software Developer), and then set the
user ID and passwords and the respective SSL settings (to accept your self-signed certificate). But there is an easier way of just accessing the URLs defined in the WSDL
in a browser. The URLs are http://localhost:9080/com.ibm.rfidic.web/services/EPCglobalEPCISService for the EPCIS Web services, and http://localhost:9080/com.ibm.rfidic.web/services/AnswerSolutionQueriesServicePort for the answer Web service. Note that these URLs are automatically forwarded when security is enabled to the corresponding URLs where HTTPS is used and a different port.
In case of success, a message is displayed stating that the Web service is available. Otherwise, a failure message about an 403 authorization failed error appears. By reopening the browser
and logging in as different users, it can be verified that, for example, user ralf is able to access the EPCIS Web service, and that the answer Web service cannot be accessed by any user.
Testing the disclosure policies can be done manually using the RFIDIC event browser and by selectively enabling and disabling security policies in the Security Policy Editor. The data that is supposed to be suppressed must appear as empty cells in a query result table within the event browser, as shown in Figures 10 and 12. Special attention must be paid to situations where more than one policy is enabled for a user or group. Remember that the value of a result object is disclosed if any of the enabled policies allow the disclosure of this value.
Conclusion
This article introduced the security features of IBM WebSphere RFID Information Center 1.0. It gave examples on how to enable security in WebSphere Application Server, how to assign users to security roles with LDAP, and how to define security policies. It has also shown the effects of enforcing disclosure control on queries. By exploiting these security features, companies can share the information stored in the EPCIS repository with their supply chain partners according to their specific security needs.
Downloads | Description | Name | Size | Download method |
|---|
| Sample LDIF file for LDAP server | ldap.ldif | 3KB | HTTP |
|---|
| Sample XML file with ObjectEvents | objectevents.xml | 14KB | HTTP |
|---|
| Sample shell script for enqueuing sample events | putqueue.sh | 1KB | HTTP |
|---|
Resources Learn
Get products and technologies
-
Download
IBM product evaluation versions, and get your hands on application development tools
and middleware products from DB2, Lotus®, Rational®, Tivoli®,
and WebSphere.
-
Build your next development project with
IBM
trial software, available for download directly from developerWorks.
Discuss
About the authors | 
| | Ralf Rantzau is a developer of the WebSphere RFID Information Center product. |
| 
| | Dirk Wollscheid is an Advisory Software engineer at the DB2 Application Integration and Web Services Team at the IBM Silicon Valley Lab in San Jose. He is the technical lead in the Information Integrator Web Services development. His interests are DB2, application servers, XML and Web Services. |
Rate this page
| |
