PRINT FROM SAP HELP PORTALDocument: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. Theinformation contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components ofother 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, theAdobe 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 aregistered 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 ofW3C ®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of SunMicrosystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAPBusiness 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 andin 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 documentserves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and itsaffiliated 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 withrespect 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 andservices, 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 (SAPNetWeaver 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 onlyrelevant 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 onthe rise. When using a distributed system, you need to be sure that your data and processes support your business needs without allowing unauthorized accessto critical information. User errors, negligence, or attempted manipulation on your system should not result in loss of information or processing time. Thesedemands 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 SecurityGuide

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 forthe 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 StartProvides links to additional information, a list of important SAP Notes and other security guides that apply to securing the AS Java.

● Technical System LandscapeProvides a brief overview of the technical system landscape of the Java systems.

● User Administration and AuthenticationDescribes user management, standard user types and synchronization of user data, as well as, AS Java authentication mechanisms and their integration inSingle Sign-On (SSO) environments.

● AuthorizationsProvides an overview of the authorization concepts on the AS Java. The topics discussed include authorization checking on the AS Java, standard UserManagement Engine (UME) actions and security roles.

● Network SecurityProvides an overview of the communication channels used by the AS Java and the corresponding transport layer security mechanisms. We also provide anexample of a secure network infrastructure using network zones and information on the standard communication ports used by the AS Java.

● Data Storage SecurityDescribes 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 SecurityProvides information about deactivating optional AS Java services that you may not need in productive operations.

● Other Security Relevant InformationPresents 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 LoggingProvides 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.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 2 of 25

Important SAP Notes

SAP Note Number Title

720590 User Management Engine (UME) on WAS 6.30 and higher.

812332 How to set up logging on a remote J2EE client

710146 How to change JVM Settings

753002 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 Quick Link on the SAP Service Marketplace

Security /security

Security Guides /securityguide

Network security /network

Released platforms /platforms

SAP Solution Manager /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 versatilityrequirements, the AS Java has an open and standards-based architecture that enables communication with a number of partners in your system landscape, forexample 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 openenvironments such as the Internet. Therefore, AS Java enables you to protect your productive systems by using firewalls to deploy the AS Java system instancesin separate security zones in your system landscape. In addition, you can use application gateways, such as proxy servers, to filter and authenticatecommunication requests for the AS Java and related application components.

For administration and configuration information for specific set ups, see AS Java Configuration in the Administration Manual.

You can also find more information from the resources listed below.

Topic Guide/Tool Quick Link to the SAP Service Marketplace

Technical description for the SAP NetWeaver AS Java Master Guide

service.sap.com/instguides

High Availability service.sap.com/ha

Security service.sap.com/security

PUBLIC© 2012 SAP AG. All rights reserved.

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) appliesthese 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 requirethe 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 Detailed Description Further Information

IdentityManagement

Web-based tool integrated into SAP NetWeaver Administrator that provides functions for configuration of the usermanagement engine (UME) and user administration.You can use the functions supplied with this tool from a Web browser.

Administration Manual:User Management

of the ApplicationServer Java

ShellConsoleAdministrator

A command line tool that enables remote administration from Telnet clients.The default AS Java configuration enables only administrator users to use telnet.

Administration Manual:Remote

Administration UsingTelnet

Config Tool An XML-based tool that enables offline configuration of AS Java cluster elements. Changes made using this toolmust be exported to the engine database and may require you to restart the AS Java. This tool does not supportremote administration of AS Java.

Administration Manual:Config Tool

Remote User Administration During Runtime

PUBLIC© 2012 SAP AG. All rights reserved.

Page 4 of 25

User management during server runtime enables efficient and scalable user management for your productive systems. Furthermore, remote user administrationfacilitates security management of individual AS Java systems, for example, when running in a cluster. Therefore, the AS Java provides the followingadministration 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 Shell Console Administrator Identity Management

Create, view, or delete users Yes Yes

Search for users No Yes

Import users from external systems No Yes

Lock or unlock users No Yes

List locked users No Yes

Change user passwords Yes Yes

Define password rules No Yes

Require password change No Yes

Create, delete and manage groups and group members Yes Yes

Assign a public-key certificate to a user Yes Yes

Assign roles to users No Yes

Assign UME actions to roles No Yes

Configure user stores 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 usermanagement 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 storinguser 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 istransparent 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 ASABAP data sources.

