The data exchanged in business-to-business (B2B) messages is often sensitive and requires protection. Secure Socket Layer (SSL) provides protection at the transport level through the confidentiality of data exchanged between two endpoints.

However, such business messages may travel through multiple endpoints. This makes the message authenticity (who sent it?) and integrity (is it changed on its way?) necessary. Also, it is important to have these facts recorded for non-repudiation purposes.

BEA WebLogic Integration http://edocs.bea.com/wli/docs8/1 supports electronic business protocol using eXtensible Markup Language (ebXML) for B2B transactions. The ebXML protocol recommends using XML Digital Signature (XMLDSig) to provide message authenticity and integrity. This article provides an introduction to XMLDSig and describes how to use it with ebXML in WebLogic Integration 8.1.

The Need for Signature in B2B Transactions
Businesses prefer to use the Internet to exchange business documents, as it is a cheap and effective medium compared to expensive, proprietary, and closed networks. The usage of an unreliable and insecure medium such as the Internet brings forth requirements for security of business transactions. Transport-level security that provides encryption, integrity, and authentication at the session level between the endpoints is not enough when messages travel through various intermediate servers. In such cases, confidentiality, authenticity, and integrity need to be provided at the message level. An interoperable and globally accepted message-signing technology is needed to answer questions, such as who sent the message, was the message modified in transit, and can the sender deny sending it, or the recipient deny receiving it?

The rest of this section provides an introduction to signature. It describes what is legally meant by signature, what a digital signature is, the processes of generating and verifying a signature, and, at the end, the introduction of XMLDSig in the context of ebXML.

The subsequent sections describe the anatomy of XMLDSig including requirements from ebXML, as well as the processes of signing and verifying an ebXML message, and provide information on support and configuration of XMLDSig in WebLogic Integration.

Signature
According to the American Bar Association, a signature is not part of the substance of a transaction, but rather of its representation or form. A signature serves the following purposes:

• Evidence: A signature authenticates a writing by identifying the signer with the signed document.
• Ceremony: The act of signing a document calls to the signer's attention the legal significance of the signer's act, and thereby helps prevent inconsiderate engagements.
• Approval: In certain contexts defined by law or custom, a signature expresses the signer's approval or authorization of the writing, or the signer's intention that it has legal effect.
• Efficiency and logistics: A signature on a written document often imparts a sense of clarity and finality to the transaction and may lessen the subsequent need to inquire beyond the face of a document.

• Integrity: The data has not been changed, destroyed, or lost in an unauthorized or accidental manner.
• Message authentication: A signature identifies what is signed, making it impracticable to falsify or alter either the signed matter or the signature without detection.
• Signer authentication: A signature indicates who signed a message. It should be difficult for another person to produce without authorization.

1. A hash function is applied to the data to be signed to generate a digest.
2. The private key of the signer is applied to the digest of the data to be signed using a cryptographic signing function to produce a digital signature.
3. The data and digital signature are sent to a recipient in some associative form such as an envelope.

1. The same hash function that was used while signing the message is applied to the received data to compute a digest.
2. The verifying function is applied using the signer's public key to find out if the signature was signed using the signer's private key and to verify if the computed digest and the digest that was transformed into the received signature are the same.
3. Lastly, the signer's public key is verified.

Why Use XML Digital Signature with ebXML?
XML has become a lingua franca for business transactions conducted over the Internet as it is text based, Internet friendly, and provides a semistructured data format. Also, when a document is exchanged between several participants who may process only a portion of the document, which often is the case in business processes, a technology is needed to selectively sign only a portion of a document. The W3C/IETF joint XML Signature (XMLDSig) is the technology that leverages the power of XML and provides selective signing of documents. Therefore, the ebXML-MS specification mandates XMLDSig as the technology to use to sign the ebXML messages.

Anatomy of an XML Signature in the ebXML SOAP Envelope
Figure 4 shows the anatomy of an XMLDSig and the subsequent paragraph provides a brief description of each element, including values recommended by the ebXML-MS for certain elements, as well as the relationship between these elements.

The SOAP Header of an ebXML message may contain zero or more Signature elements. The first such element must be signed by the From party of the ebXML message.

Each Signature element contains one SignedInfo element, which consists of the information signed.

