Network and Communication Security 

The portal is dependent on SAP NetWeaver Application Server (AS) Java for network communication. The portal network and communication security concept is covered by the security concept for AS Java.

For more information, see SAP NetWeaver Application Server Java Security Guide.

Network Architecture

The network architecture you use depends on how sensitive the applications and data are that you can access through the portal. Many different architectures are possible. For a portal installation that requires a medium level of security or higher, we recommend you use an architecture with multiple network zones.

For more information, see Using Multiple Network Zones.

In this network architecture, the portal server and its underlying AS Java are located in the inner demilitarized zone (DMZ). Any back-end systems such as SAP systems are located in the high security area. User management engine (UME) data sources such as a corporate directory server or an ABAP-based SAP system are also located in the high security area. This setup ensures for the default configuration that the inner DMZ systems have a different subdomain and document domain from the high-security systems. Smooth Web integration is guaranteed for systems in the inner DMZ.

The document domain determines when applications in different frames can interact with each other. Document domains rely on the Same Origin Policy (SOP). An application can only share information with another application if the DNS domain name and protocol are identical. In SAP applications the document domain is relaxed by one level by default, that is, by removing the hostname from the fully qualified hostname. With the relaxed document domain, applications can share information between frames as long as the systems they run on are in the same subdomain. For example, host1.example.com and host2.example.com are in the same relaxed document domain, example.com. The portal integration benefits from the relaxed document domain by enabling features between different portal frames, such as portal eventing, WorkProtect mode, session management, auto resizing, and popup windows over iView borders.

For network architectures, which do not distinguish between an inner DMZ and a high-security area, and therefore benefit from the smother portal integration provided by the relaxed document domain, you must consider the security requirements of the component systems. Document domain relaxing enables applications on different hosts and in different frames to interact, but exposes the applications to cross-frame scripting. If one of your back-end systems has significantly higher security requirements, then you must determine if the benefits provided by document domain relaxing outweigh the risk of scripting attacks by malicious users. To mitigate the risk, you must either move the high-security system to a different subdomain or disable document domain relaxing for applications on the high-security systems. In addition to the portal features described above, you may lose other functions, such as those provided by the BIApplicationFrame.

For more information about disabling document domain relaxing for Web Dynpro ABAP and Web Dynpro Java applications, see the following:

·        For Web Dynpro ABAP, see URL Parameters and Application Parameters.

●      For Web Dynpro Java, see Configuring the Web Dynpro Runtime Environment.

Search and Classification (TREX)

If you are using Search and Classification (TREX) with your portal installation, we suggest that you install the TREX server on a host separate from the portal server. Separate the two servers with a packet-filtering firewall. For optimum security, the TREX server should only be accessible by the portal and not by normal users.

For more information about TREX security, see Search and Classification (TREX) Security Guide.

Federated Portal Network (FPN)

A federated portal communicates with other portals in the network, providing information about remote role assignment and remote delta links. The portal communicates remote role assignment information with SOAPmessages using the HTTP interface of the AS Java. You can secure this interface by configuring the AS Java to use Secure Sockets Layer (SSL). The portal communicates remote delta links with the P4 interface of the AS Java.

Remote delta links do not support SSL, even if you configure the AS Java to encrypt the P4 interface.

Back-End Communication

Client browsers interact with the portal through iViews. The client browser may request information that is not on the portal server. The portal does one of the following depending on the iView being used:

·        The portal or the host AS Java connects directly to back-end systems by either Remote Function Call (RFC) or HTTP.

Protect this communication by enabling Secure Network Communication (SNC) or SSL for the iView.

●      The portal triggers a direct connection between the client browser and the back-end system.

The iView calls the relevant page within an iFrame by means of a redirect (HTTP code 30x) or JavaScript. Protect this communication by enabling SSL for the iView. Where possible, do not include sensitive information in the redirect, such as user name and password. When the iView uses SAP GUI for Windows or SAP GUI for Java, the communication uses dialog (DIAG) protocol, which you can protect with SNC.

Neither the portal nor the AS Java provides a proxy function.

iView Types and Backend Connection

iView Type	Examples	Connection
SAP Connector-Based	RFC BAPI	Client-Portal-Back End
SAP Application	SAP transaction Business Server Page (BSP) Business Warehouse (BW) report Crystal Enterprise reports Internet Application Component (IAC)	Client-Back End When in caching mode, BW caches responses on the portal server, thus the connection is Client-Portal-Back End
Database	Java Database Connectivity (JDBC)	Client-AS Java-Back End
Web-based URL		Client-Back End (default) When the iView property Fetch mode is server-side, then: Client-Portal-Back End
XML-based	RSS	Client-Back End (default) When the iView property Fetch mode is server-side, then: Client-Portal-Back End
Web Dynpro		Client-AS Java-Back End

You must set up access for clients through firewalls to the application server in the back end if the following is true:

·         Your network architecture includes one or more firewalls

·         Your portal integrates iViews that initiate client-backend communication

In the external facing portal scenario, you must configure the translation table (publishing rules) of the application gateway. This enables the application gateway to pass the external address of the back-end system to the client browser. Set the iView property, WAS Host Name to match the external address of the back-end system.