!--a11y-->
Security
Aspects of Web Dynpro for Java 
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:
· Authentication
· Model Import Security
· Security of View Context Data
· Front-End Security
· Security of URL Parameters
· Stack Trace
· 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 an Application in the Web Dynpro perspective of the SAP NetWeaver Developer Studio. You can use the User Management Service to check the authorizations; there are various interfaces and methods available for this purpose.
There are different back-end scenarios when making data available to a Web Dynpro application:
· R/3 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 R/3 BAPIs called using RFC. You should also note the following security aspects:
· RFC Call
Implementing a local or central SAP System Landscape Directory (SLD) is part of the standard administration in an SAP System. If you are developing Web Dynpro applications that connect to a back end with a static user, the use of an SLD means that you can, for example, avoid using passwords as part of the Web Dynpro application code, since the SLD utilizes 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 the source code of the custom controller.
· Password Security
In the case of a password prompt when accessing the back end of the Web Dynpro application, the information bound to the view context is transported to the back end 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 an 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 back end. 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.
Information about Web services and the security aspects for programming and using Web services is available under Web Services Security.
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 do not contain any security-relevant information.
At runtime however, you may have to provide an environment that, for example, provides connections to the back end 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 view context data is generally bound to the user interface elements, which were defined for the relevant view using the View Designer, 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 R/3 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 data is required for the application. However, the Web Dynpro developer wants to map a complete structure to the component controller or custom controller and the view context to ensure that all optional data is temporarily available. If not all attributes of the mapped structure are bound, it is recommended that the unbound 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.
The Web Dynpro Rendering Framework also contains JavaScript at the client and contains numerous enhancements that are specific to Web Dynpro and help to ensure a higher level of security for the entire Web Dynpro application. The framework also supports the use of Mozilla Netscape Version 7.0.
Regarding the communication protocol and integration of files from third parties for data output, you should note the following:
· HTTPS
To ensure that Web Dynpro applications run securely in the browser, it is recommended that you use the communication protocol HTTPS (secure http). To use HTPPS for Web Dynpro, you must 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 of URL Parameters
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 stack trace.
A stack trace is a user-friendly representation of the threads and monitors in an application; the size of a stack trace depends on the complexity of the application. To display a stack trace for a Web Dynpro application, you must set the application configuration parameter Development Mode to True; information is available under Configuring the Web Dynpro Runtime Environment.
Since the stack trace also displays the relative path to the context data (“Cannot find file…”), it is recommended that you set the Development Mode parameter to False if the path is not to be read during the error search. Then, when the error page is displayed, no stack trace is rendered, but instead the system displays the general message “Error occurred. Please contact your system administrator.“
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 R/3 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 the multiple back end support – refer to Security of Logical Systems.
