SAP Java Security

PRINT FROM SAP HELP PORTAL
Document: SAP NetWeaver Application Server Java Security Guide File name: saphelp_nw73_en_57_d8bfcf38f66f48b95ce1f52b3f5184_frameset.pdf URL: http://help.sap.com/saphelp_nw73/helpdata/en/57/d8bfcf38f66f48b95ce1f52b3f5184/frameset.htm Date created: March 11, 2013
2012 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System ads, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C , World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
PUBLIC 2012 SAP AG. All rights reserved.
Page 1 of 25
SAP NetWeaver Application Server Java Security Guide

Purpose
This guide is intended to provide you with an overview of the security aspects and recommendations that apply for the SAP NetWeaver Application Server (SAP NetWeaver AS) for Java Server technology.
Target Audience
Technology consultants System administrators This guide is not included as part of the Installation Guides, Configuration Guides, Technical Operation Manuals, or Upgrade Guides. Such guides are only relevant for a certain phase of the software life cycle, whereby the Security Guides provide information that is relevant for all life cycle phases.
Why Is Security Necessary?

With the increasing use of distributed systems and the Internet for business transactions and business data management, the demands on security are also on the rise. When using a distributed system, you need to be sure that your data and processes support your business needs without allowing unauthorized access to critical information. User errors, negligence, or attempted manipulation on your system should not result in loss of information or processing time. These demands on security apply likewise to the usage type AS Java of the SAP NetWeaver platform. To assist you in securing the AS Java, we provide this Security Guide
Integration
There is also an SAP NetWeaver Application Server ABAP Security Guide.
About this Document

This security guide provides an overview of the security-relevant information that applies to the AS Java. It contains an overview of the security considerations for the AS Java and links to the security administration or development functions in the AS Java Administration and Development Manuals, respectively. The Security Guide contains the following sections: Before You Start Provides links to additional information, a list of important SAP Notes and other security guides that apply to securing the AS Java. Technical System Landscape Provides a brief overview of the technical system landscape of the Java systems. User Administration and Authentication Describes user management, standard user types and synchronization of user data, as well as, AS Java authentication mechanisms and their integration in Single Sign-On (SSO) environments. Authorizations Provides an overview of the authorization concepts on the AS Java. The topics discussed include authorization checking on the AS Java, standard User Management Engine (UME) actions and security roles. Network Security Provides an overview of the communication channels used by the AS Java and the corresponding transport layer security mechanisms. We also provide an example of a secure network infrastructure using network zones and information on the standard communication ports used by the AS Java. Data Storage Security Describes the aspects in maintaining the availability, confidentiality and integrity of security sensitive data stored and used by the AS Java. Dispensable Functions with Impacts on Security Provides information about deactivating optional AS Java services that you may not need in productive operations. Other Security Relevant Information Presents an overview of additional topics relevant to securing the AS Java, such as Java Virtual Machine (JVM) security, security of the JMS service, Database connection security and security for the software deployment. Security Tracing and Logging Provides a discussion of the security aspects in using the logging and tracing functions available on the AS Java.
Before You Start

Related Security Guides
SAP provides a security guides for connectivity and interoperability. For more Information, see the Security Guides for Connectivity and Interoperability Technologies. For a complete list of the available SAP Security Guides, see the Quick Link /securityguide on the SAP Service Marketplace at service.sap.com.
Important SAP Notes

The most important SAP Notes that apply to the security of the AS Java are shown in the table below.
Page 2 of 25
Important SAP Notes SAP Note Number 720590 812332 710146 753002 Title User Management Engine (UME) on WAS 6.30 and higher. How to set up logging on a remote J2EE client How to change JVM Settings Web Services SSL Proxy Authentication
Additional Information
For more information about specific topics, see the Quick Links from SAP Service Marketplace. Quick Links to Additional Information Content Security Security Guides Network security Released platforms SAP Solution Manager Quick Link on the SAP Service Marketplace /security /securityguide /network /platforms /solutionmanager
Technical System Landscape

For an overview of the relevant system components and communication paths in the technical system landscape of the AS-Java, see the figure below.
AS Java Technical System Landscape The complex communication patterns and links reflect the versatile functions that the AS Java can perform in your system landscape. To meet such versatility requirements, the AS Java has an open and standards-based architecture that enables communication with a number of partners in your system landscape, for example Web and Enterprise application clients, databases, AS ABAP and other systems. The versatility of the AS Java and the number of communication partners, however, increase the system security risks, especially when used in open environments such as the Internet. Therefore, AS Java enables you to protect your productive systems by using firewalls to deploy the AS Java system instances in separate security zones in your system landscape. In addition, you can use application gateways, such as proxy servers, to filter and authenticate communication requests for the AS Java and related application components. For administration and configuration information for specific set ups, see You can also find more information from the resources listed below. Topic Technical description for the SAP NetWeaver AS Java High Availability Security Guide/Tool Master Guide Quick Link to the SAP Service Marketplace service.sap.com/instguides service.sap.com/ha service.sap.com/security AS Java Configuration in the Administration Manual.
Page 3 of 25
User Administration and Authentication

For an overview of the user authentication and administration mechanisms for the AS Java, see the following topics. User Administration and Standard Users Provides an overview of the required user types, the standard users that are delivered with the AS Java, and the tools to use for user management. User Data Synchronization The AS Java can use external data sources to store persistent user data. This topic describes how user data is synchronized with these other sources. Authentication Mechanisms and Single Sign-On Integration Describes the user authentication process on the AS Java, the available authentication mechanisms and their integration in Single Sign-On environments.
See also: User Management of the Application Server Java
User Administration and Standard Users

User Management Tools
SAP NetWeaver Application Server (AS) Java enables you to manage user data in a number of ways. For more information about the user management tools and a comparison their functions, see User Administration Tools.
Security Policy Profiles

All users are assigned to security policy profiles that define what the logon ID and password can look like as well as password expiration, and in some cases, whether the user can log on in a dialog session. You can configure and assign custom security policy profiles. How the user management engine (UME) applies these profiles depends on the data source. This is especially true when the security policy profile conflicts with the security policies of an external data source. For more information and standard user types, see Default Security Policy Profiles.
Standard Users and Groups

The AS Java has an open service provider architecture for storing user data, whereby you can use multiple user stores. Most applications on the AS Java require the use of the UME, though the use of DBMS user store and UDDI user stores are possible. In turn, the UME can use different data sources, including AS-ABAP. The standard users and groups differ for each of the available data sources. For more information, see Standard Users and Standard User Groups.
User Administration Tools

The user administration tools for the AS Java allow both offline and runtime user administration. User Administration Tools Tool Identity Management Detailed Description Web-based tool integrated into SAP NetWeaver Administrator that provides functions for configuration of the user management engine (UME) and user administration. You can use the functions supplied with this tool from a Web browser. A command line tool that enables remote administration from Telnet clients. The default AS Java configuration enables only administrator users to use telnet. Further Information Administration Manual: User Management of the Application Server Java Administration Manual: Remote Administration Using Telnet Administration Manual: Config Tool
Shell Console Administrator Config Tool
An XML-based tool that enables offline configuration of AS Java cluster elements. Changes made using this tool must be exported to the engine database and may require you to restart the AS Java. This tool does not support remote administration of AS Java.
Remote User Administration During Runtime
Page 4 of 25
User management during server runtime enables efficient and scalable user management for your productive systems. Furthermore, remote user administration facilitates security management of individual AS Java systems, for example, when running in a cluster. Therefore, the AS Java provides the following administration tools that allow remote user management during server runtime: Identity Management Shell Console Administrator For an overview and comparison of these tools, see the table below: Function Create, view, or delete users Search for users Import users from external systems Lock or unlock users List locked users Change user passwords Define password rules Require password change Create, delete and manage groups and group members Assign a public-key certificate to a user Assign roles to users Assign UME actions to roles Configure user stores Shell Console Administrator Yes No No No No Yes No No Yes Yes No No Yes Identity Management Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
User Data Synchronization

The AS Java has an open service provider architecture for storing user data. In the standard system, SAP uses the user data management functions of the user management engine (UME) store provider. The UME is the default active user store interface on the AS Java. The UME itself has a number of options for storing user data. More information: UME Data Sources.
Overview of User Stores You can configure the use of several user stores in parallel and specify which user store is active in a server configuration. At runtime, the active user store is transparent to the user, and the user is not aware of the user store provider that is actually used for user authentication and authorization.
User Data Management in UME

Consistent with the open architecture of user management in the AS Java, UME also allows you to import and export user data from and to LDAP, database or AS ABAP data sources. For an overview of the architecture and the process flow of user data replication in the UME, see the figure below.
Page 5 of 25
You can use the transport layer security mechanisms available for the corresponding communication protocols to secure the remote communication for UME data sources. More information: Communication Security for Persistency Stores. For identity provisioning, UME provides a remote interface using the Service Provisioning Markup Language (SPML) standard. Using the SPML APIs of the UME, you can perform identity management functions on users, group and role objects. The APIs can be used for user management with all of the data sources (SAP system, LDAP server or other database), supported by the UME. The AS Java can accept SPML requests to perform the following identity management functions. The available functions can also be bundled together in batch requests: Creating objects Modifying objects Searching for objects Deleting objects The AS Java accepts and processes the SPML request using Simple Object Access Protocol (SOAP) messages (according to the SPML 1.0 Bindings specification). The URL address used by the SPML service on the AS Java is <server>:<port>/spml/spmlservice.
More Information: Administration of Users and Roles Configuring User Management Reference Documentation for User Management
Authentication Mechanisms and Single Sign-On Integration

The AS Java implements the Java Authentication and Authorization Service (JAAS) standard to support various authentication methods. This enables you to choose the authentication mechanisms in your applications based on your authentication needs or requirements. Applications running on the AS Java can use either declarative or programmatic authentication. Both types of authentication rely on the same underlying technology, login modules and login module stacks. Programmatic authentication also extends declarative authentication by using authentication schemes, which allow you to prioritize login module stacks and specify user interfaces for collecting authentication information. SAP ships login modules and authentication schemes to support various authentication mechanisms. The following sections describe the underlying concepts: Declarative and Programmatic Authentication Explains the difference between declarative (container-based) authentication and programmatic (UME) authentication. The type of authentication that an application uses has consequences for the login module stack it uses and on where you configure authentication. Login Modules and Authentication Stacks Provides conceptual information about login modules and login module stacks. Login modules define the authentication logic, whereas authentication stacks enable you to define the sequence of login modules checked for authorizing access to an application. Authentication Schemes Provides conceptual information on authentication schemes. Integration in Single Sign-On Environments Provides an overview of the integration of the AS Java authentication mechanisms in Single Sign-On environments.
See also: User Authentication and Single Sign-On: AS Java Authentication Infrastructure
Page 6 of 25
Declarative and Programmatic Authentication

The AS Java enables applications to use two options for authenticating users: Declarative authentication (also known as container-based authentication): The application container of the AS Java handles authentication. A component running on the AS Java declares protected resources and the desired authentication mechanism in its deployment descriptor. When a protected resource of this component is accessed, the container in which the component runs performs authentication. Programmatic authentication (also known as UME authentication): Components running on the AS Java authenticate directly against the User Management Engine (UME) using the UME API. The component explicitly triggers authentication and afterwards the authentication process is controlled by the authentication framework. Both declarative and programmatic authentication use login modules and authentication stacks as their underlying technology. You can configure the authentication policy for both types of applications using declarative or UME programmatic authentication with their deployment descriptors web.xml and web-j2ee-engine.xml. For more information, see Protecting Java Web Applications.
After deployment, you can change this assignment in SAPNetWeaver Administrator. For more information, see Editing the Authentication Policy of AS Java Components. Portal applications and iViews have their own implementation of programmatic authentication that includes authentication schemes. The authentication scheme in turn references a login module stack. For more information, see Login Modules and Login Module Stacks and authentication schemes in the portal documentation.
Integration
The different types of applications can use different means for defining the login module stack to use in its policy configuration. For more information, see the table below: Application Type Web applications Web applications Web Dynpro applications Portal iViews Type of Authentication Declarative authentication Programmatic authentication Programmatic authentication Programmatic authentication Where is Login Module Stack defined Declared in the web.xml deployment descriptor of the Web application. For more information, see Protecting Java Web Applications. This depends on how the application is programmed. Applications can define an authentication scheme in their calls to the API. By default, if they do not define an authentication scheme, these applications use the login module stack referenced by default in the authentication schemes file. For more information, see Security Aspects of Web Dynpro for Java.
An iView property defines which authentication scheme the iView uses. The authentication scheme references a login module stack. For more information, see Assigning an Authentication Scheme to an iView.
Declarative and programmatic authentication are integrated so that if an application uses programmatic authentication to authenticate its users, the container where it runs on the AS Java is also aware that the users are authenticated. Inversely, if an application uses declarative authentication to authenticate its users, UME is also aware that the users are authenticated. Calls to the APIs of both the container and UME return the authenticated user.
If you change the default authentication scheme, this also affects any portal iViews and Web applications that use the default authentication scheme.
Login Modules and Login Module Stacks

Login Module
Authentication on the AS Java is performed using predefined authentication classes, compliant with the Java Authentication and Authorization Service (JAAS) specification and referred to as login modules. A login module contains an implementation Java class that defines the authentication logic. The AS Java is delivered with a set of standard login modules that you can extend with custom login module development. For more information, see Login Modules and Managing Login Modules.
Authentication Stacks and Policy Configurations

The AS Java enables you to define different authentication logic by using groups of login modules in authentication stacks. Each login module stack, or authentication stack, enables you to choose different combinations of authentication for each of the AS Java components or the applications you create and deploy to the AS Java.
Page 7 of 25
The use of authentication stacks is specified in the policy configurations for the AS Java applications. The various components on the AS Java, for example, Java applications, services, or modules, are registered with the Security Provider service so that you can apply security restrictions to them. The set of security restrictions for a component, which includes authentication and authorization rules, is referred to as a policy configuration. For more information, see Policy Configurations and Authentication Stacks.
Authentication Templates
The AS Java enables you to use a set of standard authentication stacks as templates for enforcing authentication checks for standard authentication mechanisms, for example for SSO with logon tickets. You can extend the standard authentication templates by registering new authentication stacks. Thereby, you can simply configure one login module stack and apply it to another registered component. For more information, see Managing Authentication Policy for AS Java Components.
Authentication Schemes
Authentication schemes are used for UME programmatic authentication only. Authentication schemes are defined in the authschemes.xml file, which you can change using the AS Java Config Tool. For more information, see Changing the authschemes.xml File in the portal documetation.
Use
An authentication scheme is a definition of what is required for an authentication process. This includes: The login module stack that is used to determine whether a user is granted access to an application The user interfaces that are used to gather the information required to authenticate a user Priority, allowing authentication schemas to be ordered You use authentication schemes to define what type of authentication is required for a certain application. Portal iViews and Web Dynpro applications always use authentication schemes. Web applications may use them when they use UME programmatic authentication. By assigning an authentication scheme to an application, you specify the type of authentication required for that application. You can also use authentication schemes enable pluggable authentication for applications using UME authentication. You can easily plug in additional authentication schemes without having to change each individual application.
Integration
All Web Dynpro applications are automatically assigned to a default authentication scheme, which in turn references the ticket login module stack. In the portal, each shipped iView template is assigned a reference to an authentication scheme. Initially all authentication scheme references point to the same authentication scheme. If you have special authentication requirements, you can define custom authentication schemes and then change the configuration of the portal so that the references point to your custom authentication schemes. This allows you to change the authentication schemes without having to modify the iViews or iView templates.
If you change the authentication scheme referenced by default, you automatically change the authentication scheme used by all Web Dynpro applications as well. For more information, see the portal documentation.
Standard Authentication Schemes

