This section describes those aspects of security for SAP Web applications that are related to network integration. This includes the network topology, firewalls, Web servers, communication encryption, and so on. You can find additional information, especially about application security, in the SAP Library under BC Basis Components – Frontend Services and in the SAP Security Guide (available in SAPnet underhttp://sapnet.SAP-ag.de/securityguide ).
When connecting to the Internet, you need to protect your system from unauthorized access and other intruders. Although we refer to the Internet throughout this discussion, Intranet applications may also require a certain degree of protection, depending on your security policy. The following information also applies to Intranets.
All security considerations require that you have a clear security concept. You cannot make any application absolutely secure. Instead you need to lay down the components of your application, then try to consider all possible threats (for example, unauthorized access and denial-of-service intrusions), define the severity of these consequences, and classify which are acceptable and which are not. You must have this concept in written form and refer to it for every security measure.
Secure Network Infrastructure for the ITS
The SAP Internet architecture has many built-in security features, such as being able to run the WGate and AGate on separate hosts. This is important because the WGate usually contains no sensitive information. The AGate, however, may contain information like SAP System passwords which need to be protected.
We strongly recommend setting up a network infrastructure that makes use of these features to control access from the Internet to sensitive application components and internal networks.
To do this, you can make use of specific security components, such as firewalls, packet filters and SAProuters to separate the individual parts of the network from each other. This ensures that unauthorized access is restricted to a small part of the system and cannot harm your internal network and the SAP System. The following graphic shows some of the components that you can use to build a secure network architecture when using ITS:
You may decide to implement some or all of these components depending on your security policy. You can find details about the components and a concrete example of a network setup in the sections below.
Our recommended network topology consists of three separate network segments that are connected by two firewall systems. The least secure network is the Internet itself. This is where the Web browser is located.
Protecting the Web Server
The Web server is protected by the first firewall system The Web server must be protected against any kind of network packets that are not needed for HTTP communication. To accomplish this, configure the router to pass packets to the corresponding TCP port only.
Usually a Web server requires one TCP service. Port number 80 is reserved for HTTP and used by default by all servers and browsers. HTTPS (HTTP plus the Secure Sockets Layer protocol), uses TCP port number 443 by default.
Configure the Web server operating system to be as closed and restrictive as possible. Disable any unnecessary network services.
Protecting the Internal Network and AGate Server
We strongly recommend taking additional measures to separate the Web server from your internal corporate network, such as using a firewall system and/or SAProuter. This prevents additional damage if an intruder manages to gain control of the Web server. We recommend keeping the AGate in your internal network.
The connection between WGate and AGate can be relayed by a SAProuter. For a detailed description of the SAProuter functionality and administration, see the SAP Library under BC SAProuter (BC Basis Components – Client Server Technology). You can configure the SAProuter to relay only the WGate–AGate connection and deny all other connection attempts. See SAP Online documentation ITS Administration Guide on how to configure ITS with SAProuter (BC–Basis ® Frontend Services ® Internet Transaction Server).
You can use other firewall products to relay the TCP connection from the WGate to the AGate. See the documentation for your firewall for further information.
Protecting the SAP Server
For very high security demands, the SAP server network can be protected with a firewall and SAProuter as described inNetwork Security.
To protect the AGate from unauthorized access in the internal network, place the AGate in the server network. In this way, the AGate is protected with the same mechanisms that protect your SAP servers.
To achieve maximum protection from the Internet, place the AGate outside of the server network. Because the AGate communicates with the SAP application server in the same way as the typical SAPgui (using DIAG or RFC) no special measures are necessary for the connection between the AGate and the SAP System.
Example of a Network Configuration
The following graphic shows an example network security infrastructure suitable for Internet access to SAP using the SAP Internet Transaction Server:
The security of the network zones increases from left to right. The first router/packet filter allows direct access from the Internet to the Web server's TCP ports only. It never routes any packet directly to the second router, so no packets get directly from the Internet into the internal network. This is why the Web server network is called the demilitarized zone. The second router/packet filter is configured to deny any direct access from the Web server network to any host in the corporate network except for the SAProuter (TCP port and host). Therefore, the connection from the WGate to the AGate can only be transmitted through the SAProuter. In the example, the AGate is located in the SAP server network. The server network is connected to the client network through a router that may also provide access restriction.
If you want, and as mentioned in the previous section, you can also place a router/packet filter between the AGate and the SAP application server. This provides additional protection if an intruder manages to exploit any security hole of the AGate or the operating system it is running on.
In the above example, we have displayed a setup using standard network and computer components. Many vendors offer specialized firewall products for these tasks. You may use such products; however, we do not describe them in more detail here in this guide.
You can use cryptographic methods to increase the security of all network connections involved in an ITS application.
Browser – Web Server
All data (including passwords) is usually transmitted through the Internet without being encrypted. To maintain confidentiality for this data, you can encrypt the connection between the Web server and browser. The SAP-supported Web servers and all modern browsers support the encryption of the HTTP data stream by using the Secure Sockets Layer protocol (SSL), also known as HTTPS. HTTPS data streams are completely transparent to the ITS. For more details regarding encryption techniques, see the documentation supplied by the Web server manufacturer.
To use SSL encryption, the Web server must obtain a certificate for its public key. This certificate is referred to in this section as the server certificate. It is used by the browser to authenticate the server, and is issued by a Certification Authority (CA). If the browser receives a server certificate issued by a trusted CA, then the browser can verify that it is connected to the intended server. This is the precondition for the secure connection to be established.
If you want to offer a service to all Internet users, this server certificate must have been issued by an official CA that is trusted by most browsers used in the Internet. For internal users, you can set up a corporate CA and configure the browsers to trust this CA.
WGate – AGate
By default, the data sent between WGate and the AGate is sent as clear text. You can choose a different connection type which encrypts the data with a DES algorithm using a static key. This key is not configurable; therefore, this encryption provides protection only against accidental reading of the data, but not against serious attacks.
For better protection you can use SAP's Secure Network Communication (SNC) to protect the link between the WGate and AGate. SNC uses an external security product to apply encryption to communication links between components of an SAP System. It offers different levels of protection, depending on the cryptographic product you use. SeeNetwork Security.
AGate – SAP System
The connection between AGate and SAP System can also be protected with SNC.
In the Internet scenario, you do not necessarily know which users want to access the application data in the SAP System. In addition, due to the large number of Internet users, you normally cannot set up a separate account for each user. Therefore, if you want to make certain Internet Application Components available to anonymous Internet users, you normally set up service users with predefined passwords in the SAP System. These users should have only the permissions necessary to access the application (for example, a product catalog). The corresponding ITS service is configured with this logon information to include the password. If you need to further authenticate the Internet user (for example, when an order is placed), the application itself must perform the additional authentication. (For example, the application verifies the customer number and password using corresponding function calls.)
For each application that is accessible over the Internet, you must create a service file, which is located on the AGate. This file contains information that is specific to the application (for example, the SAP transaction to start, the SAP client, the service user name and password to use). The ITS needs this information to run the application. The password does not appear as clear text in the service file, but is encrypted using a static key. Therefore, if you have service users with authorizations that are worth protecting, then take special care to protect the AGate service files from unauthorized access.
ITS does not store any security-relevant information on the WGate.
In an Intranet or Extranet scenario, users can log on to SAP over the ITS using their SAP user name and password. User names and passwords are not stored permanently in the ITS in this case. User authentication takes place entirely within the SAP System. Internet Application Components are subject to the usual SAP authorization concept, just like any other SAP transactions.
Named Users with Browser Certificates
Certificates on the client browser can also be used to identify the user in the SAP System (R/3 Release 4.5 or higher). This eliminates the need for the user to enter a logon name and password. It can be used for all IACs that require a named SAP user. A description of the basics of this technology follows. See X.509 Certificate Logon over the ITS for details (in SAPnethttp://sapnet.sap-ag.de/systemmanagement à Media Center à Security à Literature).
The most common form of client certificates use the X.509 standard. Certificates are issued by a certification agency (CA) and installed in the browser. The Web server verifies the certificate's validity and extracts the user name (also called a distinguished name, or DN). The certificate is passed to the SAP System which logs on the corresponding user without password check. To ensure that the DN can be trusted, secure network connections have to be used along the entire path of communication.
You can either use a commercial CA (for example, Verisign Inc.) or set up your own CA.
Web servers can be configured to accept only connections that present a valid certificate. This can be used as an access control mechanism, especially if only certificates issued by a certain (for example, your own) CA are allowed.
ITS Session Integrity
To maintain the integrity of the multi-step transactions when using IACs, the ITS issues a unique session ID number when the first request is made by the user. This session ID is sent to the browser with the first HTML page. It must be passed back to the ITS with every successive request. The session ID is used by the ITS to identify the correct session context. It also ensures that another user cannot easily take over a current session. If you need even stronger protection of user sessions, you can use HTTPS.
Old versions of ITS rely on HTTP cookies to store the session ID. In current ITS versions a cookie is needed only for user identification across multiple services. If you do not need this feature, you can disable the sending of cookies.
Client IP Addresses
As an additional security feature, the ITS stores the client IP address along with the session ID. A possible eavesdropper, who listens in on the network connection and thus acquires the current session ID, cannot easily issue a fake reply. (Their IP address does not match that of the original user.)
You can configure the number of significant bytes used for the network address comparison. On the AGate, the following registry key specifies a mask of the significant network address bits:
The default value is 255.255.255.255, which specifies that the entire address should be compared. Enable this value for an Intranet solution. For Internet applications, we recommend entering a value of 255.255.0.0. In this case, only the leading figures of a network address are compared. This allows clients who use multiple Web proxy servers with load balancing to access the ITS.
Search engines are a valuable tool for every user of the Internet. They allow you to search a large portion of all existing Web pages for words or phrases to find some piece of information. In order to build their indexes, most search engines traverse the Web by following all links in all Web pages they find. A program that does this is called a "crawler", or more generally, a "robot". The crawling procedure is very effective, but there are some problems. If a link directs the robot into one of your Internet applications, the robot follows all links into the application. But since the information is dynamically generated, it is not suitable for inclusion in a static index. Also the robot's requests impose additional load on your server.
The Standard for Robot Exclusion (SRE) provides a method to exclude robots from certain parts or all of a servers resource space. There is no easy way to prevent a robot from disobeying this exclusion, but most robots adhere to the standard.
Before accessing a site, an SRE-compliant robot checks the filerobots.txt in the root directory of the server (for example, http://www.yourcompany.com/robots.txt ). This file contains rules that tell the robot which parts of the server are accessible and which are not. If you run an SAP ITS, your robots.txt must contain at least the following lines:
# This is a comment line
This way the robot stays away from the Internet Application Components on your server. You could also disallow your entire server by specifying "Disallow: /" . But you may want to allow the robots access to the general part of the server so that prospective customers can find your service through the search engines.
Note that robots are not just an issue in the Internet, but also in corporate intranets where search engines are often used to build an index of corporate information.