For an overview of the architecture and the process flow of user data replication in the UME, see the figure below.

PUBLIC© 2012 SAP AG. All rights reserved.

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 datasources.

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 (SAPsystem, 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 batchrequests:

● 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 Bindingsspecification). 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 tochoose 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 underlyingtechnology, login modules and login module stacks. Programmatic authentication also extends declarative authentication by using authentication schemes, whichallow 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 AuthenticationExplains the difference between declarative (container-based) authentication and programmatic (UME) authentication. The type of authentication that anapplication uses has consequences for the login module stack it uses and on where you configure authentication.

● Login Modules and Authentication StacksProvides conceptual information about login modules and login module stacks. Login modules define the authentication logic, whereas authentication stacksenable you to define the sequence of login modules checked for authorizing access to an application.

● Authentication SchemesProvides conceptual information on authentication schemes.

● Integration in Single Sign-On EnvironmentsProvides 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

PUBLIC© 2012 SAP AG. All rights reserved.

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 desiredauthentication mechanism in its deployment descriptor. When a protected resource of this component is accessed, the container in which the componentruns 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 triggersauthentication 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 descriptorsweb.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 inturn 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 tablebelow:

ApplicationType

Type ofAuthentication

Where is Login Module Stack defined

Webapplications

Declarativeauthentication

Declared in the web.xml deployment descriptor of the Web application.For more information, see Protecting Java Web Applications.

Webapplications

Programmaticauthentication

This depends on how the application is programmed. Applications can define an authentication scheme in their calls to theAPI. By default, if they do not define an authentication scheme, these applications use the login module stack referenced bydefault in the authentication schemes file.

WebDynproapplications

Programmaticauthentication

For more information, see Security Aspects of Web Dynpro for Java.

PortaliViews

Programmaticauthentication

An iView property defines which authentication scheme the iView uses. The authentication scheme references a login modulestack.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 whereit 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 isalso 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 isdelivered 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, orauthentication stack, enables you to choose different combinations of authentication for each of the AS Java components or the applications you create and deployto the AS Java.

PUBLIC© 2012 SAP AG. All rights reserved.

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, Javaapplications, services, or modules, are registered with the Security Provider service so that you can apply security restrictions to them. The set of securityrestrictions 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 andapply 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 useauthentication 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 authenticationschemes enable pluggable authentication for applications using UME authentication. You can easily ‘plug in’ additional authentication schemes without having tochange 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 theconfiguration of the portal so that the references point to your custom authentication schemes. This allows you to change the authentication schemes withouthaving 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 aswell.

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 AuthenticationScheme

Description Login ModuleStack

Referenced by

uidpwdlogon Requires form-based logon with user ID and password. ticket default,UserAdminScheme

certlogon Requires authentication using client certificates. client

basicauthentication Uses the Basic Authentication feature of the HTTP protocol. ticket

header Allows authentication using external Web access managementproducts.

header

anonymous Provides a very basic form of anonymous logon. A logon ticket is notissued.

PUBLIC© 2012 SAP AG. All rights reserved.

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 authenticationmechanisms enable efficient integration into Single Sign-On (SSO) environments.

For an overview of the authentication mechanisms shipped with AS Java, see the table below:

AuthenticationMechanism

Description

BasicAuthentication

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.

Logon Tickets 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 issueda logon ticket after they have authenticated themselves against a ticket issuing system, with any of the supported mechanisms. The ticketcan then be submitted to other SAP or non-SAP ticket accepting systems as an authentication token. The user does not need to enter a userID or password for authentication but can access the system directly after the system has checked the logon ticket.For more information, see Using Logon Tickets with AS Java.

Clientcertificates

As an alternative to Basic Authentication using a user ID and passwords, users using a Web browser as a front-end client can also provideX.509 client certificates to use for authentication. In this case, no passwords have to be transferred and the communication of usercredentials is secured using the Secure Sockets Layer (SSL) Protocol. Authentication takes places without direct user intervention, whichallows integration in a SSO environment.For more information, see Using X.509 Client Certificates on the AS Java.

SAMLAssertions

You can use SAML for SSO in a scenario where a user is authenticated on an external authentication system that acts as an SAMLauthority. 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 SAMLspecification, and by default its use is activated in the SAML configuration. However, for testing purposes, you can disable the enforcementof 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 userestablishes a source site server that initiates the SAML communication. This source site provides the destination site with an assertionartifact, which is an identifier for the user’s assertions. The source site also provides a responder, which acts as the SAML authority thatactually provides the user’s assertions. The destination site provides the desired resource and an artifact receiver, which receives the initialassertion artifact and passes it on to be evaluated by the SAML login module.If the user’s ID as provided by the SAML authority is not identical to the user ID at the destination site, then the destination site must alsoprovide a user mapping mechanism.For more information, see ../../KW/IWB_EXTHLP~440DA0DF25C1648FE10000000A1553F7/ Configuring AS Java as a ServiceProvider.

KerberosAuthenticationwith SPNego

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 servercomponents into the Windows Integrated Authentication infrastructure. The SPNegoLoginModule of the AS Java enables you to use Kerberosindependently of the underlying operating system (OS) of the AS Java host and without an intermediary Web server.For more information, see Using Kerberos Authentication.

Single Sign-Onfor resourceadapters

The AS Java provides an additional authentication mechanism type supported by the connector container: SAP Assertion Ticket of typecom.sap.security.core.server.jaas.SAPAuthenticationAssertionTicketCredential. The SAP Assertion Ticket is fully compatible with the SAPLogon Ticket. With this authentication mechanism, you can specify additional authentication types in the deployment descriptor of theresource adapter according the J2EE Connector Architecture.For more information, see Single Sign-On for Resource Adapters and JCA.

Headervariables foruserauthentication

You can use header variable authentication to delegate user authentication to any external product, which authenticates the user and returnsan authenticated user ID as part of the HTTP header. Users only have to authenticate once against the external product and can then accessapplications 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.

If appropriate security measures are not taken, authentication using header variables can allow attackers to impersonate a user by sending a request with auser 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 theauthenticating 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 betweenthe 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 JEEsecurity 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, andauthorization 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 topologyused 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 (frontends). The AS Java works at the database and application levels in your implementation framework, where it defines and forwards the presentation logic to Webclient 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 shownin 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 SAPServer Software, which is available on the SAP Service Marketplace at http://service.sap.com/security.

PUBLIC© 2012 SAP AG. All rights reserved.

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 NetworkCommunications (SNC). The transport layer security functions on the AS Java use the security provider libraries and the AS Java security environment. Youspecify 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 Configuring the Use of SSL on the AS Java.

For information specific to each of the communication protocols used by the AS Java, see the table below.

Protocol SecurityMechanism

Comment

HTTP Secure SocketLayer (SSL)

P4 is the transfer protocol for Java specific Remote Method Invocation (RMI) communication. This protocol is used for remotedeployment, as transport layer for JMS (Java Message Service) protocol, and remote method invocations of custom remoteobjects bind in naming..For more information, see Configuring the Use of SSL on the AS Java in the Administration Manual.

P4 Secure SocketLayer (SSL)

P4 is the transfer protocol for Java specific Remote Method Invocation (RMI) communication. This protocol is also used forcommunication 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 Secure SocketLayer (SSL)

IIOP is an alternative transfer protocol to use for RMI communication requests. You can also use IIOP for communication withCORBA 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.

LDAP Secure SocketLayer (SSL)

You can use an LDAP directory server as the persistence layer for the UME user store. You can use SSL for the TransportLayer Security in this case.

RFC Secure NetworkCommunications(SNC)

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 driver-dependent

JDBC is a communication protocol for connecting to databases. Transport Layer Security for database connectivity is providedby the driver used to connect to the database.

Telnet Virtual PrivateNetwork (VPN)

Telnet is used for remote administration using Shell Admin tool. We recommend establishing a virtual private network to securethe connection.For more information, see Remote Administration Using Telnet in the Administration Manual

Session N/A Session is a type of communication protocol that is used only between the Internet Communication Manager (ICM) and theserver 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.

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

PUBLIC© 2012 SAP AG. All rights reserved.

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. Deployedapplications 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 arethe protocols that are used for Java specific Remote Method Invocations communication. In addition, the AS Java supports SOAP for Web Servicescommunication.

The AS Java containers represent an abstract logical grouping of runtime services and life cycle management functions for application components. The ASJava containers include the Web Container, EJB Container, Web Services Container and Persistence Container. The security aspects vary according to thecontainer 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 JavaGives an overview of the security aspects associated with using intermediary devices such as the SAP Web Dispatcher, Microsoft IIS and other servers, forexample, the Apache reverse proxy.

● Communication Security for the Web ContainerPresents an overview of the security aspects of the communication between the AS Java and Web clients, for example Web browsers and Web Dynproapplications.

● Communication Security for the EJB ContainerDiscusses the security aspects of the communication between application servers acting as clients or servers and the AS Java.

● Communication Security for Web ServicesProvides an overview of the security aspects of the communication channels relevant to Web Services.

● Communication Security for Persistence LayerProvides an overview of the security aspects of connecting the AS Java to backend systems and user persistency stores.

● Communication Security for the Software DeploymentProvides 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 ManualCommunication Security

● Security Guide for Connectivity with the AS Java in the SAP NetWeaver Security Guide

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 morecritical 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

PUBLIC© 2012 SAP AG. All rights reserved.

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-chargeto SAP customers that operates using the SAP application server load-balancing mechanisms. It supports the use of SSL for securing connections and doeshave 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 additionalfeatures 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 Webapplication client is passed through the Internet Communication Manager (ICM) for load balancing and is then forwarded to the Web applications (WARs) runningin the Web container of the AS Java. The Web applications then access business objects using Enterprise Java Beans (EJBs) from the EJB Container. The EJBsin 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 ProtocolUsed

Type of Data Transferred Available Security Protection

Front-end client using Web application client toapplication server

HTTP · Authentication information· All application data

Secure Socket Layer (SSL)

Web application to Enterprise Java Bean P4IIOP

· All application data● Data about propagation of security credentials

Secure Socket Layer (SSL)

EJB to persistence layer JDBCLDAPRFC

· All application data· Authentication data when accessing persistence layers

or remote servers

Driver dependent encryptionfor JDBCSSL for LDAPSNC for RFC

See also:

● Using Login Modules to Protect Web Applications

PUBLIC© 2012 SAP AG. All rights reserved.

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 remoteobjects 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 EJBcontainer. The table below presents an overview of the security relevant information for each of the communication paths.

Communication Path ProtocolsUsed

Type of Data Transferred Available SecurityProtection

Client side RMI-P4 object accessing server-side EJBor remote object

P4 · Authentication information· All application data

Secure Socket Layer (SSL)

Client side RMI-IIOP object accessing server-sideEJB or remote object

IIOP · Authentication information· All application data

Secure Socket Layer (SSL)

Client side CORBA object accessing server-sideEJB or remote object

IIOP · Authentication information· All application data

Secure Socket Layer (SSL)

EJB to persistence layer JDBCLDAPRFC

· All application data· Authentication data when accessing persistencelayers or remote servers

Driver-dependent encryptionfor JDBCSSL for LDAPSNC 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. Itrepresents 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 ofbusiness 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, forexample EJBs, Java Classes (in Servlet Container), Portal Services. The Framework takes care to deserialize incoming XML SOAPData and invoke animplementation. In addition, based on a Web Services Definition Language (WSDL) Description a WS Proxy can be generated that exposes a Java Interface tothe clients, and generates XML SOAP Messages.

For an overview of the communication flow, see the figure below.

Web Services Communication Flow

PUBLIC© 2012 SAP AG. All rights reserved.

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 isthen 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/orencrypting 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 decoupledinteraction, connection-oriented security, such as SSL, alone is insufficient or inappropriate. Therefore, the AS Java enables you to use Document securitymechanisms, such as OASIS WS Security XML signatures and XML encryption, on a per message basis. In addition, to prevent unpredictable behavior ofWeb 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 timedevelopment environment for publishing, discovering, and accessing Web services on the AS Java. Security related features such as communication type orauthentication 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. WSdefinitions and deployed Web Services are published in a UDDI registry. WSDL documents provide the basis for the WS consumer and can be found in theService Registry using a Web browser or the standard UDDI API’s.

The WS Consumer side derives the WS proxy generation based on the Web Service Definition, retrieved from the UDDI. Technical details that are predefined inthe WS configuration are configured separately in the client runtime for the WS Container of the AS Java. For more information, see Configuring the ServicesRegistry in the Administration Manual.

For an overview of the communication paths and the relevant security protection, see the table below.

Communication Path Protocol Used Type of Data Transferred Security Protection

WS Consumption SOAP over HTTP WS application data in XML format.Authentication information

Secure Socket Layer.Document Security

· XML signature· XML encryption

Client AuthenticationClient exclude lists using a HTTP proxy server

Publish/Find WDSL HTTP WSDL application dataAuthentication information.

Secure Socket LayerUDDI server Basic or Certificate AuthenticationClient exclude lists using a HTTP proxy server

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.

PUBLIC© 2012 SAP AG. All rights reserved.

Page 15 of 25

Communication Path Protocols Used Type of Data Transferred Available Security Protection

AS Java to LDAP directory server LDAP ● Authentication data● Application data for directory management● Directory entries

Secure Socket Layer (SSL)

AS Java to RDBMS user store JDBC 1.xJDBC 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 sideDeploy 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 clientapplications 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 AdministrationFor telnet deployment, you open a Telnet session to the AS Java and then use the Deploy Controller functions for software deployment. To secure thecommunication, we recommend that you can use a VPN.

For more information about using these tools in your deployment scenario, see Deployment: Putting It All Together in the Development Manual. For anoverview of the communication flow, see the figure below.

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 Protocols Used Type of Data Trasferred Available Security Protection

Deploy Controller Client to AS Java P4 ● Authentication data for AS Java connection● Application data for deployment

VPN

Shell Administration Telnet ● Authentication data for the connection● Application data for deployment

VPN

See also:

Security of the SAP Java Development Infrastructure

AS Java Ports

PUBLIC© 2012 SAP AG. All rights reserved.

Page 16 of 25

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 atinstallation 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 serverprocess. 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 theinstance name including the instance number, for example, JC40 (where 40 is the instance number).

Dispatcher port_index Values

Index Port Name

0 HTTP port

1 HTTP SSL port

2 IIOP Initial Context port

3 IIOP SSL port

4 P4 and JMS port

5 P4 SSL port

6 IIOP port

7 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 15and 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 ASJava. 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 Port Name

0 Join port

1 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 Value

Server Join Port 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 isinstance_number.

Server DebugPort

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 isinstance_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 Port Default Range

Start service HTTP 5NN13 50013 50013-59913

Start service HTTPS 5NN14 50014 50014-59914

SL Controller 5NN175NN185NN19

500175001850019

Not applicable

See also:

PUBLIC© 2012 SAP AG. All rights reserved.

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 whenusing 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 orcommunication destinations, in encrypted form. Data saved in this area is encrypted using a secret key that is created explicitly for the application or servicecomponent.

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 Java’sconfiguration 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 thetriple 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 storageWith centralized storage, applications or application components use the Secure Storage service on the AS Java to encrypt and decrypt the data. This datais 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 ofthe Configuration Manager.

● Decentralized storageWith decentralized storage, the applications and application component maintain their own storage area for the encrypted data. They only uses the SecureStorage 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 Java’s Secure Storage service to encrypt and store sensitive data such as passwords. To use the AS Java securestore, 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 tosecure storage, the AS Java registers the application or service, creates a context for the application or service, generates a secret key, and allows theapplication 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.ClientStateSavingPasswordentry 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 JavaFunctional Unit Configuration tool (for initial configuration) or the Configuration Wizard (for ongoing configuration) to specify the technical configuration for the functionalunits you have installed.

For more information, see the Software Logistics documentation .

Other Security Relevant Information

PUBLIC© 2012 SAP AG. All rights reserved.

Page 18 of 25

The following topics provide an overview of additional security related information for the AS Java.

· Security on the JMS ServiceIn 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 ormore Java clients. The security issues for this service that are discussed include authorization, authentication checking, policy configurations, andcommunication protocols and ports.

● Java Virtual Machine SecurityThe 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 ConnectionThe 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 givesan overview of the security mechanisms used for the integrity and confidentiality of the configuration and source code data stored in the user persistencestores.

● Destination ServiceProvides an overview of the security mechanisms in the Destinations service of AS Java. The Destination service is used by applications or services tospecify the remote service’s 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 informationabout the user, therefore to prevent potential misuse of session information the cookies should not be exposed to client side scripts. To increase the securityprotection of system cookies, you can enable the use of the additional system cookie attribute HttpOnly.

● Creating Secure Connections Using JavaMailApplications that use the JavaMail Client Service can create secure connections with mail servers instead of plain connections. The security of connectionscan 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, orwith 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 checkis 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 thecurrent 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 encryptionon 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 Java’s processes run in a Java Virtual Machine (JVM), which means that any security aspects that apply to the virtual machine also affect the security ofthe 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 fromhostile programs downloaded from untrusted sources by providing a customizable sandbox in which Java programs run. The sandbox security model representsa shell that surrounds a running Java program and protects the host system from malicious code. Thus, because of the safety features defined by Java’s securitymodel 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 theJVM can establish whether a function can perform such access, however, they do not guard against malicious consequences from calling such native methods orsoftware 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

PUBLIC© 2012 SAP AG. All rights reserved.

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 onUNIX/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 ConfigTool.

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. Theyare specified only once, when the DataSource that is used to provide the database connection is created. The DataSource is initialized with the suppliedcredentials 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 laterdeploy 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 thisuser 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 followingproperties 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 notchange 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 user’s 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.

PUBLIC© 2012 SAP AG. All rights reserved.

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 service’s address and theuser 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 connectioninformation for the RFC Adapter in the Integration Server configuration or in the Partner Connectivity Kit (PCK). Therefore, make sure you make the connectionconfiguration 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 Webservice. 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 inkeystore 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-Onor 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

PUBLIC© 2012 SAP AG. All rights reserved.

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 securityprotection 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. Theseapplications 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 Webbrowser 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 forfurther 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 serverbecause the applet uses its own communication channel. Therefore, the user will either see a logon screen or notice other function defects (for example, ablank 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 emptyresponses 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 InternetExplorer 6.0 SP1, see the relevant documents available at msdn.microsoft.com. For information about support of this feature in other Web browsers, consult thedocumentation 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 valueto true.

For backward compatibility, by default the HttpOnly attribute is not enabled for use in system cookies. We recommend that you manually enable it afterverifying 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 totrue, 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 thecommunication 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 sessiontracking 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 ofSecuritySessionIDHTTPSProtection. Web session tracking will be possible only when using HTTPS, which means that the application will not functionproperly 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 SystemProperties .

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 managementengine (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:

PUBLIC© 2012 SAP AG. All rights reserved.

Page 22 of 25

Property Description

SessionIPProtectionEnabled Specifies whether the session IP protection is enabled. When this property is set to true, the HTTP session cannot beaccessed from different IPs. Only requests from the IP that started the session are processed.

SessionIdRegenerationEnabled Specifies whether the session regeneration is enabled. When this property is set to true, the Web Container regeneratesthe session ID on every login.

UseSecuritySessionIdUniqueName Creates a unique name of security session identifier cookie per system. When this property is set to true, the systemgenerates a specific security session identifier cookie name. This property can be used only ifSessionIdRegenerationEnabled is enabled.

SecuritySessionIdGracePeriod Specifies the time period in which AS Java may accept HTTP requests that require authentication and are sent in parallelby 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 beprocessed 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

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 theoperation of some scenarios, but exposes potential exploits for login cross-site request forgery (login-XSRF). To improve protection against login-XSRF attacks, werecommend 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 thesession 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 performsuccessful 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 thisproblem 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. Thisproperty allows a group of parallel requests that meet certain criteria (for example have equal authentication configuration) to be accepted by AS Java. Theproperty 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 Note1417679!"

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 identicalauthentication processes.

If none of the above options can be applied, configure the authentication stack of the requested application so that the Session Fixation Protection parameterhas value grace_period. The default value is strict. For more information, see: Editing the Authentication Policy of AS Java Components.

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

Note

PUBLIC© 2012 SAP AG. All rights reserved.

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 securityevents 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 facilitateinformation requirements for different levels of troubleshooting, logs are recorded by categories and traces by component location. In addition, you can use theadministration 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 TracingGives 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 LogIncludes 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 usefulin 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 debugginginformation. 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 oldvalue 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:

PUBLIC© 2012 SAP AG. All rights reserved.

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. Thosevalues 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.

HTTP headers values are not logged by default. The masking can be applied only if you have configured the LogHeaderValue property of the HTTP ProviderService. 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 EEapplications use to exchange security sensitive information over HTTP.

The AS Java security-sensitive information in the HTTP communication logs as an additional step, based only on the parameters definitions and HTTPheaders 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.

Note

Note

PUBLIC© 2012 SAP AG. All rights reserved.

Page 25 of 25