Hi,
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)
Messaging components
Integration Server and PCK
SOAP
Adapter Engine and PCK
Mail
Adapter Engine
RNIF 2.0
Adapter Engine
RNIF1.1/CIDX
Adapter Engine
IIly
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
XI 3.0 is the XI protocol valid for both SAP NetWeaver ´04 and SAP NetWeaver 7.0.
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
● SOAP protocol
○ (s3) SOAP sender to Adapter Engine or PCK
○ (r3) Adapter Engine or PCK to SOAP receiver
● Mail protocols
○ (s3) Mail server to Adapter Engine or PCK (IMAP4/POP3)
○ (r3) Adapter Engine or PCK to mail server (IMAP4/SMTP)
● RNIF and CIDX protocol
○ (s3) RNIF or CIDX sender to Adapter Engine
○ (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 senderu2019s certificate attached to the message. There are two alternative trust models to verify the authenticity of the senderu2019s public certificate:
○ In the direct trust model, the signeru2019s 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 signeru2019s public key certificate is validated by a locally maintained public certificate of the CA that issued the signeru2019s public certificate. In addition, the subject name and the issuer of the signeru2019s certificate is compared with the expected partneru2019s 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:
○ The RNIF and CIDX adapters support both a direct and a single-level hierarchical trust models.
○ 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.
● When encrypting a message, the sender encrypts with the public key of the receiver (also verifying the correctness of the receiveru2019s certificate by using the public key of the certificateu2019s 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.
reg,
suresh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.