Show TOC

Background documentationMessage-Level Security Locate this document in the navigation structure

 

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:

    • Non-repudiation of origin

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

    • 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 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)

SOAP

Mail

RNIF 2.0

RNIF1.1/CIDX

Messaging components

Advanced Adapter Engine

Advanced Adapter Engine

Advanced Adapter Engine

Advanced Adapter Engine

Advanced Adapter Engine

Signature

X

X

X

X

X

Non-repudiation of origin

X

X

(Web service security)

X

X

Non-repudiation of receipt

X

X

X

Encryption

X

X

X

X

Technology

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).

S/MIME or

Web service security (XML signature)

The SOAP body is signed.

S/MIME

S/MIME

PKCS#7

Note Note

XI 3.0 is the XI protocol valid for all SAP NetWeaver versions.

End of the note.

Message-level security is not guaranteed across the entire communication path of a message, but only for the intended business-to-business connections, which can be the following communication paths, as described under Business Communication.

  • XI protocol

    Note Note

    This communication is configured using the SOAP adapter and choosing XI 3.0 as Message Protocol.

    End of the note.

    • (s4) Advanced Adapter Engine (AAE) to AAE

    • (r4) AAE to AAE

  • SOAP protocol

    • (s3) SOAP sender to Advanced Adapter Engine

    • (r3) Advanced Adapter Engine to SOAP receiver

  • Mail protocols

    • (s3) Mail server to Advanced Adapter Engine (IMAP4/POP3)

    • (r3) Advanced Adapter Engine to mail server (IMAP4/SMTP)

  • RNIF and CIDX protocol

    • (s3) RNIF or CIDX sender to Advanced Adapter Engine

    • (r3) Advanced Adapter Engine to RNIF or CIDX receiver

    Note Note

    Note that using the Advanced Adapter Engine Extended integration processes cannot be used. Therefore, those scenarios of the business package that use integration processes are not supported in that case.

    End of the note.

You define in the Integration Directory whether and how message-level security is to be applied to messages. For this purpose, you use integrated configurations to configure the sender side in scenarios (s3) and (s4) and integrated configurations to configure the receiver side in scenarios (r3) and (r4).

Message-level security relies on public and private x.509 certificates maintained in the AS Java 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:

    • 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.

    • 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.

      In general, 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:

    • The RNIF and CIDX adapters support both a direct and a single-level hierarchical trust model.

    • 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.

More information: