When developing or running Web Dynpro programs, it is very important that the available security functions are integrated, as is also the case when programming other Web applications. With regard to the security-relevant aspects of a Web Dynpro application, the following categorization can be made:
? Model Import Security
? Security of View Context Data
? Front-End Security
? Modifiable User Interface Elements
? Checking of Generated URLs by the URL Generation Service
? Security of URL Parameters
? Stack Trace
? Web Dynpro Console
? Password Security
? Security of Web Dynpro Applications in the SAP Enterprise Portal
For a Web Dynpro Application unit, which is required for starting the actual application, you can set whether or not you want to carry out an authentication. This authentication setting is part of the application configuration. You set the relevant flag when creating the application entity Application in the Web Dynpro perspective of the SAP NetWeaver Developer Studio. You can use the User Management Service to check the authorizations. Various interfaces and methods are available for this purpose.
There are a number of back-end scenarios for making data available to a Web Dynpro application:
? SAP Business API (BAPI) (Adaptive RFC model)
? Web Service (Web Service model)
? XMI Model (Web Dynpro model from UML definition (XMI format))
When you import an adaptive RFC model, all the security settings apply that are generally valid for the BAPIs called using RFC. Note the following security aspects regarding an RFC call: Setting up a local or central SAP System Landscape Directory (SLD) is part of the standard administration of an SAP system. If you are developing Web Dynpro applications that connect to a back end with a static user, using an SLD means that you can, for example, do without passwords as part of the Web Dynpro application code, since the SLD uses a secure storage for the password. You configure an SLD for a Web Dynpro application using the Visual Administrator. The logical destination specifications are made in the relevant wizard when importing an Adaptive RFC model; you can make special destination specifications in the Web Dynpro Content Administrator. The connection to the destination itself is implemented in Custom Controller source code.
Information about Web services and the security aspects of programming and using Web services is available in the Web Services documentation.
When importing an external UML model, no security-relevant information is processed, imported, or saved. The import only requires an .xmi file that describes the object model interface. The Java-based implementation, which must be in accordance with the description in the XML file by adhering to specific naming conventions, and the metadata does not contain any security-relevant information.
At runtime however, you may have to provide an environment that, for example, makes connections to the back end available or must know the current user. This could result in security gaps at runtime, but these are not caused by the model import to Web Dynpro. Instead, they represent an inherent attribute of the individual model implementation.
The data held and processed in the view context is a central part of every Web Dynpro application. The user interface elements, which were defined for the relevant view using the View Designer, are generally bound to the individual view context elements by the Web Dynpro application developer to ensure that data flow takes place between the client and the server. However, it is also practically possible for view context data to be in the view context unbound. This can be the case if, for example, data from existing SAP back-end systems is used, but it is unclear at the time of the data binding which attributes are definitely required for the Web Dynpro application. More than one Java proxy, which corresponds to a conventional Java class, is generated for each back-end Business API, but sometimes not all generated proxies or model classes are required for the application. The Web Dynpro developer will usually want to define a controller context that also includes optional elements in the context-to-model binding. In a subsequent step, these optional elements are then included in the context mapping (for example, between the view context and the custom context) to make all optional data available temporarily. If not all elements of the context structure bound to the model are used for the data binding, it is recommended that the unused context attributes are made sufficiently secure so that they are not accidentally sent from the client to the server.
To ensure this security, you can either set the attribute property to readOnly = true in the Properties view or delete the relevant attributes. Otherwise, unauthorized access to the view context contents using the client would be possible. The general recommendation is that the view context must not contain data that cannot be changed.
To ensure that Web Dynpro applications run securely in the browser, it is recommended that you use the communication protocol Secure HTTP (HTTPS). To use HTPPS for Web Dynpro, you need to set the relevant flag in the Visual Administrator. The Web Dynpro application can then run on the port entered for the HTTPS connection.
? Office Integration and Using Adobe Forms
If you use Microsoft Office documents or Adobe forms for the output, we recommend that, for security reasons, you only use documents with signatures. Information about signature technology is available at the homepages of the individual companies. Security-relevant settings with regard to user management and SSL connections are included in the Interactive Forms Security Guide. The Adobe Document Services Configuration Guide describes the configuration steps for setting up the required users and different communication connections, for the installation and configuration of the certificates for SSL connections, signatures, and certification (SAP Service Marketplace, http://service.sap.com/instguides).
Checking of Generated URLs by the URL Generation Service
A Web Dynpro application can be modeled in two different ways: The application developer can either divide a complex application into several small applications that can call one another, or the application, which has varying logic, can be split into Web Dynpro components according to flow-relevant aspects and programmed accordingly. In the first case, the developer must ensure that any navigation to an application using a second calling application must always proceed with correct, valid, and non-security-relevant – that is, visible – parameters.
Theoretically, it would also be possible to address the application in any way – that is, you could pass an invalid value with the URL parameter. To prevent this unauthorized passing of URL parameters to the Web Dynpro application, you must check the validity of the parameters and specify it for the running application. It is recommended that you do not use security-relevant parameters in the URL. This means that the Web Dynpro application developers must define the used parameters themselves and assign the valid values to the application. Therefore, the application logic in the event handler to the startup plug of an interface view addressed using a URL should be programmed so that any unauthorized requests are caught and, for example, the value is not stored in the context and the validity is checked.
Since parameters can be set using the specified URL of the Web Dynpro application, integrating a Web Dynpro application in a SAP Enterprise Portal will result in a higher level of security for the entire application, since there is no direct access to the URL from within the Portal.
For the purposes of error analysis in a Web Dynpro application, you can write a log in a log file, but you also have the option of displaying a Java stack trace. To display the stack trace of a Java Web Dynpro application, set the application configuration parameter Development Mode toTrue.
Using the parameter value DevelopmentMode = true also results in the version information of many components – including the operating system – being passed to the client and this security gap would enable targeted attacks on a computer. You should therefore set the Development Mode parameter to False if you want to protect security-relevant data.
Furthermore, the Java stack trace displays the relative path to the context data (“Cannot find file …“). We therefore recommend that you also set the Development Mode parameter to False if you want to avoid the path being displayed during the error search. Then, when the error page is displayed, no stack trace is rendered, but instead the system displays the generic message “Error occurred”. Furthermore, the Java stack trace displays the relative path to the context data (“Cannot find file …“).
If the Web Dynpro configuration parameter Development Mode is set to False, as described under “Stack Trace“, all version information – for example, on the Web Dynpro runtime, Java Development Kit (JDK), or client – can still be accessed by the administrator using Web Dynpro console commands. The administrator can use these console commands to make the version information such as the server operating system or the Java version, which are written to the HTML output for every request, accessible to other users. These users can then also access this information via the Web Dynpro Console.
In the case of a password prompt when accessing the server, the information bound to the view context is transported to the SAP Web Application Server and back, if the same view is displayed again. The password input field, which is bound to a context attribute of the type String, is displayed in unreadable form. However, it is readable when passed in the data exchange with the SAP Web Application Server.
To prevent unauthorized identification of the password, the Web Dynpro application developer should transfer the password to a second context attribute that is not involved in the data flow between the view and the server. Another option is to make the field unreadable by setting it to (****).
Note that the password may also be displayed in readable form when tracing, depending on the tracing settings. The password will only be visible to the developer who used it for access, but we thought it necessary to point out this possibility nonetheless.
The SAP NetWeaver technology platform enables a standardized access to user information. Rolls and authorizations used for the SAP Enterprise Portal 6.0 are automatically available to Web Dynpro application embedded as an iView. The Web Dynpro application and SAP EP 6.0 can use the same user store. To access the user data, the Java API of the User Management Engine (UME) can connect to an LDAP directory, an external database, or the SAP user management. The logon method Single Sign-On is available for Web Dynpro applications integrated in the SAP Enterprise Portal. If the Web Dynpro application integrated in the Portal accesses several back ends – that is, uses multiple back end support – note the security aspects of logical systems.