The AS Java is shipped with a set of authentication schemes. These are defined in the authschemes.xml file. The following authentication schemes are shipped with SAP NetWeaver Application Server Java: Name of Authentication Scheme uidpwdlogon certlogon basicauthentication header anonymous Description Requires form-based logon with user ID and password. Requires authentication using client certificates. Uses the Basic Authentication feature of the HTTP protocol. Allows authentication using external Web access management products. Provides a very basic form of anonymous logon. A logon ticket is not issued. Login Module Stack ticket client ticket header Referenced by default, UserAdminScheme
Page 8 of 25
Integration in Single Sign-On Environments

The AS Java is shipped with a range of login modules that support the most common authentication mechanisms. The majority of the supported authentication mechanisms enable efficient integration into Single Sign-On (SSO) environments. For an overview of the authentication mechanisms shipped with AS Java, see the table below: Authentication Mechanism Basic Authentication Logon Tickets Description Basic Authentication is an HTTP standard method for authentication, whereby the user provides a user ID and password for authentication. By default, the AS Java uses Basic Authentication for applications that are set up to use Basic or Form authentication. For more information, see Logon Using User ID and Password on the AS Java. The AS Java supports the use of logon tickets for SSO when using a Web browser as the front-end client. In this case, users can be issued a logon ticket after they have authenticated themselves against a ticket issuing system, with any of the supported mechanisms. The ticket can then be submitted to other SAP or non-SAP ticket accepting systems as an authentication token. The user does not need to enter a user ID or password for authentication but can access the system directly after the system has checked the logon ticket. For more information, see Client certificates Using Logon Tickets with AS Java. As an alternative to Basic Authentication using a user ID and passwords, users using a Web browser as a front-end client can also provide X.509 client certificates to use for authentication. In this case, no passwords have to be transferred and the communication of user credentials is secured using the Secure Sockets Layer (SSL) Protocol. Authentication takes places without direct user intervention, which allows integration in a SSO environment. For more information, see SAML Assertions Using X.509 Client Certificates on the AS Java. You can use SAML for SSO in a scenario where a user is authenticated on an external authentication system that acts as an SAML authority. Based on this authentication, the user receives an SAML assertion (upon request) that he or she can use to access the AS Java. To protect the data exchange, SSL is required for the connection between the source and destination sites. SSL is required by the SAML specification, and by default its use is activated in the SAML configuration. However, for testing purposes, you can disable the enforcement of SSL for the SAML-based document exchanges. The SAML Single Sign-On scenario involves a source site, assertion artifact and a destination site. The site that authenticates the user establishes a source site server that initiates the SAML communication. This source site provides the destination site with an assertion artifact, which is an identifier for the users assertions. The source site also provides a responder, which acts as the SAML authority that actually provides the users assertions. The destination site provides the desired resource and an artifact receiver, which receives the initial assertion artifact and passes it on to be evaluated by the SAML login module. If the users ID as provided by the SAML authority is not identical to the user ID at the destination site, then the destination site must also provide a user mapping mechanism. For more information, see Provider. Kerberos Authentication with SPNego ../../KW/IWB_EXTHLP~440DA0DF25C1648FE10000000A1553F7/ Configuring AS Java as a Service
You can use the Simple and Protected GSS API Negotiation Mechanism (SPNego) to enable Kerberos authentication on the AS Java. Kerberos is an integral part of the Windows 2000 and higher operating systems, however, you can integrate non-Windows server components into the Windows Integrated Authentication infrastructure. The SPNegoLoginModule of the AS Java enables you to use Kerberos independently of the underlying operating system (OS) of the AS Java host and without an intermediary Web server. For more information, see Using Kerberos Authentication. The AS Java provides an additional authentication mechanism type supported by the connector container: SAP Assertion Ticket of type com.sap.security.core.server.jaas.SAPAuthenticationAssertionTicketCredential. The SAP Assertion Ticket is fully compatible with the SAP Logon Ticket. With this authentication mechanism, you can specify additional authentication types in the deployment descriptor of the resource adapter according the J2EE Connector Architecture. For more information, see Single Sign-On for Resource Adapters and JCA. You can use header variable authentication to delegate user authentication to any external product, which authenticates the user and returns an authenticated user ID as part of the HTTP header. Users only have to authenticate once against the external product and can then access applications on the AS Java, such as the portal, with SSO. When using an external product with the header variable login module for authentication, all requests must pass through the external product. In addition, the user ID that the external product returns in the HTTP header must exist in the user management data sources. For more information, see Header Variables.
Single Sign-On for resource adapters
Header variables for user authentication
If appropriate security measures are not taken, authentication using header variables can allow attackers to impersonate a user by sending a request with a user ID in the appropriate header variable to the AS Java. To prevent this, you should make sure that the AS Java can be accessed only from the authenticating Web server. If it is not possible to block the HTTP and HTTPS ports of the AS Java, you must configure SSL with mutual authentication between the authenticating Web server and the AS Java.
See also: User Authentication and Single Sign-On: AS Java Authentication Infrastructure ../../KW/IWB_EXTHLP~444F16B56FED0597E10000000A155369/
Authorizations
PUBLIC 2012 SAP AG. All rights reserved. Page 9 of 25
Applications and components deployed on SAP NetWeaver Application Server (AS) Java can use the following approaches to authorization checking: Assign activities to individual users based on roles Control the use of objects using Access Control Lists (ACLs).
Role-based Authorization
Applications deploy authorizations in Java EE security roles or user management engine (UME) actions depending on the decision of the developer. The JEE security roles and UME actions can be bundled by the developer or the administrator into UME roles. The administrator then assigns these roles to the users.
ACL-based Authorizations
ACLs limit access to individual objects. The AS Java does not provide a user interface to manage ACLs, but it does provide APIs for reading, writing, and authorization checks of ACLs.
More information
Authorization Concept of the AS Java Standard UME Roles Standard UME Actions Standard Java EE Security Roles
Network Security
Your network infrastructure is an important element in protecting your SAP NetWeaver systems. The network topology for the AS Java is based on the topology used by the SAP NetWeaver platform. SAP systems are implemented as client-server frameworks built in three levels: database server level, application server level and the presentation level (front ends). The AS Java works at the database and application levels in your implementation framework, where it defines and forwards the presentation logic to Web client applications, such as, for example Web browsers and Web Dynpro applications. Therefore, when deploying the AS Java in your network landscape, we recommend that you use a network topology with multiple network security zones as shown in the figure below.
Network Topology with Multiple Security Zones See the following sections for more details on the transport layer and communication channel security aspects that specifically apply to the AS Java: Transport Layer Security Communication Channel Security AS Java Ports
For a complete list of the default ports used by SAP NetWeaver products and their default assignments, see the document TCP/IP Ports Used by SAP Server Software, which is available on the SAP Service Marketplace at http://service.sap.com/security.
Page 10 of 25
Transport Layer Security

