SAP security is one of those neglected areas that organizations are now giving their due importance. Since confidential organizational data is now widely used and accessed over the Internet using mobile devices such as PDAs and tablets, it has become imperative that organizations take security very seriously. Efforts must be taken to ensure nobody can hack into systems and intercept data transactions.

SAP NetWeaver Portal is single point of access to the entire transactional data and applications so you need to consider SAP NetWeaver Portal security from a variety of angles. Not only is dispatcher security important; other entry points into your system such as Knowledge Management, Web Dynpro for Java, and Business Process Management (BPM) must be protected. Relying on just firewall and Basis configuration is not enough. Following are some tips for protecting your system against masquerading.

Knowledge Management Security

Knowledge Management (KM) is one of the most sensitive areas of SAP NetWeaver Portal. KM not only contains important documents, but also the repository’s connection to file and Web-based Distributed Authoring and Versioning (WebDav) servers. In addition, if unauthorized access can be obtained via any unscrupulous way, BI and metadata repositories can reveal BI system details such as SIDs and the system name. If you have a custom application using KM APIs, TREX APIs, and crawling services, you have to be extra careful when system users invoke API objects. Take a look below to know more about system users.

The following list of system users is not exhaustive. You can search for KM system users and find more users such as collaboration system users and notification system users and so on. Just keep in mind that when you use KM APIs, always use system users to invoke a specific KM service. This secures your application. As these system users do not have a User Management Engine (UME) existence, nobody can hack them to retrieve KM data.

KM_Service: Do not mistake this system user for a typical UME user. You cannot log in with this user and this user does not have a password. This user should be used mainly to execute KM APIs. To be specific, this should be used when you want to access the folder hierarchy of KM. For example, if you wish to retrieve the details of a child folder of a specific parent folder, you should always use this user instead of using an admin user. An admin user may or may not have authorization to programmatically read some or all data. The admin user physically exists in the system and has a user ID and password which, if compromised, means reading system data isn’t difficult.

Subscription_service: This system user is used mainly to fetch subscription details of any given file or folder in KM. For example, if you wish to retrieve the email ID of users who have subscribed to a specific folder or file, you should use this user.

Index_service: If you are using TREX and index APIs, you should use this user. You will be able to fetch index instances and associated properties with the help of this user. This user also allows you to crawl and index documents when used in the KM Index Management service.

Information Content Exchange (ICE)_service: If you can remember ICE Packages, you will be able to correctly guess what this user is for, which is KM content transport-related APIs and services.

KM Access Control Lists: KM manages permissions to folders and repositories with access control lists, also known as ACLs. ACLs can also be inherited by child objects from parent objects without specifically configuring permissions for the child folder. However, you can always choose to configure a separate ACL for every object in KM including a folder and a file. If you have sensitive or confidential documents stored in KM, you must always define a separate ACL for each of the confidential folders. This helps restrict illegal access to KM documents and prevents illicit users from getting hold of KM URLs from a generic URL and a document name.

Working with files: To edit a file such as a document or Microsoft Excel sheet, you have two options. One is to edit locally and another one is to edit online. Editing online is not a problem when it comes to security because online editing does not create a temporary copy of the document on the user system. However, editing locally can be critical if you do not understand how this functionality works. When you browse any Web site, it stores temporary files on your system in a dedicated temporary Internet files folder. This is applicable to KM documents too.

When you edit a file locally, KM stores this document until you save the file and check it in. If you forget to check in the document or accidentally close the editing window, KM has no way to delete the file from your machine. If you are using a company laptop, then your laptop probably contains encryption software that encrypts all the data on your machine. However, if you are using a shared system or working from a public computer or system, always ensure you delete the KM file you were editing from temporary Internet files.

Reports are always handy: In particular Virus Scan and Malicious Script handler are helpful reports. Virus Scan finds viruses attached to KM documents and allows you to clean or delete infected documents. You should run this report once every week. Malicious Script handler identifies KM objects that have a malicious executable script attached. Include this report in your KM security checklist. You access this report by following menu path Content Administration > KM Content > Tool Box (available in detail level navigation / left panel) > Reports > Mass Operation.

Delete subscriptions data: If you have allowed users to register on SAP NetWeaver Portal with their email IDs, it is possible that even when users cease to be an employee or customer, they will receive email notifications via the subscription service. This is especially true when your portal is an external facing or customer portal. In this case, it is extremely important to remove subscriptions for users who are no longer active. In SAP Portal 7.0, there was an option to delete subscription data for a deleted or inactive user. However, in 7.3, SAP has made available a report called Subscription Cleanup that allows you to delete the subscription data of users who no longer exist. Access this report by following menu path Content Administration > KM Content > Tool Box (available in detail level navigation / left panel) > Reports > User Related Cleanup > Subscription Data Cleanup.

Web Dynpro for Java and Portal Application Security 

