S 4.266 Secure configuration of the SAP Java Stack
Initiation responsibility: Head of IT, IT Security Officer
Implementation responsibility: Administrator
The Java stack of an SAP system allows the use of Java-based technologies. Java-based technologies are primarily used in web-based scenarios. In contrast to the ABAP stack, the Java stack is relatively new and its functions are used much less frequently. The new Java-based technologies are a supplement to the ABAP environment so that the importance of the Java stack will increase in the future. Business-related functions may still be operated in the ABAP stack, but the front-end components will be implemented in Java. The Java stack is formed by an application server that implements the J2EE (Java 2 Enterprise Edition) specification.
Since the Java stack and the ABAP stack are integrated into the NetWeaver Application Server and can communicate with each other via the JavaConnector (JCo), an installed Java stack needs to be secured. However, the Java stack requires security mechanisms and concepts completely different from those of the ABAP stack.
The most important steps from a security perspective which must be performed when specifying the initial configuration of the Java stack are outlined below . The descriptions are limited to the configuration of the application server and do not deal with any other applications installed.
Java stack installation
The Java stack should only be installed on SAP system versions permitting the separate installation of the Java stack (versions lower than version 6.40) if Java-based products or applications are used on the system.
If the Java stack cannot be installed separately and will not be used, the configuration must be specified in such a way that it is impossible to access the Java stack. For this, all services of the Java stack must be deactivated.
Training on the use of the Java stack
Administrators administrating the Java stack must possess knowledge of the J2EE architecture and of the security concepts in the J2EE architecture. Knowledge of the static security configuration for J2EE-compliant objects specified by the administrator using the administration tool is particularly necessary in this case. For this, a role-based security concept is used. It must be taken into consideration that SAP has extended the J2EE Java Authentication and Authorization Service (JAAS) by adding the SAP-specific User Management Engine (UME) functionality. This enables the static configuration of the security settings to be extended dynamically by the program code, which can be controlled using the UME. In the UME, it is therefore possible to combine the actions allowed in the programs and consolidate them in roles, for example. Users can then be assigned to these roles so that they obtain the authorisations they need.
Administrators must also be aware that the Java stack is equipped with its own, separate user and authorisation management system, which means that administrative tasks always need to be performed in this system. It is recommended in this case to use the UME (see also S 2.341 Planning the use of SAP), since this reduces the number of administrative tasks to be performed.
Disabling unneeded services
The Java stack offers a large range of services. Not all services are needed in every scenario for operation. For this reason, all unneeded services should be deactivated for security reasons. One problem in this context is that services may depend on each other. Furthermore, there are system services and non-system services. The Java stack is administrated using a separate Java tool, the "Visual Administrator". This tool can also be used to administrate the individual services. For this, the services can be found in the "server" section of the object tree used as a navigation aid in the Visual Administrator. Detailed information on a service is displayed as soon as it is selected.
The following procedure is recommended:
- First, it must be determined which service offers the technology necessary to run the application needed (e.g. the servlet_jsp service for servlet-based applications).
- Then, the dependencies of the service must be determined. It is also necessary to clarify which other services must be enabled in order to execute the service in question. These other services can be found on the "Dependencies" tab of the service attributes. In general, only the highly interdependent services are needed.
- The same procedure must be applied to the dependent services found until no more services can be added to the list of services.
- The services which do not appear in the list can be disabled. It must be noted, though, that certain services are required for the operation of the Java stack.
- Unneeded applications can be stopped or uninstalled. This is accomplished using the "deploy" service.
- The aliases of unneeded applications administrated using the "http" service can be disabled.
- After having disabled a service or application, it is necessary to check whether the services and applications needed are still executable.
- If the application or the Java stack becomes inoperable, the Java stack logs should be analysed. In general, they contain error messages indicating which service was required but has been disabled. Otherwise, the only way to find out which combination of services is needed is by trying out various combinations.
- For system services, the start parameter "always" must be changed in the XML configuration file "runtime.xml" in the corresponding service directory of the operating system or using the GUI-based "Configurations" tool (value: "never" or "manual).
Since the Java stack changes with each new version and there are differences in the number of services and functions offered by different versions, it is not possible to provide a comprehensive list of the services at this point.
References to SAP documentation on services and their function can be found in S 2.346 Use of the SAP documentation.
Removing standard content
All standard content such as documentation (e.g. for the deploy service: sap.com/...docs.examples), sample programs (e.g. for the deploy service: sap.com/...htmlb.ear), or static HTML sites should be uninstalled.
Securing the HTTP service
The HTTP service should be secured, which includes ensuring the following aspects:
- ensuring directories cannot be displayed
- ensuring unneeded aliases are disabled
- prohibiting HTTP PUT operations (uploading data)
SAP documentation on this subject can be found in S 2.346 Use of the SAP documentation.
Installing the cryptographic function library
In order for the Java stack to be able to use strong cryptographic procedures, it is necessary to install a cryptographic function library offering strong procedures. It is also possible to use free implementations from the Java environment for encryption. When using cryptographic function libraries, it is generally necessary to abide by the license conditions of the provider and to check for compatibility with the Java stack.
Even Java stack components such as Secure Storage, which is used to store data securely using system services and applications, require cryptographic procedures. For this reason, adequate security can only be reached after installing a cryptographic function library.
Configuring the authentication module
Several authentication methods can be used for authentication when accessing the Java stack. For example, it is possible to configure the use of certificates or single sign-on tickets for authentication in addition to the user name and password method. In this case, it is possible to specify the order in which the procedures are used and if a certain procedure alone is adequate for authentication purposes.
It is therefore necessary within the framework of the authorisation concept to decide which procedures will be used and how they will be used. If necessary, additional procedures can be integrated using additional libraries from third party manufacturers. The JAAS interface, which is specified in the Java standard, is used for this purpose.
Restricting access to system resources
The authorisation concept must specify which users or user groups are allowed to access the system resources of the Java stack and which operations (e.g. read, write, or list) will be allowed during access. The operations available for configuration depend on the type of resource in this case. It is therefore recommended to perform detailed planning based on a specific Java stack - for example after installation. Additional information can be found in S 4.268 Secure configuration of rights for the SAP Java Stack.
Restricting access to the administration interface
The Java stack can be administrated using several interfaces:
- Visual Administrator
The Visual Administrator communicates with the Java stack using the P4 interface. Access to the P4 interface (port 50004 for instance 00 by default) therefore needs to be protected against unauthorised accesses using a firewall. Since the P4 protocol can also be tunnelled through HTTP (port 50001 for instance 00 by default), the HTTP port also must be protected. - Telnet service of the Java stack (port 50008 for instance 00 by default)
If this command-line based access capability is not used, the Telnet service should be disabled. If Telnet is used, only authorised administrators may be allowed to access to the service. The Telnet resource (security service, resources, root/system/telnet) therefore needs to be configured in such a way that only the administrators belonging to the group of authorised administrators are entered as "GrantedUsers". - File system in which the configuration files are stored
The directories and files of the Java stack installation must be set up with restrictive access restrictions. (Note: Different file system layouts are used depending on the version of the Java stack. The trend is moving towards storing the Java stack configurations in the database only).
Access to the administration tools (Visual Administrator, Configtool) is to be restricted to authorised administrators only. It must be taken into account, though, that that these tools operate using the network, which means attackers could install their own versions of these programs. It is therefore recommended to configure the restrictions at the network level so that only certain computers can access the administrative ports (see above). This does not completely rule out the possibility of an attack, but makes it more difficult to initiate an attack on the system.
Ensuring password quality
Strong passwords should be configured for the users of the Java stack. The functionality offered for ensuring password quality differs between individual versions of the Java stack.
As a minimum requirement, the minimum password length should be set to the value specified by the password policy. The password length should be set to at least 8 characters (configured for all users using "Set Filter").
A maximum age for passwords should also be set that corresponds to the specifications of the password policy. The maximum age is configured in the user properties. A value of 90 days is recommended.
Securely configuring the Java stack single sign-on
In order to access the Java stack using a single sign-on, the certificates of the systems required to accept single sign-on tickets must be imported. In this case, it must be ensured that single sign-on tickets are only accepted by trustworthy systems (see also S 4.258 Secure configuration of the SAP ABAP Stack).
Review questions:
- Are the SAP administrators who administrate the Java stack trained regarding the architecture and the security concepts of the J2EE architecture?
- Are all unneeded services of the Java stack disabled in the SAP system?
- Is the HTTP service secured appropriately in the SAP system?
- Has a cryptographic function library been installed for the SAP Java stack, which offers strong procedures?
- Does the authorisation concept specify which users or user groups are allowed to access the system resources of the Java stack and which operations (e.g. read, write, or list) will be allowed during access?
- Has access to the Java stack administration tools (Visual Administrator, Configtool) been restricted to authorised SAP administrators?
- Has the SAP network been configured in such a way that only certain computers are allowed to access administrative ports?
- Does the configuration of the SAP system provide sufficient password quality for Java stack users?