For an overview of the communication protocols and the corresponding security mechanisms for the AS Java, see the figure below.
AS Java Communication Paths and Protocols. Depending on the underlying communication protocol of the AS Java, you can use either the Internet standard Secure Socket Layer (SSL) or Secure Network Communications (SNC). The transport layer security functions on the AS Java use the security provider libraries and the AS Java security environment. You specify the security provider and the secure store security options during the AS Java installation. For more information, see Transport Layer Security on the AS Java in the Administration Manual.
SSL on the AS Java is not configured by default. For more information about enabling the use of SSL, see For information specific to each of the communication protocols used by the AS Java, see the table below. Protocol HTTP Security Mechanism Secure Socket Layer (SSL) Comment
Configuring the Use of SSL on the AS Java.
P4 is the transfer protocol for Java specific Remote Method Invocation (RMI) communication. This protocol is used for remote deployment, as transport layer for JMS (Java Message Service) protocol, and remote method invocations of custom remote objects bind in naming.. For more information, see Configuring the Use of SSL on the AS Java in the Administration Manual. P4 is the transfer protocol for Java specific Remote Method Invocation (RMI) communication. This protocol is also used for communication between the SDM server and the AS Java. P4 supports HTTP tunneling and can also be used with proxies. For more information, see Using P4 Protocol Over a Secure Connection in the Administration Manual. IIOP is an alternative transfer protocol to use for RMI communication requests. You can also use IIOP for communication with CORBA application servers. Transport Layer Security for the IIOP protocol is provided by SSL. For more information, see Configuring the AS Java for IIOP Security in the Administration Manual. You can use an LDAP directory server as the persistence layer for the UME user store. You can use SSL for the Transport Layer Security in this case. SNC is an SAP proprietary layer used with the SAP communication protocols RFC and DIAG. For more information, see Secure Network Communication (SNC) in the SAP NetWeaver Security Guide JDBC is a communication protocol for connecting to databases. Transport Layer Security for database connectivity is provided by the driver used to connect to the database. Telnet is used for remote administration using Shell Admin tool. We recommend establishing a virtual private network to secure the connection. For more information, see Remote Administration Using Telnet in the Administration Manual Session is a type of communication protocol that is used only between the Internet Communication Manager (ICM) and the server processes in the AS Java cluster. These elements exist in the same security context of an AS Java instance and, therefore, no transport security is necessary.
P4
Secure Socket Layer (SSL) Secure Socket Layer (SSL) Secure Socket Layer (SSL) Secure Network Communications (SNC) driverdependent Virtual Private Network (VPN) N/A
IIOP
LDAP RFC
JDBC Telnet
Session
See also: Administration Manual: Configuring the Use of SSL on the AS Java Using SSL to the AS Java via the ICM Using SSL With an Intermediary Server Configuring SNC: AS Java -> AS ABAP
Page 11 of 25
Communication Channel Security

Communication Flow
The AS Java is an application middleware component in your system landscape and communicates with a number of communication partners. Deployed applications and the components of the AS Java can negotiate communication using several protocols, depending on the AS Java container where they reside. The primary communication protocols include HTTP, Telnet, P4 and IIOP, as well as, LDAP, JDBC and RFC for SAP specific communications. P4 and IIOP are the protocols that are used for Java specific Remote Method Invocations communication. In addition, the AS Java supports SOAP for Web Services communication.
The AS Java containers represent an abstract logical grouping of runtime services and life cycle management functions for application components. The AS Java containers include the Web Container, EJB Container, Web Services Container and Persistence Container. The security aspects vary according to the container that processes the application.
Communication Security
In the following topics we describe in more detail the relevant security considerations for each of the communication channels for the AS Java: Using and Intermediary Server to Connect to the AS Java Gives an overview of the security aspects associated with using intermediary devices such as the SAP Web Dispatcher, Microsoft IIS and other servers, for example, the Apache reverse proxy. Communication Security for the Web Container Presents an overview of the security aspects of the communication between the AS Java and Web clients, for example Web browsers and Web Dynpro applications. Communication Security for the EJB Container Discusses the security aspects of the communication between application servers acting as clients or servers and the AS Java. Communication Security for Web Services Provides an overview of the security aspects of the communication channels relevant to Web Services. Communication Security for Persistence Layer Provides an overview of the security aspects of connecting the AS Java to backend systems and user persistency stores. Communication Security for the Software Deployment Provides an overview of the communication channel security when deploying applications on the AS Java using the Software Deployment. See also: Data integrity Transport Layer Security on the AS Java in the Administration Manual Security Guide for Connectivity with the AS Java in the SAP NetWeaver Security Guide
Communication Security
Using an Intermediary Server to Connect to the AS Java

When establishing your cluster network infrastructure, you can establish a demilitarized zone (DMZ) separated by using firewalls to control access to your more critical systems in the backend. Use an intermediary server in the DMZ to perform the necessary routing and load balancing tasks. See the figure below: Using an Intermediary Server
Page 12 of 25
SAP provides the SAP Web dispatcher that you can use as the intermediary server. The SAP Web dispatcher is a load-balancing device provided free-of-charge to SAP customers that operates using the SAP application server load-balancing mechanisms. It supports the use of SSL for securing connections and does have URL filtering capabilities. It can be used with both AS ABAP and AS Java installations. You can also use different devices as the intermediary server, for example, an Apache Web server as a reverse proxy. Such devices often provide additional features such as more refined load-balancing, or request and content filtering. The features provided depend on the product you are using. See also: Using SSL With an Intermediary Server in the Administration Guide.
Communication Security for the Web Container

For this communication channel, communication is initiated by a Web application client, such as a Web browser. The access request coming from the Web application client is passed through the Internet Communication Manager (ICM) for load balancing and is then forwarded to the Web applications (WARs) running in the Web container of the AS Java. The Web applications then access business objects using Enterprise Java Beans (EJBs) from the EJB Container. The EJBs in turn access the actual data in the persistence layer. For an overview of the communication flow, see the figure below.
Communication Flow for Web Container The table below presents an overview of the security-relevant information for each of the communication paths. Communication Path Front-end client using Web application client to application server Web application to Enterprise Java Bean Protocol Used HTTP Type of Data Transferred Authentication information All application data P4 IIOP JDBC LDAP RFC All application data Data about propagation of security credentials All application data Authentication data when accessing persistence layers or remote servers Driver dependent encryption for JDBC SSL for LDAP SNC for RFC Secure Socket Layer (SSL) Available Security Protection Secure Socket Layer (SSL)
EJB to persistence layer
See also: Using Login Modules to Protect Web Applications
Page 13 of 25
Communication Security for the EJB Container

For this communication channel, communication occurs between RMI-P4, RMI-IIOP, or CORBA application servers acting as clients calling server-side remote objects such as Enterprise Java Beans (EJBs) or remote objects implementing RMI-P4 or RMI-IIOP.
Application Server to Application Server Communication Flow By contrast to accessing the AS Java using Web applications, in this case, security management is carried out by the corresponding client or server side EJB container. The table below presents an overview of the security relevant information for each of the communication paths. Communication Path Client side RMI-P4 object accessing server-side EJB or remote object Client side RMI-IIOP object accessing server-side EJB or remote object Client side CORBA object accessing server-side EJB or remote object EJB to persistence layer Protocols Used P4 IIOP IIOP JDBC LDAP RFC Type of Data Transferred Authentication information All application data Authentication information All application data Authentication information All application data All application data Authentication data when accessing persistence layers or remote servers Available Security Protection Secure Socket Layer (SSL) Secure Socket Layer (SSL) Secure Socket Layer (SSL) Driver-dependent encryption for JDBC SSL for LDAP SNC for RFC
Communication Security for Web Services

