Technical Articles
Securing Webdynpro Java Applications with Webdispatcher
We had a requirement to block users from seeing certain SAP PI/PO messages. In SAP PI it is only possible to limit users from seeing all payloads or no payloads at all. We have some PI test messages that we should not show to users because they are confidential.
We wanted the simplest approach for it without having to develop a new monitor.
We found we could use the SAP Web dispatcher to help intercept the Webdynpro applications and then filter the messages that users should not see. It means that we did not need to create new applications to manage this. The web dispatcher has some much bigger options than is normally used.
Possibility to intercept a request from UI and add custom logic.
SAP allows modifying HTTP requests. We took this article as a basis https://help.sap.com/viewer/683d6a1797a34730a6e005d1e8de6f22/7.5.9/en-US/86960bf3f8544e0d91c70c9359e2f127.html
Our goal is to block Webdynpro Application from watching payloads remotely and then use our own redirect servlet to fetch the normal payload.
Steps
In our case, we needed to forward a request for opening a single message page to our custom Java Servlet and then decide if a user is allowed to view this page according to our custom business logic.
In general, there are a couple of steps to achieve this:
1. Find and open file icm_filter_rules in \usr\sap\<PI System Name>\SYS\global\security\data.
2. Write the rules, which will be used to forward the request to our custom servlet.
Example:
if %{REMOTE_ADDR} !stricmp 127.0.0.1 [AND]
if %{REMOTE_ADDR} !stricmp ::1 [AND]
if %{REQUEST_METHOD} stricmp “GET” [AND]
if %{FORMFIELD:afwmsgkey} !stricmp “”
RegIRedirectUrl ^/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp.*$ /webdynpro/dispatcher/sap.com/pro-confidential-data-component/MessagePageServlet [QSA]
It means that a request will be redirected only if an IP address is not localhost, for GET method and if “afwmsgkey” query parameter is not empty. In this case requests which matches the pattern “/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp” will be redirected to “/webdynpro/dispatcher/sap.com/pro-confidential-data-component/MessagePageServlet” and all query parameters will be sent as well.
3. Save the file and restart the server.
4. Create a Service Component in SAP NetWeaver. In our case, it consists of two Development Components: ear and web.
5. Create a Java Servlet and implement some custom logic there:
As you can see in if-else clause, it is possible either just to return the response or forward the request further.
This forward context uses the current users credentials, so no need to implement new user authentication.
6. Deploy this Service Component to the SAP system.
7. Finally, the requests will be processed via the custom Java Servlet:
Once we open the viewing of a new message the Get request will be sent via the Figaf Component. POST requests will be sent via a normal endpoint. So it will all work identically.
Conclusion
I hope you find this interesting and see the Web Dispatcher can help with a lot more on your SAP Netweaver system.
We can now fetch messages payloads outside the SAP PI server. If users log on to the PI system the redirect will not work because they are then on the localhost.
Hi Daniel,
Thanks for this blog. From a technical perspective this is a pretty interesting read. I never wrote a custom module to reroute/filter requests to NetWeaver.
Regarding the purpose itself I have a question: how does this differentiate from the role-based standard solution to give/deny access to payload view? As described in the following note you can restrict access to the payload view in monitoring even (on an interface level): https://launchpad.support.sap.com/#/notes/1370334
(Don’t take it as criticism. I really appreciate the work you’ve done. I just want to understand the advantages of your solution over the standard solution for this type of problem.)
Hi Raffael
It may be useful to block the messages in that way with payloads. But that gives access to an interface or not. Not specific messages.
Our requirement was that if messages were sent from the Figaf IRT then we wanted to block them. In the Figaf tool, we fetch lots of confidential messages from production systems. We wanted to be able to test messages without giving contractors/less trusted employees access to the data.
In the Figaf tool, we have masked the payloads so nobody can see it. Then we wanted to make sure to secure the payloads when testing aswell. We found we could send messages with a specific guid prefix and then be able to check if the message or parent had that prefix. If it did we wanted to block the message.
So the filter is on a message level filter.