bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

B2B Security

Implementing Nonrepudiation

This topic includes the following sections:

- Overview of Nonrepudiation

- Using the Service Provider Interfaces (SPIs) for Nonrepudiation

Overview of Nonrepudiation

Nonrepudiation is the ability of a trading partner to prove or disprove having previously sent or received a particular business message to or from another trading partner. Consider the following example.

Trading Partner A has agreed to purchase 1000 ergonomic chairs from Trading Partner B. In the course of this agreement, Trading Partner A has sent a business message to Trading Partner B agreeing to buy the chairs at a set price. Later, though, Trading Partner A disputes the original price and denies having sent a message in which they agreed to pay that price.

If a reliable nonrepudiation system has been in place, Trading Partner B can disprove Trading Partner A's claim by producing a document from Trading Partner A specifying the amount Trading Partner A agreed to pay. Further, if this original document is digitally signed, timestamped, recorded, and secured by a trusted third-party source, the validity of this document has full legal recourse.

Nonrepudiation, or the ability to provide legal evidence of the involvement of a denying party, is a requirement for critical business messages. WebLogic Integration B2B supports both nonrepudiation of origin and nonrepudiation of receipt:

- Nonrepudiation of origin links the business message and the sender of the message. It provides legal evidence that you have sent a business message.

- Nonrepudiation of receipt links the business message and the recipient of the message. It provides legal evidence that you have received a business message.

To support nonrepudiation, the B2B engine incorporates the following services:

- Digital signatures

- Secure timestamps

- Secure audit logs

The remaining sections in this topic describe each of these services and explain how to incorporate them into your B2B environment.

Digital Signature Support

The purpose of digital signature support is to provide a means to prevent anyone or anything from tampering with the contents of a business message, especially when the business message is in transit between two trading partners. The B2B engine provides digital signature support that conforms to the Public Key Cryptography Standard 7 (PKCS7) packaging for digital signatures.

A digital signature itself is a set of data appended to a business message consisting of an encrypted, one-way hash value of data packaged in a specific format (for example, PKCS7 SignedData). A digital signature:

- Validates that the contents of a digitally signed message have not been tampered with.

- Contains the identity of the sender of the business message.

The data required to create a digital signature is obtained from the trading partner configuration data in the repository. The information required to create a digital signature also includes the following:

- Trading partner signature certificate and private key

- Certificate authority certificate for the trading partner signature certificate

- Hash algorithm name: SHA1

- Signature algorithm name: RSA

Business Protocols with Which You May Use Digital Signature Support

WebLogic Integration provides digital signature support for messages that use the following business protocols:

- RosettaNet 1.1

- RosettaNet 2.0

- XOCP 1.1

Configuring Digital Signature Support

When you configure WebLogic Integration, you have the option of specifying a digital signature service. To use a digital signature service, you must configure it as described in Configuring Digital Signatures for Nonrepudiation.

Secure Timestamp Service

If nonrepudiation is being used, secure timestamp services are required to attach a Coordinated Universal Time (UTC) timestamp to the secure audit log when business messages are also logged to the secure audit log. For example, when you receive a business message, a timestamp is entered as a nonrepudiation of receipt (NRR) message in the audit log. When you send a business message, a timestamp is entered as a nonrepudiation of origin (NRO) message in the audit log. WebLogic Integration B2B includes a Service Provider Interface (SPI) so that you can incorporate a secure timestamp service from a trusted third-party provider.

If you incorporate a secure timestamp service from a trusted third-party provider, you need to create a Java class file that implements the com.bea.b2b.security.TimestampProvider interface. In the class methods (for example, getTimestamp) of your class implementing the com.bea.b2b.security.TimestampProvider interface, you call out to the third party timestamp provider. For details about creating this application, see Using the SPI for the Secure Timestamp Service.

The B2B engine prohibits more than one secure timestamp provider from being registered in WebLogic Integration. This restriction ensures that all timestamps created in the WebLogic Integration are ordered chronologically.

Note: If you do not configure a secure timestamp service provider in WebLogic Integration, system time is used for timestamping system events and signatures.

For details about the secure timestamp SPI, see Using the SPI for the Secure Timestamp Service.

Configuring the Secure Timestamp Service

To configure the secure timestamp service, complete the following steps:

1. Start the WebLogic Integration B2B Console and display the B2B configuration page, as described in Configuring Security for the WebLogic Integration B2B Engine.

2. Select the Security tab. The B2B Security configuration page is displayed, as shown in the following figure.

   Figure 5-1 B2B Security Configuration Page

3. In the field labeled Secure Timestamp Class, enter the fully qualified name of the Java class that implements the secure timestamp interface.

4. Restart WebLogic Server so that the new configuration takes effect.

Secure Audit Log Service

A secure audit log is also required for nonrepudiation. This log typically stores each business message with its digital signature and secure timestamp. You use an audit log to reconstruct the sequence of messages and other system events that have occurred during the exchange of business messages among trading partners.

As with the timestamp service, the B2B engine provides a Service Provider Interface (SPI) for you to configure a trusted, third-party provider of the secure audit log. If you incorporate a secure audit log service from a trusted third-party provider, you need to create a class file that implements the com.bea.b2b.security.AuditLogProvider interface. In the class methods of your class implementing the com.bea.b2b.security.AuditLogProvider interface (for example, log), you call out to the third party audit log provider. For details about creating this implementation, see Using the SPI for the Secure Audit Log.

Note: If you do not configure a third-party provider for a secure audit log service, the B2B system provides a default audit log in a file named secureaudit.log, which you can enable by setting the system property bea.secureaudit to on. This file is based on the logging subsystem in B2B, and is protected by only the underlying operating system's file permissions system. This file is not digitally signed or encrypted.

Writing to the Audit Log Directly

As an alternative to writing a Java implementation of the com.bea.b2b.security.AuditLogProvider interface to call out to an application that writes to the audit log, you can write an application that writes to the audit log directly via an invocation to the com.bea.b2b.security.Audit.log(byte[] data) method, as shown in the code example provided in this section.

This example is a modification of the HelloPartnerServlet.java class, which is located in the following directory, where SAMPLES_HOME represents the directory in which the sample applications are installed:

- Windows

>     %SAMPLES_HOME%\integration\samples\HelloPartner\src\wlcsamples\servlets

- UNIX

>     $SAMPLES_HOME/integration/samples/HelloPartner/src/wlcsamples/servlets

In this example, the bolded code shows the statements that have been added to show writing to the audit log.

Listing 5-1 Example of Writing to the Audit Log Directly

>     package wlcsamples.servlets;
>     import java.io.*;
>     import java.util.*;
>     import javax.servlet.*;
>     import javax.servlet.http.*;
>     import java.lang.*;
>     import javax.transaction.*;
>     import javax.naming.*;
>     import javax.jms.*;
>     import weblogic.jms.extensions.WLTopicSession;
>     import weblogic.jms.extensions.XMLMessage;
>     import org.w3c.dom.*;
>     import org.apache.html.dom.*;
>     import org.apache.xml.serialize.*;
>     import org.apache.xerces.dom.*;
>     import org.apache.xerces.parsers.DOMParser;
>     import org.xml.sax.*;
>     import com.bea.eci.logging.*;