A Web Service (WS) is a self-contained, modularized function, that can be published, discovered, and accessed across a network using open standards. It represents an executable entity. For the caller or sender of a WS, a service is a black box that may require input and delivers a result. WS cover the provision of business integration functions within and across enterprises on top of any communication technology stack, whether synchronous or asynchronous. The AS Java uses the WS Framework for Java as a pluggable infrastructure for declaring and using Web Services. A Web Service can be any component, for example EJBs, Java Classes (in Servlet Container), Portal Services. The Framework takes care to deserialize incoming XML SOAPData and invoke an implementation. In addition, based on a Web Services Definition Language (WSDL) Description a WS Proxy can be generated that exposes a Java Interface to the clients, and generates XML SOAP Messages. For an overview of the communication flow, see the figure below.
Web Services Communication Flow
Page 14 of 25
To use a WS, a WS Consumer initiates a transaction with a WS provider using the Simple Object Access Protocol (SOAP). The SOAP transaction request is then transported over the network using the HTTP protocol. The transmission of the document can either be secured by using HTTP over SSL, or by signing and/or encrypting the SOAP document using OASIS WS Security.
Web services messages may travel over any number of connections and potentially traverse many intermediaries. In order to support this decoupled interaction, connection-oriented security, such as SSL, alone is insufficient or inappropriate. Therefore, the AS Java enables you to use Document security mechanisms, such as OASIS WS Security XML signatures and XML encryption, on a per message basis. In addition, to prevent unpredictable behavior of Web services due to poorly formed messages, with the AS Java you can use a WS proxy. You can use the AS Java to act both as a provider and as a consumer for Web Services. The SAP NetWeaver Development Studio provides a design time development environment for publishing, discovering, and accessing Web services on the AS Java. Security related features such as communication type or authentication level can be assigned in the WS definition in an abstract form. The technical details of these features are then specified in the WS configuration. WS definitions and deployed Web Services are published in a UDDI registry. WSDL documents provide the basis for the WS consumer and can be found in the Service Registry using a Web browser or the standard UDDI APIs. The WS Consumer side derives the WS proxy generation based on the Web Service Definition, retrieved from the UDDI. Technical details that are predefined in the WS configuration are configured separately in the client runtime for the WS Container of the AS Java. For more information, see Registry in the Administration Manual. For an overview of the communication paths and the relevant security protection, see the table below. Communication Path WS Consumption Protocol Used SOAP over HTTP Type of Data Transferred WS application data in XML format. Authentication information Security Protection Secure Socket Layer. Document Security XML signature XML encryption Client Authentication Client exclude lists using a HTTP proxy server Publish/Find WDSL HTTP WSDL application data Authentication information. Secure Socket Layer UDDI server Basic or Certificate Authentication Client exclude lists using a HTTP proxy server Configuring the Services
Communication Security for Persistency Stores

As middle-tier software, the AS Java communicates with a number of external data sources. The external data sources include AS ABAP systems, databases, and LDAP-compliant directory servers. For an overview of the communication flow, see the figure below.
Communication Flow for Persistency Stores The table below presents an overview of the security-relevant information for each of the communication paths.
Page 15 of 25
Communication Path AS Java to LDAP directory server
Protocols Used LDAP
Type of Data Transferred Authentication data Application data for directory management Directory entries
Available Security Protection Secure Socket Layer (SSL)
AS Java to RDBMS user store
JDBC 1.x JDBC 2.x
Authentication data Application data User management data
Driver-provided encryption
AS Java to AS ABAP
RFC
Authentication data Application data
Secure Network Communications (SNC)
See also: Security Aspects of the Database Connection in the Administration Manual
Communication Security for Software Deployment

Deployment is the final stage of application development and it involves the transfer of application data to the target system. The AS Java uses a server side Deploy Controller to manage software deployment. The Deploy Controller enables client applications to use APIs to enable deployment of software components on the AS Java server process. The client applications that use the Deploy Controller APIs use the P4 communication protocol for the connection to the AS Java. The standard tools below use the Deploy Controller APIs and enable you to deploy software components on the AS Java SAP NetWeaver Developer Studio (NWDS) During software deployment, the SAP NetWeaver Developer Studio connects to the Deploy Controller on the AS Java server using the Deploy Controller API. The connection between the NWDS and the target AS Java uses the P4 communication protocol. Shell Administration For telnet deployment, you open a Telnet session to the AS Java and then use the Deploy Controller functions for software deployment. To secure the communication, we recommend that you can use a VPN. For more information about using these tools in your deployment scenario, see overview of the communication flow, see the figure below. Deployment: Putting It All Together in the Development Manual. For an
Communication Flow for Software Deployment For an overview of the remote communication paths, the protocols used, the data transferred see the table below. Communication path Deploy Controller Client to AS Java Protocols Used P4 Type of Data Trasferred Authentication data for AS Java connection Application data for deployment Shell Administration Telnet Authentication data for the connection Application data for deployment VPN Available Security Protection VPN
See also: Security of the SAP Java Development Infrastructure
AS Java Ports
The default AS Java ports enable you to establish communication to an AS Java instance as part of the SAP NetWeaver cluster. The ports are generated at installation time and when new cluster elements have to be created.
AS Java Ports
For AS Java, 20 ports are available for the ICMelement and 80 are available for the server elements, since five is the maximum number of ports for a server process. Therefore, no more than 16 server cluster elements can be created on one instance. The default AS Java ports meet the following requirements: The port value is a number over 50000 For each cluster element the ports begin with 50000+100*instance_number, where instance_number is a two digit number from 00 to 99 specifying the number of central instance and dialog instances.
You can see the instance number from the directory, where the AS Java is installed. Under /usr/sap/<SID>, there is a directory which name contains the instance name including the instance number, for example, JC40 (where 40 is the instance number). Dispatcher port_index Values Index 0 1 2 3 4 5 6 7 Port Name HTTP port HTTP SSL port IIOP Initial Context port IIOP SSL port P4 and JMS port P4 SSL port IIOP port Telnet port
For server cluster elements the ports are created from 50000+100*instance_number+20+n*5+port_index, where n is the number of server elements from 0 to 15 and port_index is from 0 to 4.
You can see the number of the server element from the installation directory of the AS Java. Under <Drive>:\usr\sap\<SAPSID>\<Instance_Name>\j2ee\cluster, there are server<Server_Number> directories representing the server processes in the AS Java. Their number depends on the number specified at installation time.
The ports for AS Java server3 with instance_number=15 are from 51535 (50000+100*15+20+3*5+0) to 51539 (50000+100*15+20+3*5+4). Server port_index Values Index 0 1 Port Name Join port Debug port
According to the formula mentioned above and the port_index values, the server ports for the AS Java are as follows: AS Java Server Ports Internal Port Server Join Port Server Debug Port Value For s0: 5NN20, for s1=5NN25, for s2=5NN30.for s15=5NN95, where s0, s1, s2,..s15 shows the number of server processes and NN is instance_number. For s0: 5NN21, for s1=5NN26, for s2=5NN31.for s15=5NN96, where s0, s1, s2,..s15 shows the number of server processes and NN is instance_number.
Example
The port for P4 on a dispatcher element with instance_number=15 is: P4 port=50000+100*15+4=51504
Administrative Services for AS Java Ports

There are additional administrative services used by the AS Java. The corresponding ports are shown in the table below. Administrative Service Ports Service Start service HTTP Start service HTTPS SL Controller Port 5NN13 5NN14 5NN17 5NN18 5NN19 Default 50013 50014 50017 50018 50019 Range 50013-59913 50014-59914 Not applicable
See also:
Page 17 of 25
TCP/IP Ports Used by SAP Applications This document provides a complete list of the ports used in conjunction with the AS Java, for example, the ports used by SAPinst during installation or when using the SAP Web Dispatcher. You can find this document on the SAP Developer Network at www.sdn.sap.com/irj/sdn/security under Infrastructure Security Network and Communications Security.
Data Storage Security

The AS Java provides a secure storage area where applications or service components on the AS Java can store sensitive data such as passwords or communication destinations, in encrypted form. Data saved in this area is encrypted using a secret key that is created explicitly for the application or service component.
Secure Storage for Application Specific Data

Applications or application components, deployed on the AS Java, can save sensitive data in encrypted form in a secure storage area in the AS Javas configuration database. The data saved in this area is encrypted using a secret key that is created explicitly for the application or service. The AS Java uses the triple DES algorithm to perform the encryption. You can use two approaches for storing and maintaining the encrypted data for the individual applications or application components: Centralized storage With centralized storage, applications or application components use the Secure Storage service on the AS Java to encrypt and decrypt the data. This data is also stored in the corresponding secure storage context on the AS Java. You can control the parameters of this secure storage area from the properties of the Configuration Manager. Decentralized storage With decentralized storage, the applications and application component maintain their own storage area for the encrypted data. They only uses the Secure Storage service on the AS Java to retrieve the key, which is necessary to encrypt and decrypt the data.
Integration
Applications or services can use the AS Javas Secure Storage service to encrypt and store sensitive data such as passwords. To use the AS Java secure store, applications or services are assigned a designated context area in the secure storage where the corresponding encrypted data is stored. To receive a context area, AS Java applications or services register with the secure storage service. The first time an application or service requests access to secure storage, the AS Java registers the application or service, creates a context for the application or service, generates a secret key, and allows the application access to the context for future requests. For more information, see Secure Storage for Application-Specific Data in the Administration Manual.
Encryption of the state Field of JSF Pages