Web Dynpro for Java security is often not considered important, especially because developers rely on Basis and Portal administrators to protect access to Web Dynpro for Java applications. However, in this section, I discuss the security measurements that every developer can implement to make applications even more secure.

Using security zones: Defining or customizing security zones for specific applications is commonly performed by an SAP portal administrator in System Administration. However, developers too can do their bit by defining security zones at the application design times. These security zones then can be edited or modified by portal administrators. This way, portal developers do not have to depend on administrators. Therefore, always define an application security zone in the deployment descriptor (i.e., Portalapp.xml file). Developers can define security zones for Portal components and Portal services in Portalapp.xml. 

Secure applications interacting with UME APIs: A Web Dynpro application having UME APIs is one of the examples of a situation in which you would like to set security zones programmatically rather than relying on a portal administrator. If your Web Dynpro application is using UME APIs, it is crucial to control access of this application to rightful users. If this application is accessed by the wrong set of users, and if they get access to UME object, they can access the entire user management engine of SAP NetWeaver Portal. This is a major security flaw and must be closed before you deploy your application. It is the responsibility of Portal developers to close this loophole.

Use system users: If you are going to use UME, TREX, or KM APIs, which grant access to sensitive data, always invoke API calls with system users instead of real users. By doing this, you further secure your application by ensuring that even if the application is hacked, all you lose are system users, which are non-existent in the UME database. Attackers cannot log in with a system user.

Perform programmatic user authentication: There is one more way you can further determine the authenticity of a user while your application executes. For example, your Web Dynpro for Java application involves reading the logged-in user or current user of the application. A further instance of a logged-in user is used to access UME or KM data. In this case, before you create an instance of a logged-in user and pass it on as an object to APIs, it is always useful to check whether the current user is an anonymous user or authenticated user. If you find that current user is indeed anonymous then you can use methods provided by IWDClientUser to forcefully log off the user or force the current user to re-authenticate.  You can use code shown in Figure 1 in a View implementation or Controller to incorporate this feature.

Figure 1

Code to force a logoff or to force re-authentication

Never maintain JAR files locally: Do not make the JAR files required for your Web Dynpro application available locally to your application. This is a major issue if you transport the application to a different system or server. This is because JAR files are not transported along with your Web Dynpro for Java application. Also, SAP NetWeaver Development Infrastructure (NWDI) guidelines strongly suggest not importing any development component (DC) that contains local JAR files. Always create a custom component of the library type and maintain all JAR files in the library DC. Add a dependency of your WebDynpro Java application to the library DC so that JARs can be referred to at runtime. This avoids post-transport application crashing due to unavailability of local JAR files.

Understand the visibility property of Web Dynpro user interface (UI) elements: For any UI element in Web Dynpro for Java framework, the following visibility properties are defined:

1. VISIBLE
2. NONE
3. BLANK
4. ALWAYS
5. NOT_YET

These values are used to manage the visibility of a particular UI element. Setting the visibility property of a UI element to NONE makes this UI element invisible to the end user. Setting visibility to BLANK  performs the same function except it takes up the view space, whereas, NONE does not take any view space. If you are using visibility property to control display of sensitive business data, then you should control visibility by NONE instead of BLANK. This is because in case of BLANK, data is still set to the client but just not displayed. In the case of NONE, data is not sent to the client at all. However, if you are on version CE 7.1 or newer, visibility BLANK property value is no longer used. Since it is no longer available you do not have to worry about setting visibility with BLANK. However, if you are on SAP Portal 7.0 or lower, make a note of this point and never set visibility to BLANK.

SAP system access and database connections: At all times, developers must avoid direct access to database resources. If there is a need to access the database directly, then always use connection pools instead of creating a connection object explicitly. For example, developers can use Java Database Connectivity (JDBC) Connectors for connecting to a standalone database.

Web Dynpro for Java applications are closely coupled with back-end systems to fetch, display, or modify business data stored in the back-end system. To enable a secured connection to remote enabled function modules, always use SAP Connector Framework APIs. There are also instances of hard coding a system alias in Web Dynpro for Java or a Portal application component. However, instead of hard coding a system alias, developers must always use IConnectorGatewayService to get the connection from maintained system aliases. Hard coding technical parameters that might need a code change at a later stage of the application maintenance calls for additional overhead cost. In addition, unauthorized access to code can reveal back-end system details such as name, client number, SID, and instance number.

Static and dynamic include of a JavaServer Pages (JSP): A JSP file can be referred at runtime by two methods. One is a static way of referring to a JSP file and is defined by the code in Figure 2.

Figure 2

Static method to refer to JSP

A static include of a JSP file renders the entire copy of the referred JSP file at the place of definition. This obviously impacts the size of the original or parent JSP file and this severely degrades application performance. You will most probably experience extremely slow loading time for connection with slow speeds or high network lag. On the other hand, a dynamic include of JSP file is defined by the code in Figure 3.