>     //Import the Audit class from security package.
>     import com.bea.b2b.security.Audit;
>     ...
>     	protected void printResultHTML(PrintWriter pw, Document resultDoc)
>     	{
>     		try {
>     			pw.println("<P><CENTER><P><BR>   <b>Hello Partner Sample</b><BR>");
>     			if( resultDoc != null ) {
>     				Element root = resultDoc.getDocumentElement();
>     				NodeList productList =
>     					root.getElementsByTagName("integer-product");
>     				NodeList noteList =
>     					root.getElementsByTagName("note");
>     				Node childProduct = productList.item(0);
>     				Node childNote = noteList.item(0);
>     				if( childProduct == null || childNote == null ) {
>     					pw.println("<BR> The Replier Partner has responded
>     						with a document of unexpected structure...");
>     				else {
>     					String product = ((Text)childProduct.
>     						getFirstChild()).getData();
>     					String note = ((Text)childNote.getFirstChild()).
>     						getData();
>     					// Log the note to the Audit log
>     					byte[] ba = note.getBytes();
>     					Audit.log(ba);
>     					//String strXMLDoc = DocSerializer.docToString
>     						(resultDoc);
>     					pw.println("<BR> The Replier Partner has responded
>     						with the following result... <BR>  ");
>     					pw.println("<BR> Product: " + product + "");
>     					pw.println("<BR> Note: " + note + "<P><BR><BR>
>     						</CENTER>");
>     					pw.println("<CENTER><IMG SRC=\"Hello4.gif\"
>     						WIDTH=650 HEIGHT=220
>                        BORDER=0 NATURALSIZEFLAG=3></CENTER>");
>     				}
>     			}
>     			else {
>     				pw.println("<BR> ERROR:  ");
>     				pw.println("<BR> The Requestor Trading Partner's private
>     					workflow did not return a result.<P><BR><BR></CENTER>");
>     				pw.println("<CENTER><IMG SRC=\"Hello1.gif\" WIDTH=650
>     					HEIGHT=220 BORDER=0 NATURALSIZEFLAG=3></CENTER>");
>     			}
>     			pw.println("<P><CENTER><BR> <BR> ");
>     			pw.println("<P><CENTER><A HREF=\"/HelloPartnerLauncher.html\">
>     				<b>Click Here to Run Again</b></A></CENTER></P>");
>     		} catch (Exception e) {
>     			e.printStackTrace();
>     		}
>     	}

Configuring the Secure Audit Log

To configure the secure audit log, complete the following steps:

1. Start the B2B Console and display the WebLogic Integration B2B configuration page, as described in Configuring Security for the WebLogic Integration B2B Engine.

2. Select the Security tab. The B2B Security configuration page is displayed, as shown in the following figure.

   Figure 5-2 WebLogic Integration B2B Security Configuration Page

3. In the field labeled Audit Log Class, enter the fully qualified name of the Java class that implements the secure audit log.

4. Restart WebLogic Server so that the new configuration takes effect.

Using the Service Provider Interfaces (SPIs) for Nonrepudiation

This section describes the SPIs for the following nonrepudiation services:

- Secure Timestamp Service

- Secure Audit Log Service

Using the SPI for the Secure Timestamp Service

WebLogic Integration B2B allows you to create a customized secure timestamp service by implementing the com.bea.security.TimeStampProvider interface. If you implement a timestamp using the SPI described in this section, you must configure this service later in the B2B Console so that the service is invoked properly during run time.

The com.bea.b2b.security.TimeStampProvider interface has the following methods, which a timestamp application must implement:

- String getTimestamp()

This method returns a string specifying the time in Coordinate Universal Time (UTC) format.

- long getTimestampInMillis()

This method returns a string specifying the UTC time in milliseconds.

Your implementation of the timestamp interface must include a default public constructor with no arguments. Neither the constructor nor any methods in the class that implements the TimeStampProvider interface should throw any exceptions.

Using the SPI for the Secure Audit Log

WebLogic Integration B2B allows you to create a secure audit log service by implementing the com.bea.security.AuditLogProvider interface. If you implement an audit log service using the SPI described in this section, you must configure this service later in the B2B Console so that the service is invoked properly during run time.

The com.bea.b2b.security.AuditLogProvider interface has the following methods, which a secure audit log application must implement:

- void init()

This method initializes the audit log.

- void log (java.lang.String component,
  java.lang.String type,
  byte[] data,
  java.lang.String principal)

This method is invoked to log a message in the secure audit log. It has the following parameters:

- java.lang.String component

Contains the component that is logging the message

- java.lang.String type

Specifies the type of the nonrepudiation message

- byte[] data

Contains the data to be logged

- java.lang.String principal

Contains the name of the trading partner who is logging this message

Your implementation of the secure audit interface must include a default public constructor with no arguments. Neither the constructor nor any methods in the class that implements the AuditLogProvider interface should throw any exceptions.

Audit Log Messages

All log messages correspond to the DTD log-message.dtd, which defines the contents for each message type.

All audit log messages have the following three identifiers:

- Location—the location, in WebLogic Integration, in which the message is stored

- Type—the message type

- Data—the actual information that is being logged

The following table describes the contents of the data for each of the message types. All the log messages contain the timestamp obtained from the timestamp provider that is configured in WebLogic Integration.

Message Type | Description
--- | ---
NRR | Nonrepudiation of receipt. Contains that name of the trading partner receiving the business message and the application data.
NRO | Nonrepudiation of origin. Contains the name of the trading partner sender, the business message, and the application data.
APP | Is logged from any trading partner Java class via the Audit.log(byte[] data) method.The data format for this message type is any stringified XML document. Because the application is logging the message, the contents of the data are controlled by the application itself.

Audit Log DTD

The following code example shows the log-message.dtd file:

>     <!ELEMENT LOG (non-repudiation-origin| non-repudiation-receipt | application)>
>     <!ATTLIST LOG  time-stamp CDATA  #REQUIRED >
>     <!ATTLIST LOG location CDATA  #IMPLIED >
>     <!ATTLIST LOG Principal CDATA  #IMPLIED >
>     <!ELEMENT non-repudiation-origin (#PCDATA)>
>     <!ELEMENT non-repudiation-receipt (#PCDATA)>
>     <!ELEMENT application (#PCDATA)>