The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. For ebXML-MS, www.w3.org/TR/2001/REC-xml-c14n-20010315 (c14n) is the recommended algorithm.

The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm, a key dependent algorithm, and possibly other algorithms such as padding. The ebXML-MS recommends www.w3.org/2000/09/XMLDSig#dsa-sha1.

The signature can contain references to one or more data (payload) objects in the ebXML message. Each Reference element includes the digest method and the digest value calculated over a data object. The optional URI attribute of the Reference identifies the data object to be signed. A URI with the value "" identifies the node-set (without comment nodes) of the XML resource containing the signature while the value of the MIME content-id identifies a payload part of the ebXML message.

Transforms in Reference is an optional ordered list of processing steps that are applied to the data object's content before it is digested. Transforms can include operations such as canonicalization, encoding/decoding (including compression/inflation), XSLT, XPath, XML Schema validation, etc. The three transforms required for signing ebXML messages are:

1. Enveloped Signature (www.w3.org/2000/09/XMLDSig#enveloped-signature): Signature is over the SOAP Envelope that contains the signature(s) as an element.
2. XPath (www.w3.org/TR/1999/REC-xpath-19991116): With expression to exclude signing elements with attributes such as actor that could change as the message passes through intermediaries. It is

   not(ancestor-or-self::node()[@SOAP-ENV:
   actor='urn:oasis:names:tc:ebxml-msg:actor:nextMSH'] |
   ancestor-or-self::node()[@SOAP-ENV:actor=
   'http://schemas.xmlsoap.org/soap/actor/next'])

3. Canonicalization of the SOAP Envelope using www.w3.org/TR/2001/REC-xml-c14n-20010315

KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information.

Object is the element where arbitrary data may be placed. An Object element is merely one type of digital data that can be signed via a Reference.

The Process
This section describes the processes of generating a signature for an ebXML message to be sent, and validating the signature when that message is received.

Let's say that the company ABC, Inc., buys laptops from company XYZ, Inc. These companies exchange business messages using ebXML-MS v2.0. Quote is a signed business document sent by XYZ (From party) in response to the QuoteRequest message received from ABC (To party) as shown in Figure 5.

XYZ uses the following attributes to sign the Quote message.

• Signature algorithm: www.w3.org/2000/09/XMLDSig#rsa-sha1
• Digest algorithm: www.w3.org/2000/09/XMLDSig#sha1
• Canonicalization algorithm: www.w3.org/TR/2001/REC-xml-c14n-20010315
• X509 certificate of the signer party, XYZ, is encoded with the signature as X509Data of KeyInfo.

1.  Reference Generation for each data object to be signed:
a. Apply the three Transform(s) recommended by ebXML-MS.
b. Calculate the DigestValue for the transformed object using the SHA1 algorithm.
c. Create the Reference element including the URI for the referred object ("" for the SOAP Header containing the Signature or the value of the Content-id for the payload part with the Quote document), DigestValue, and DigestMethod used.

2.  Signature Generation:
a. Create SignedInfo with SignatureMethod, CanonicalizationMethod, and Reference(s).
b. Canonicalize the SignedInfo using the algorithm c14n.
c. Calculate SignatureValue for SignedInfo using the RSA-SHA1 algorithm and the private key of the Signer, XYZ.
d. Create the Signature element and include SignedInfo, SignatureValue and KeyInfo with the X509 certificate chain of XYZ.

3.  Packaging:
a. Package Signature as a SOAP Header.
b. Package ebXML multipart message with a SOAP Envelope and a payload part containing the Quote document as MIME parts.

Listing 1 (the code for this article is online at www.sys-con.com/weblogic/sourcec.cfm) shows an example of a signed ebXML message.

Validation of a Signed Message
This section describes the signature validation process. The process consists of four main parts: unpacking the signature from message, signature validation, reference validation, and signer verification as shown in figure 7.

1.  Unpack Signature
a. Obtain the Signature from the SOAP Envelope Header
b. Extract the KeyInfo, SignedInfo and SignatureValue from the Signature
c. Canonicalize SignedInfo using the c14n algorithm.

2.  Signature Validation
a. Extract XYZ's public key from the KeyInfo
b. Apply XYZ's public key and SignatureMethod RSA-SHA1 to validate the SignatureValue of the SignedInfo

3.  Reference Validation for each signed object
a. Get the data object to be digested. This should be obtained by de-referencing the URI of the Reference and applying Transform(s).
b. Calculate the digest of the data obtained above using SHA1 as the DigestMethod.
c. Compare this digest with the value in the DigestValue received for this Reference.

4.  Verifying the Signer
a. Validate XYZ's certificate; this may include time validity, host name verification, key usage, basic constraint checks, etc.
b. Validate XYZ's certificate chain. Make sure none of the certificates in the chain are revoked.
c. If ABC and XYZ had exchanged their certificates off-band, make sure that the received certificate's fingerprint matches with the one stored in ABC's database.

XMLDSig and ebXML in WebLogic Integration
BEA WebLogic Integration provides a J2EE and XML standard-based integration platform to enterprises to integrate business processes with various back-end systems and trading partners. The Trading Partner Integration module of WebLogic Integration helps enterprises automate and manage relationships with customers, suppliers, distributors, and other trading partners by providing support for business transactions conducted using ebXML and other protocols.

The ebXML protocol in WebLogic Integration uses XMLDSig for signing messages. This support consists of the following:

1. Signing of ebXML Message with attachment(s).
2. Signed acknowledgements for ebXML-MS 2.0
3. KeyInfo including X509Data with Signer's certificate chain
4. Signature algorithms
   a. www.w3.org/2000/09/xmldsig#rsa-sha1
   b. www.w3.org/2000/09/xmldsig#dsa-sha1
5. Digest algorithm: www.w3.org/2000/09/xmldsig#sha1
6. Canonicalization algorithm: www.w3.org/TR/2001/REC-xml-c14n-20010315
7. Transform algorithms:
   a. www.w3.org/2000/09/xmldsig#enveloped-signature
   b. www.w3.org/TR/2001/REC-xml-c14n-20010315
   c. www.w3.org/TR/1999/REC-xpath-19991116 (with default XPath expression mandated by ebXML-MS)

Assumptions

• XYZ, Inc., uses WebLogic Integration. A WebLogic Integration domain is already created with custom keystores.
• Trading partners ABC and XYZ have obtained public key certificates from recognized Certificate Authorities. These certificates have RSA public key and necessary key usage for signing messages.
• XYZ offers a quote service using QuoteService.jpd as a BEA WebLogic Integration business process. This process receives the QuoteRequest document and responds with the Quote document. This process is already deployed in the WebLogic Integration domain.
• ABC's system is running and ready to send QuoteRequest to XYZ. It has XYZ's public key certificate in its database.

1. Start WebLogic Integration server and log in to the WebLogic Integration console.
2. Click Trading Partner Management->Profile Management.
3. Create a Partner Profile for XYZ.
   a. Click Create New and fill all necessary information for XYZ. Make it a LOCAL trading partner. Click Add Profile.
   b. Click Add Binding, select ebXML 2.0 and click Create Binding.
   c. Change the Endpoint information. Click Add Certificate where Signature Certificate is required.
   d. Choose Import certificate from file and click Next.
   e. If the private key is password protected, you will have to create a password alias using Add alias.
   f. Provide the location of the private key and certificate for XYZ and enable the Import Certificate In KeyStore checkbox. Click Create Certificate. This private key and certificate is used to send a signed Quote from XYZ to ABC.
   g. Enable the Signature Required checkbox and click Add Binding.
4. Create a Partner Profile for ABC.
   a. Follow steps 3a-3d above for ABC, but specify ABC as a REMOTE trading partner.
   b. Provide the location of the file where the public key certificate of ABC is kept. Enable the Import Certificate In KeyStore checkbox. Click Create Certificate. This is needed to complete the signer verification process in case ABC sends signed messages to XYZ.
   c. Enable the Signature Required checkbox and click Add Binding. This indicates that ABC is expecting signed documents from XYZ.
5. Create a ServiceProfile between XYZ and ABC for service QuoteService.jpd by following the steps from Trading Partner Management->Service Management.
6. A third-party plug-in to perform certificate verification can be configured in WebLogic Integration as described in Trading Partner Integration Security.
7. To enable nonrepudiation, configure a Secure Audit Log provider. Follow the steps described in "Trading Partner Management" for more information.

References