Figure 3

Dynamic include

You can identify dynamic includes with function calls. As you know, function calls do not impact program execution, and in a similar way, a dynamic include does not affect application execution speed.

Use JSP Forwards: If you have to switch between JSP pages in your applications, always forward the request instead of re-directing. A JSP forward is internally handled by JSP runtime and therefore the browser is not aware of the fact that the current application request is forwarded to a different JSP. Browsers still have an impression that the same request is continued. This is a great way to secure sensitive business data that might be prone to attackers at the time of switching requests in a browser session.

SAP BPM Security
 

With the increasing use of SAP BPM for managing process-oriented tasks, securing the process has become imperative. Unfortunately, many people do not understand the risk associated with simple tasks such as initiating a BPM process. They end up granting access to sensitive areas of the system that can further grant access to the entire system administration. Here are some tips on BPM security:

Avoid invoking SAP BPM processes via SAP NetWeaver Administrator (NWA) –  To invoke a process from NWA you first need authorization to access the admin area that is placed under the NWA. By doing this, you might end up granting access to someone who is not aware of security implications. By granting access to NWA, you basically can grant admin/super admin access to someone for whom it is not intended. Sensitive configurations such as Destinations, Connectors, Web service Connectors, JAVA services, and so on can be started or stopped via NWA.

Although you can use NWA in sandbox or development environments, it is not suitable for productive environments. You can play around to test a number of BPM features in a sandbox or development system. In this situation, you might find a manual process trigger suitable. However, when you are porting your BPM process to the quality or production environment, you need to automate the BPM process so that no human intervention is needed. There are a number of ways to automate SAP BPM process initiation. Following are descriptions of various initiation methods:

Manual process initiation: To initiate a process via NWA, which I do not recommend in any environment except sandbox or development, follow menu path NWA > Configuration Management > Process & Tasks > Process Repository > Find your BPM Process. Click the Start Process button. To initiate an SAP BPM process via NWA, you need SAP_BPM_SuperAdmin access. Because of security concerns, you cannot grant this access to business users.

Web service-based Initiation:  When you deploy an SAP BPM Process, a Web service-based service interface is generated. You can access this Web service by navigating to SAP NetWeaver Administrator > SOA > Single Service Administration. You can further use WDSL URL in your Web Dynpro for Java applications by creating a Web service model and integrating a service interface in your Web Dynpro application. This is perhaps the best way to initiate a BPM process.

There are additional ways by which you can initiate a BPM process that are out of scope of this article because they are not used in a production environment. To read more about these options, use the following URL:

https://help.sap.com/saphelp_nwce72/helpdata/en/62/a6d7ac03994e0796c6b949c8952547/content.htm

Understand BPM roles and authorizations: The SAP BPM framework operates on a number of roles and authorizations. An SAP BPM business user profile needs a different set of authorizations from just another guest or anonymous user. On a similar note, if you want to invoke an SAP BPM process without human intervention, then you need a different role. Following is a list of roles:

SAP_BPM_SuperAdmin: This is a super admin level role that can be used to trigger an SAP BPM process or perform administrative tasks such as monitor a process, suspend or resume a process, and so on. Avoid granting this role to any user except a system admin in a productive environment.

BPEM end user: If you wish to receive BPM processes and tasks in a UWL inbox, you need to assign a BPEM end user role to users. Without this role, users are not able to access BPM tasks delivered in a Universal Work List (UWL) inbox.

SAP_BPM_Debug: This role should be given only to a developer profile who intends to programmatically assign a separate or a new instance of BPM process to an already running application. However, never grant this role to any user in a productive environment. Developers can change the process instance from SAP NetWeaver Developer Studio with this role. Keep this role granting limited to sandbox or development environments only.

SAP_BPM_TRIGGER_EVENT – As noted in the earlier section, it is better to initiate a BPM process via a Web service.  However, you need SAP_BPM_TRIGGER_EVENT authorization in the system to be able to initiate a BPM process by calling its Web service interface. If you intend to use BPM APIs for programmatic initiation of a BPM process, this authorization is required. SAP_BPM_TRIGGER_EVENT is an UME action that can further be assigned to any role or group to grant BPM start access to mass users.

If you want to read more on initiating a BPM process via BPM APIs, navigate to the following URL: https://help.sap.com/saphelp_nw73/helpdata/EN/77/2943a3456147d69cd637801d3b3f3d/content.htm

Ameya Pimpalgaonkar

Ameya Pimpalgaonkar is a senior SAP architect. He specializes in SAP Netweaver Portal, SAP BPM, BRM, MDM, and SAP Mobile. His interests include UI and front-end technologies, SAPUI5, Responsive Design, and integration of modern technologies with SAP UI. He has also worked on HTML5, CSS3, and jQuery. Ameya is also a certified usability analyst from HFI, USA.

You may contact the author at ameya85@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.