Network and Communication Security

Your network infrastructure is extremely important in protecting your system. Your network needs to support the communication necessary for your business needs without allowing unauthorized access. A well-defined network topology can eliminate many security threats based on software flaws (at both the operating system level and application level) or network attacks such as eavesdropping. If users cannot log on to your application or database servers at the operating system or database layer, then there is no way for intruders to compromise the machines and gain access to the back-end system’s database or files. Additionally, if users are not able to connect to the server LAN (local area network), they cannot exploit well-known bugs and security holes in network services on the server machines.

The network topology for SAP Jam Integration is based on the topology used by the SAP NetWeaver platform. Therefore, the security guidelines and recommendations described in the SAP NetWeaver Security Guide also apply to SAP Jam Integration.

Communication Channel Security

The table below shows the communication channels used by SAP Jam Integration, the protocol used for the connection and the type of data transferred.

Table 1: Communication Channels
Communication Path	Protocol Used	Type of Data Transferred	Data Requiring Special Protection
Web browser acting as front-end client to SAP Gateway Hub system	OData/REST over HTTP/HTTPS	Application data and security credentials	Security credentials Application data (depending on individual security requirements and the criticality of the data)
SAP front-end system to SAP back-end system containing Collaboration back-end enablement and ABAP SMI	RFC	Application data (during service execution) Remote access to service registry Synchronization of SAP Gateway subscriptions	Application data (depending on individual security requirements and the criticality of the data)
SAP back-end system to SAP front-end system	RFC	Information about proxy host and port Synchronization of SAP Gateway subscriptions	Application data (depending on individual security requirements and the criticality of the data)
ABAP SMI to SAP Jam OData and REST API	OData / REST over HTTPS	Application data and security credentials	Security credentials Application data (depending on individual security requirements and the criticality of the data)
SAP Jam to SAP Gateway Hub system	OData over HTTPS	Application data and security credentials	Security credentials Application data (depending on individual security requirements and the criticality of the data)
Web browser acting as front-end client to Feed Widget in SAP Jam	HTTPS	Application data and security credentials	Security credentials Application data (depending on individual security requirements and the criticality of the data)

RFC connections can be protected using Secure Network Communications (SNC).

HTTP connections are protected using the Secure Sockets Layer (SSL) protocol.

REST Tunnel

Services to be addressed by the REST tunnel need to be explicitly activated (whitelist).

Some services that would expose security tokens through the REST tunnel are blocked by a blacklist. The blacklist cannot be modified.

For more information, see Configuring REST Tunnel.

Cross-Site Request Forgery Protection

Token-based protection against cross-site request forgery (CSRF) is available for the REST tunnel and enabled by default for ABAP Social Media Integration for all dedicated service providers. This is provided as a second level of defense and is necessary for service providers that do not provide CSRF protection, such as SAP Jam.

ABAP SMI is set up to handle CSRF protection in the tunnel, which means that CSRF tokens are always issued by the REST tunnel.

The system behaves as follows:

Non-modifying request used to retrieve a CSRF token
The REST tunnel generates a CSRF token and sends it back in the HTTP response header field X-CSRF-Token. This happens in a non-modifying request (such as GET) if the header field X-CSRF-Token with the value fetch is sent along with the non-modifying request.
Modify request without a CSRF token or with an invalid token
For all modifying requests (such as POST) the application must include this token in an HTTP request header field with the same name (X-CSRF-Token). For all modifying requests, the REST tunnel checks the validity of the CSRF token in the request. If the validation fails, an HTTP status code 403 (Forbidden) is sent back to the client with a message CSRF token is invalid.
Modify request with a valid CSRF token
If a valid CSRF token is sent along with a modifying request, the validation succeeds and normal processing of the request continues.

Cross-Site Scripting Protection

If you use the REST tunnel in conjunction with SAPUI5 components (or within the SAPUI5 framework), several controls that protect against cross-site scripting (XSS) are available. However, if you set up the REST tunnel to work with a different front-end, ensure that you implement proper protection (input validation) to prevent XSS.