To ensure that client-side state is protected, we recommend that you encrypt the state. To do that, you must add the com.sun.faces.ClientStateSavingPassword entry to the web.xml deployment descriptor. You can do this as follows: <env-entry> <env-entry-name>com.sun.faces.ClientStateSavingPassword</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>SOME_PASSWORD</env-entry-value> </env-entry> This causes the state to be encrypted, by using the specified password (SOME_PASSWORD).
Dispensable Functions with Impacts on Security

In productive mode, to reliably ensure that only services that are really needed run on your SAP NetWeaver system, we recommend that you use the Java Functional Unit Configuration tool (for initial configuration) or the Configuration Wizard (for ongoing configuration) to specify the technical configuration for the functional units you have installed. For more information, see the Software Logistics documentation .
Other Security Relevant Information

The following topics provide an overview of additional security related information for the AS Java. Security on the JMS Service In this topic we discuss the security aspects of the Java Message Service of the AS Java. This service is used for exchanging messages between two or more Java clients. The security issues for this service that are discussed include authorization, authentication checking, policy configurations, and communication protocols and ports. Java Virtual Machine Security The AS Java runs in a Java Virtual Machine within your operating system. This topic gives an overview of the related security information. Security Aspects of the Database Connection The AS Java uses the user persistence data stores provide for security and integrity of the data in cases of system upgrade or server failure. This topic gives an overview of the security mechanisms used for the integrity and confidentiality of the configuration and source code data stored in the user persistence stores. Destination Service Provides an overview of the security mechanisms in the Destinations service of AS Java. The Destination service is used by applications or services to specify the remote services address and the user authentication information to use for connecting to other services. Protecting Sessions Security AS Java applications can use system cookies to track user data (such as sessions tracking, logon data, etc). These cookies contain sensitive information about the user, therefore to prevent potential misuse of session information the cookies should not be exposed to client side scripts. To increase the security protection of system cookies, you can enable the use of the additional system cookie attribute HttpOnly. Creating Secure Connections Using JavaMail Applications that use the JavaMail Client Service can create secure connections with mail servers instead of plain connections. The security of connections can include the following aspects: (Mandatory) Certificate-based authentication of the parties (Optional) Signature and encryption of mail content Improved Protection Versus Login-XSRF Lists preferred settings for improved protection against login cross-site request forgery.
JMS Provider Security Aspects

The JMS connection factories are obtained using JNDI. A JMS connection can be created from the connection factory either with a user name and password, or with no parameters. In case a user name and password are provided, a validation check will be performed if the password matches the user. If not, the call will fail. If the check is successful, all subsequent JMS permission checks will be done for the specified user. In case a connection is created without specifying the user name and password, all subsequent JMS permission checks will be done for the user in the current thread context (this will be the anonymous user, if no login has been performed). Note that in both cases no logon is performed, only JMS permission checks are done for the respective user.
Communication Protocol
The JMS Provider communication uses a SAP-proprietary binary protocol on top of P4 as the transport layer. The JMS provider does not offer its own encryption on the JMS communication, but the P4 transport can be configured to run over SSL.
Data Storage
Configuration data and user data (messages) are stored in the database and underlie the database protection mechanisms.
Java Virtual Machine Security

The AS Javas processes run in a Java Virtual Machine (JVM), which means that any security aspects that apply to the virtual machine also affect the security of the AS Java. Java's security model defines the security concept and the mechanisms incorporated in the JVM. The Java security model is focused on protecting users from hostile programs downloaded from untrusted sources by providing a customizable sandbox in which Java programs run. The sandbox security model represents a shell that surrounds a running Java program and protects the host system from malicious code. Thus, because of the safety features defined by Javas security model and incorporated in the JVM, running programs can access system resources only in safe and structured ways. Java applications running in the JVM sandbox can also access native functions of the operating system where the sandbox runs. The security mechanisms of the JVM can establish whether a function can perform such access, however, they do not guard against malicious consequences from calling such native methods or software vulnerabilities in the application code of the JVM itself.
Therefore, we recommend that you follow the latest updates of JVM and install the latest patches provided by your virtual machine or operating system vendor.
Security Implications for SAP Java Virtual Machine (JVM)

The SAP JVM offers a debugging on demand feature, enabling debugging of Java programs without restart of the Java VM. With Java debugging, one can
Page 19 of 25
possibly get an insight into the confidential data of Java programs. In addition, the Java debug protocol (JDWP) allows a wide range of control over the Java VM. An attacker can therefore harm a Java program or Java application server utilizing the Java VM debugging feature. Debugging can only be enabled by the user that has started the SAP JVM. In addition, the user has to have write-permission for the Java launcher program on UNIX/Linux operating systems, or System Administrator authorizations on Microsoft Windows operating systems.
We recommend you protect your JVM with a network firewall, thereby disabling possible attacks on Java debug ports. The ports used for debugging are: In a standalone SAP JVM (not embedded in the AS Java) Without command line option, the default ports used are 8000 up to 8100, dependent on the number of concurrently-used SAP JVM instances for debugging. With command line option XdebugPortRange, the ports that are configured with the option (from)[-(to)] are used. In the SAP JVM used in an AS Java, the debug port range is configured with the AS Java Config Tool. Debugging can be turned off with the parameter XX:-EnableDebuggingOnDemand using the command line in the standalone scenario or with the AS Java Config Tool.
See also: Configuring JVM Parameters SAP Note: 1029914
Security Aspects for Database Connections

Use
When connecting to databases, the AS Java as well as the applications deployed on it authenticate themselves by means of a user name and a password. They are specified only once, when the DataSource that is used to provide the database connection is created. The DataSource is initialized with the supplied credentials and uses them for the authentication of all physical connections that it provides.
Features
You may use one of the following options for database connectivity: Using the default DataSource, you can connect to the system database in which the AS Java stores its information You can register a new DataSource to connect to another database that your application uses
Using the Default DataSource

The default DataSource is created at installation and is used by all AS Java services that need to connect to the system database. The applications that you later deploy on the server may also use this DataSource. More information: Running JPA Applications on the System Data Source
The default DataSource uses the standard database schema user SAP<SID>DB, where <SID> is the system identifier for example, J2E. The password for this user is defined at installation. The user name and password for the default DataSource, are stored encrypted in a secure storage. The parameters for this secure storage are the following properties of the Configuration Manager: secstorefs.keyfile secstorefs.lib secstorefs.secfile
You cannot establish a database connection and respectively run the AS Java without using a secure storage. It is highly recommended that you do not change the default properties. To change the password of the default user, you must: Change the user password in the database. For more information on how to do that, refer to the SAP NetWeaver Security Guide. Maintain the relevant entry in the secure storage: a. Start the Config Tool. (Execute the configtool script file in <ASJava_install_dir>\configtool.) b. Select secure store. The configuration for the secure storage in the file system appears. c. Select the jdbc/pool/<SID>/Password entry. d. Enter the database users new password in the Value field and choose Add. e. Choose File Apply to save the data. The new password is used to connect the AS Java to the database the next time it is restarted.
Page 20 of 25
Connecting with a User-Defined DataSource

