With this variant, SAP NetWeaver uses industry-specific business packages to support the integration of both new and existing industry standards. The business packages contain the collaboration knowledge defined by the respective industry standards, and the technical adapters required for the transport, routing, and packaging of industry-specific messages.
The technical adapters provided are:
● The RNIF adapter for the RosettaNet industry standard for the high tech industry
● The CIDX adapter for the chemical industry
Both adapters run in the central or non-central Adapter Engine.
The Adapter Engine connects senders and receivers that do not speak the XI message protocol by handing over messages to the Integration Engine and the other way round.
In addition to the central Adapter Engine, non-central Adapter Engines can be installed on an SAP NetWeaver AS Java without Integration Engines. There may be any number of non-central Adapter Engines, each associated with exactly one Integration Server with which the Adapter Engine communicates using the XI protocol.
The following security aspects apply:
● Propagating user identities
User identity propagation should not be used for B2B communication, because external users cannot be distinguished from internal users.
See also: 
● User authorization
Access control lists (ACLs) can be defined in the Integration Directory for the RNIF and CIDX adapters.
See also:
● 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.
However, message-level security is not guaranteed across the entire communication path of a message, but only for the intended B2B connections, which means the following communication paths when the RNIF or CIDX adapter is involved:
RNIF and CIDX protocol
○ RNIF or CIDX sender to Adapter Engine
○ Adapter Engine to RNIF or CIDX receiver
The RNIF and CIDX adapters support both a direct and a single-level hierarchical trust model.
See also:
● Network and communication security
Depending on the protocol used, all data (including passwords) is usually transmitted through the network (intranet or Internet) in plain text. To maintain the confidentiality of this data, you should apply transport-layer encryption for both internal communication and message exchange.
For an overview of supported security mechanisms on transport level, see
● Communication ports
For the configuration of a process integration landscape, it is necessary to know the network addresses, the ports, and further information such as Internet addresses, to be able to define rules for the security components of the network (such as firewalls and proxies).
For messaging components, you have to distinguish between push mode and pull mode. For push mode protocols and adapters, like the RNIF and CIDX adapters, certain ports and addresses are used for incoming messages.
See the table in
Depending on the usage scenario, the risk assessment of the network infrastructure, and a company’s security policy, appropriate security measure should be taken.
The most critical case is where PI is used for B2B messaging and the business partner sends HTTP messages over Internet connections that are not secure. In this case, we strongly recommend that you use secure messaging connections and security components such as firewalls and application gateways to prevent attackers from eavesdropping or modifying messages.
Depending on the security requirements, a dedicated Integration Server for B2B messaging can be added in a separate network zone. This provides enhanced security because it impedes direct access from the Internet to the more critical A2A Integration Server and A2A Adapter Engines.
See also:
● Adapter-specific security configuration
Each adapter is configured by an adapter-specific configuration for both the inbound (sender) side and the outbound (receiver) side. You make these configuration settings in a sender agreement for the inbound side and a receiver agreement for the outbound side, together with adapter-specific channels referenced in the agreements.
○ See
○ See
No comments:
Post a Comment