Message-Level Security

Message-level security allows you to digitally sign or encrypt documents exchanged between systems or business partners. It improves communication-level security by adding security features that are particularly important for inter-enterprise communication. Message-level security is recommended and sometimes a prerequisite for inter-enterprise communication.

?     A digital signature authenticates the business partner signing the message and ensures data integrity of the business document carried by a message.

Signatures are used in two scenarios:

0     Non-repudiation of origin

The sender signs a message so that the receiver can prove that the sender actually sent the message.

0     Non-repudiation of receipt

The receiver signs a receipt message back to the sender so that the original sender can prove that the receiver actually received the original message.

?     Message-level encryption is required if message content needs to be confidential not only on the communication lines but also in intermediate message stores.

SAP NetWeaver usage type Process Integration (PI) offers message-level security for the XI protocol itself, for the RosettaNet protocol, for the CIDX protocol, and for the SOAP and Mail adapters. The table below summarizes the message-level security features of these protocols and adapters.

Message-Level Security Features

XI Protocol (XI 3.0)



RNIF 2.0


Messaging components

Integration Server and PCK

Adapter Engine and PCK

Adapter Engine

Adapter Engine

Adapter Engine







Non-repudiation of origin



(Web service security)




Non-repudiation of receipt











Web service security (XML signature)

Signed parts are the SAP main header, the SAP manifest, and the payloads (SOAP attachments).

Encrypted parts are the payloads (SOAP attachments).


Web service security (XML signature)

The SOAP body is signed.




XI 3.0 is the XI protocol valid for both SAP NetWeaver ґ04 and SAP NetWeaver 2004s.

Message-level security is not guaranteed across the entire communication path of a message, but only for the intended B2B connections, which can be the following communication paths, as described under Service Users for Message Exchange.

?     XI protocol

0     (s4) Integration Server to Integration Server, PCK to Integration Server

0     (r4) Integration Server to Integration Server, Integration Server to PCK

?     SOAP protocol

0     (s3) SOAP sender to Adapter Engine or PCK

0     (r3) Adapter Engine or PCK to SOAP receiver

?     Mail protocols

0     (s3) Mail server to Adapter Engine or PCK (IMAP4/POP3)

0     (r3) Adapter Engine or PCK to mail server (IMAP4/SMTP)

?     RNIF and CIDX protocol

0     (s3) RNIF or CIDX sender to Adapter Engine

0     (r3) Adapter Engine to RNIF or CIDX receiver

You define whether and how message-level security is to be applied to messages in the Integration Directory by using sender agreements on the inbound (sender) side in scenarios (s3) and (s4) and by using receiver agreements on the outbound (receiver) side in scenarios (r3) and (r4). For more information about configuring message-level security, see Security Configuration at Message Level.

Message-level security relies on public and private x.509 certificates maintained in the J2EE keystore, where each certificate is identified by its alias name and the keystore view where it is stored. Certificates are used in the following situations:

?     When signing a message, the sender signs it with its private key and attaches its certificate containing the public key to the message.

The receiver then verifies the digital signature of the message with the sender’s certificate attached to the message. There are two alternative trust models to verify the authenticity of the sender’s public certificate:

0     In the direct trust model, the signer’s public key certificate is compared with the locally maintained, expected public key certificate of the partner. Therefore, the direct trust model requires offline exchange of public key certificates, which can be self-signed or issued by a CA.

0     In the hierarchical trust model, the signer’s public key certificate is validated by a locally maintained public certificate of the CA that issued the signer’s public certificate. In addition, the subject name and the issuer of the signer’s certificate is compared with the expected partner’s identity configured in a receiver agreement on the receiver side.

Generally, the hierarchical trust model enables chains of certificates attached to the message. The XI 3.0 message format, however, does not support such chains; the certificate used for signing has to be signed by a root CA.

In the hierarchical trust model, the sender and the receiver only need to agree upon the CA and the subject name that the sender has used in its certificate.

The following trust models are supported:

0     The RNIF and CIDX adapters support both a direct and a single-level hierarchical trust models.

0     The XI protocol and the SOAP adapter (with Web service security) only support a single-level hierarchical trust model.

0     The Mail adapter and the SOAP adapter (with S/MIME) support a multi-level hierarchical trust model.

?     When encrypting a message, the sender encrypts with the public key of the receiver (also verifying the correctness of the receiver’s certificate by using the public key of the certificate’s root CA).

The receiver decrypts with its private key certificate.

For more information about the certificate store, see Certificate Store.

Whenever a message is signed, the receiver archives the signed messages for non-repudiation purposes. See Archiving Secured Messages.