If you need to connect to another database, you have to register a new DataSource using the JDBC Connector Service. More information: Managing JDBC DataSources Deploying Data Sources To create the DataSource, you must supply a valid user name and password for the database schema. The AS Java stores this data encrypted.
More Information
Managing Secure Storage in the File System
Destination Service
Use
Applications or services can establish connections to other services. When using such connections, you need to specify the remote services address and the user authentication information to use for the connection. Many applications use the Destination service for this purpose. The Destination service supports the following types of destinations: HTTP(S) RFC
Not all applications use the Destination service. Some applications have their own connection maintenance tools. For example, you configure the connection information for the RFC Adapter in the Integration Server configuration or in the Partner Connectivity Kit (PCK). Therefore, make sure you make the connection configuration in the correct location.
In earlier releases, you also maintained logon data for Web services in the Destination service. These are now maintained in the logical ports for the Web service. For more information, see Authentication.
Integration
The Destination service uses the Secure Storage service on the AS Java to store security-relevant information such as passwords. You can use the Secure Sockets Layer (SSL) protocol to secure HTTP connections. In this case, the corresponding keys and public-key certificates are stored in keystore entries in the Key Storage service. You can use Secure Network Communications (SNC) to secure RFC connections to ABAP systems. In this case, you must use SAP NetWeaver Single Sign-On or an external security product to provide the protection. For more information, see Transport Layer Security on the AS Java.
Prerequisites
If you use SNC to secure RFC connections, then SAP NetWeaver Single Sign on or the external security product used is installed on the AS Java. See Installing the SAP Cryptographic Library on the AS Java. The Destination, Secure Storage and Key Storage services must be running when an application or service requests access to its secure storage area.
Activities
For administrating the destinations, select the Destinations service in the SAP NetWeaver Administrator. For information about maintaining destinations, see: Maintaining HTTP Destinations Maintaining RFC Destinations
Development
For more information about using the Destination service in your applications, see The Destination Service API.
Session Security Protection

Java EE applications can use system cookies to track user data (such as sessions tracking, logon data, and so on). These cookies contain sensitive information
Page 21 of 25
about the user. Therefore, to prevent potential misuse of session information, cookies should not be exposed to client side scripts. To increase the security protection of system cookies, you can enable the use of the additional system cookie attribute HttpOnly.
Declaring a cookie as HttpOnly increases the security of your system because it eliminates access to this cookie in the Web browser from client-side scripts, applets, plugins, and so on. This can have side effects because some applications use such technologies and also rely on this information. These applications may no longer function correctly because they cannot access this information.
An example of this is an application that uses Java applets to perform a certain function within a Web browser application. When the user accesses the Web browser application, the backend server may authenticate the user and may issue the user a cookie (for example, a logon ticket or a session ID) to use for further authentication. If the HttpOnly attribute is set for this cookie, then neither the applet can access it, nor the cookie is automatically sent back to the server because the applet uses its own communication channel. Therefore, the user will either see a logon screen or notice other function defects (for example, a blank screen), even though the user was already authenticated in the Web browser session.
System Cookies
SAP NetWeaver Application Server Java (AS Java) system cookies affected by this configuration include: Cookies for tracking Web browser sessions, such as JSESSIONID (in accordance with the Java Servlet 2.5 specification). Cookies named saplb_ <string>, with string representing a logon group for load balancing. More information: AS Java Cookies.
When you enable the use of the HttpOnly attribute for these system cookies, some Web browsers (valid only for Internet Explorer version 6.0 SP1) return empty responses to JavaScript requests for access to the system cookies.
This feature currently has effect only for Web browsers Internet Explorer version 6.0 SP1 and later. For more information about the HttpOnly feature in Internet Explorer 6.0 SP1, see the relevant documents available at msdn.microsoft.com. For information about support of this feature in other Web browsers, consult the documentation provided by your Web browser provider. You use the HTTP service property SystemCookiesDataProtection to enable the use of the HttpOnly attribute for system cookies by configuring the property value to true.
For backward compatibility, by default the HttpOnly attribute is not enabled for use in system cookies. We recommend that you manually enable it after verifying that your applications do not rely on reading system cookies on the client side.
Do not set the SystemCookiesDataProtection property to true if the ICM property disable_url_session_tracking is also set to true. If both properties are set to true, AS Java cannot handle HTTP sessions correctly. For more information about the disable_url_session_tracking property, see icm/HTTP/ASJava/disable_url_session_tracking.
You use the HTTP service property SystemCookiesHTTPSProtection to set the Secure attribute to the Web session tracking and the load balancing (sapdb_) cookies it is related to. If the property is set to true, the Secure attribute is set to the system cookie and cookies marked as secure are only transmitted in case the communication channel is a secure one. In this case, it is obligatory that you use SSL since these cookies are not transferred via plain HTTP and session tracking on HTTP will not work. You use the SecuritySessionIDHTTPSProtection property of the HTTP Service to protect the security session identifier cookie from being sent over unsecured HTTP connection. When the property is set to true, the Secure attribute for the cookie is set and the browser will send it only over HTTPS..
If SystemCookiesHTTPSProtection is set to true, all the Web session tracking and saplb cookies will be secure regardless of the value of SecuritySessionIDHTTPSProtection. Web session tracking will be possible only when using HTTPS, which means that the application will not function properly over HTTP. You can configure the properties using SAP NetWeaver Administrator. To do this, locate the HTTP Provider Service under Service tab of the Java System Properties .
Logon Tickets
Logon tickets are cookies that are used for user authentication and Single Sign-On on AS Java. To set this attribute for logon tickets, set the user management engine (UME) property ume.logon.httponlycookie to the value TRUE. More information: Editing UME Properties.
Security Related Properties for HTTP Sessions

There are several properties of the Web Container service, which control security related aspects of HTTP sessions:
Page 22 of 25
Property SessionIPProtectionEnabled SessionIdRegenerationEnabled UseSecuritySessionIdUniqueName
Description Specifies whether the session IP protection is enabled. When this property is set to true, the HTTP session cannot be accessed from different IPs. Only requests from the IP that started the session are processed. Specifies whether the session regeneration is enabled. When this property is set to true, the Web Container regenerates the session ID on every login. Creates a unique name of security session identifier cookie per system. When this property is set to true, the system generates a specific security session identifier cookie name. This property can be used only if SessionIdRegenerationEnabled is enabled. Specifies the time period in which AS Java may accept HTTP requests that require authentication and are sent in parallel by a client (in ms). The property default value is 2000 ms. We do not recommend to increase the default value unless the parallel HTTP requests from one client cannot be processed in less than 2 seconds, for example, in cases with heavily loaded AS Java systems. For more information: Parallel HTTP Requests and Session Fixation Protection
SecuritySessionIdGracePeriod
You can configure the properties using SAP NetWeaver Administrator. To do this, locate Web Container under Service tab of Java System Properties . More information: Java System Properties
Improved Protection Versus Login-XSRF

By default, SAP NetWeaver Application Server (AS) Java enables automatic logon with just the user ID and password as URL parameters. This eases the operation of some scenarios, but exposes potential exploits for login cross-site request forgery (login-XSRF). To improve protection against login-XSRF attacks, we recommend that you disable or set to false the authentication property Enable Automatic Logon with User ID and Password(ume.logon.userpwd_automatic_logon). See also SAP Note 1441999. For more information about configuring authentication properties, see Configuring Authentication Properties.
Parallel HTTP Requests and Session Fixation Protection

When a client sends more than one HTTP requests in parallel within a short time period and some of them require authentication, this causes change of the session authentication state after the first of them is granted access to the requested resource. As a result, the rest of the parallel requests may not perform successful authentication and will be treated by AS Java as incorrect requests, that is, they will not be given access to the requested resource. A solution for this problem is provided as part of the session fixation mechanism in AS Java.
Session Fixation Protection

