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:
○ 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 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) |
Web Services |
SOAP |
RNIF 2.0 |
RNIF1.1/CIDX |
|
Messaging components |
Integration Server and PCK |
Integration Server |
Advanced Adapter Engine and PCK |
Advanced Adapter Engine |
Advanced Adapter Engine |
Advanced Adapter Engine |
Signature |
X |
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 |
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). |
Web service security |
S/MIME or Web service security (XML signature) The SOAP body is signed. |
S/MIME |
S/MIME |
PKCS#7 |
XI 3.0 is the XI protocol valid for all SAP NetWeaver versions.
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
○ (s4) Integration Server to Integration Server, PCK to Integration Server
○ (r4) Integration Server to Integration Server, Integration Server to PCK
● WS protocol
○ (s1) WS sender to Integration Server
○ (r1) Integration Server to WS receiver
● SOAP protocol
○ (s3) SOAP sender to Advanced Adapter Engine or PCK
○ (r3) Advanced Adapter Engine or PCK to SOAPreceiver
● Mail protocols
○ (s3) Mail server to Advanced Adapter Engine or PCK (IMAP4/POP3)
○ (r3) Advanced Adapter Engine or PCK to mail server (IMAP4/SMTP)
● RNIF and CIDX protocol
○ (s3) RNIF or CIDX sender to Advanced Adapter Engine (not for local processing on the Advanced Adapter Engine)
○ (r3) Advanced Adapter Engine to RNIF or CIDX receiver (not for local processing on the Advanced Adapter Engine)
You
define in the Integration Directory whether and how message-level security is
to be applied to messages. For this purpose, you use sender agreements on the
inbound (sender) side in scenarios (s3) and (s4) and receiver agreements on
the outbound (receiver) side in scenarios (r3) and (r4). More information about configuring message-level
security:
Security Configuration
at Message Level.
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 XI protocol and the SOAP adapter (with Web service security) only support a single-level hierarchical trust model.
○ The Mail adapter and the SOAP adapter (with S/MIME) support a multi-level hierarchical trust model.
○ The WS runtime supports both a direct and 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 about the certificate store: Certificate Store.
Whenever a message is signed, the receiver archives the signed messages for non-repudiation purposes. More information: Archiving Secured Messages.