Valid user parallel requests are properly distinguished from session fixating attacks by a feature provided with the SecuritySessionIdGracePeriod property. This property allows a group of parallel requests that meet certain criteria (for example have equal authentication configuration) to be accepted by AS Java. The property default value is 2 seconds. The SecuritySessionIdGracePeriod property is configurable as part of servlet_jsp service properties. For more information, see Session Security Protection. When two parallel requests require different authentication processes, and the second one is not accepted, you get a 403 response with error message " Possible session fixation attack detected! Contact your system administrator with a reference to SAP Note 1417679!" Here are some alternatives for the administrator or application provider to solve this issue: Try to avoid designing applications that are sending parallel requests from one user/client (browser) that require authentication. If the first option is not possible, configure the affected applications with one and the same authentication stack. Thus both parallel requests will trigger identical authentication processes. If none of the above options can be applied, configure the authentication stack of the requested application so that the Session Fixation Protection parameter has value grace_period. The default value is strict. For more information, see: Editing the Authentication Policy of AS Java Components.
Note
Use this configuration with caution and only when the authentication mechanism is secure enough to prevent session fixation attacks.
Tracing and Logging

Security tracing and logging are important elements for securing your application server systems. Therefore, the AS Java includes monitoring and administration
Page 23 of 25
functions for the early detection and investigation of deviations from established security policies. The tracing and logging functions allow you to display security events for the entire AS Java system landscape, as well as for individual AS Java. The logging and tracing functions on the AS Java enable you to generate logs and traces for events affecting all components on the AS Java. To facilitate information requirements for different levels of troubleshooting, logs are recorded by categories and traces by component location. In addition, you can use the administration tools of the AS Java to generate logs and traces of system events with different severity levels. The following topics give additional information about the logging and tracing features for the AS Java: Logging and Tracing Gives an overview of the logging and tracing functions available for the AS Java with references to configuration sections for more information. Masking Security Sensitive Data in the HTTP Access Log Includes information about the necessary configuration changes to mask security sensitive data written to the HTTP access logs. Troubleshooting Application Errors By default in productive mode, the amount of information written to traces is limited. To have the server write more information to traces, which may be useful in development or for support reasons, set the value of the property DetailedErrorResponse to true. The AS Java monitoring and administration functions also enable you to view security events for the entire system landscape. For more information, see Log Viewing and Monitoring with the NWA.
See also: Log Configuration in the Administration Manual Logging and Tracing in the Development Manual
Logging and Tracing

The following files are available for logging important security events and helping administrators with troubleshooting: Security logging Location in Log Viewer: ./log/system/security.<n>.log Location in file system: \usr\sap\<SID>\<instance_number>\j2ee\cluster\server<n>\log\system\security.<n>.log This file contains the log entries of a number of security related services, including the following: Authentication Destination service User Management Virus Scanner Interface Web Services Successful and failed user logons and logouts (LOGON.OK, LOGON.FAILED, LOGOUT.OK, LOGOUT.FAILED) Security audit log This file contains a log of important security events, such as creation or modification of users, groups and roles. More information: Security Audit Log of the AS Java. Trace files Location in Log Viewer: ./log/defaultTrace.<n>.trc Location in file system: \usr\sap\<SID>\<instance_number>\j2ee\cluster\server<n>\log\defaultTrace.<n>.trc This file contains all the trace information for the whole server and includes trace information for user management engine (UME) libraries and the UME provider ( com.sap.security.core.ume.service ). The information in this file is on a fine-granular level and includes exceptions, warnings, and debugging information. It is mainly required by SAP support. Change log Location in file system: \usr\sap\<SID>\<instance_number>\j2ee\cluster\changelog The change log contains changes that were done manually in the SAP NetWeaver Administrator, such as creating, deleting or modifying a policy configuration, creating, deleting or modifying a keystore view, and so on. The change log contains information about what was changed, who changed it, what was the old value and what is the new value. Directory server logs When you use an LDAP directory server as a data source for the UME, you can configure log files to monitor and troubleshoot the connections. More information: Directory Server Access Log Directory Server Connection Pool Log
Viewing Log and Trace Files in the Log Viewer

Use SAP NetWeaver Administrator to view log and trace files. SAP NetWeaver Administrator provides a predefined security view. More information:
Page 24 of 25
Viewing Specific Security Views Log Viewer
Configuring the Log Viewer

Use SAP NetWeaver Administrator to configure log and trace files. More information: Configuring Log Controllers.
Masking Security-Sensitive Data in the HTTP Access Log

The HTTP Provider Service applies masking to the value of security-sensitive URL parameters, cookies, or headers that might be sent with the request. Those values appear as five dots in the relevant log file. The masking can be applied for both Common Log File format, and the SAP log format that you might be using. For more information about log formats, see Logging in Common Log File Format.
Note
HTTP headers values are not logged by default. The masking can be applied only if you have configured the LogHeaderValue property of the HTTP Provider Service. For more information, see Logging Additional Information.
When using HTTP communication logging, you should consider your security policy, user access rights to log files and the mechanisms that deployed Java EE applications use to exchange security sensitive information over HTTP.
Note
The AS Java security-sensitive information in the HTTP communication logs as an additional step, based only on the parameters definitions and HTTP headers listed below. If you transmit security-sensitive information using custom parameters or custom defined headers, masking is not applied.
The following is a list of all elements masking applies to:
Path Parameters
jsessionid
Request Parameters
j_password j_username j_sap_password j_sap_again oldPassword confirmNewPassword ticket
HTTP Headers
Authorization Cookie JSESSIONID MYSAPSSO2 The same masking applies to the above elements also in cases when the communication is performed over HTTPS.
Page 25 of 25

SAP Java Security

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Java Security

Uploaded by

Copyright:

Available Formats

PRINT FROM SAP HELP PORTAL

PUBLIC 2012 SAP AG. All rights reserved.

SAP NetWeaver Application Server Java Security Guide

Why Is Security Necessary?

About this Document

Before You Start

Important SAP Notes

PUBLIC 2012 SAP AG. All rights reserved.

Technical System Landscape

PUBLIC 2012 SAP AG. All rights reserved.

User Administration and Authentication

See also: User Management of the Application Server Java

User Administration and Standard Users

Security Policy Profiles

Standard Users and Groups

User Administration Tools

Shell Console Administrator Config Tool

Remote User Administration During Runtime

PUBLIC 2012 SAP AG. All rights reserved.

User Data Synchronization

User Data Management in UME

PUBLIC 2012 SAP AG. All rights reserved.

Authentication Mechanisms and Single Sign-On Integration

PUBLIC 2012 SAP AG. All rights reserved.

Declarative and Programmatic Authentication

Login Modules and Login Module Stacks

Authentication Stacks and Policy Configurations

PUBLIC 2012 SAP AG. All rights reserved.

Standard Authentication Schemes

PUBLIC 2012 SAP AG. All rights reserved.

Integration in Single Sign-On Environments

Single Sign-On for resource adapters

Header variables for user authentication

PUBLIC 2012 SAP AG. All rights reserved.

Transport Layer Security

Configuring the Use of SSL on the AS Java.

PUBLIC 2012 SAP AG. All rights reserved.

Communication Channel Security

Using an Intermediary Server to Connect to the AS Java

PUBLIC 2012 SAP AG. All rights reserved.

Communication Security for the Web Container

EJB to persistence layer

See also: Using Login Modules to Protect Web Applications

PUBLIC 2012 SAP AG. All rights reserved.

Communication Security for the EJB Container

Communication Security for Web Services

Web Services Communication Flow

PUBLIC 2012 SAP AG. All rights reserved.

Communication Security for Persistency Stores

PUBLIC 2012 SAP AG. All rights reserved.

Communication Path AS Java to LDAP directory server

Protocols Used LDAP

Available Security Protection Secure Socket Layer (SSL)

AS Java to RDBMS user store

JDBC 1.x JDBC 2.x

Authentication data Application data User management data

Authentication data Application data

Secure Network Communications (SNC)

Communication Security for Software Deployment

See also: Security of the SAP Java Development Infrastructure

Administrative Services for AS Java Ports

PUBLIC 2012 SAP AG. All rights reserved.

Data Storage Security

Secure Storage for Application Specific Data