I was presenting the Figaf IRT tool to an SAP PI customer, that had a huge amount of interfaces with confidential data and was looking to test migration. In the tool, we already had an option to take a payload then anonymize the content of it. It did require you knew what was confidential and some data is easy while other types of data can be more difficult like to figure out if it needed to be secured.

For a migration or an upgrade, the normal way has been to ask the business to perform some manual tests to see if things were working. The problem is they would create an order with one line item. It will not provoke the possible errors in production where you have orders with 100+ lines of 10 different product types.

My take on this has been to take as much test data as possible the most simple way and then create test cases on it.

Your SAP PI or SAP CPI system contains a lot of confidential data it can be;

• Salary or HR data
• Orders
• Business Partner Masterdata
• Finance documents

With our normal record/replay approach, we were giving too many people access to the data. So everybody with access to the Figaf system could fetch the data they wanted. If you have contractors working on your project it may not be ideal.

The puzzle

That was the puzzle I wanted to solve: How can we test with a lot of data, without revealing what the real data was.

Over Christmas break, is spend some time to find a good solution. I came up with a plan on how we could enable the users to test, and not view confidential data. We spend 3 weeks implementing the solution, so it was not a large development. We still have some implements to make for it to work.

The solution

The addition of the Figaf tool to handle this processing is in two parts. One is in the Figaf tool, the other to protect users in the Test system from viewing the data.

Protecting the data

Most confidential data is on your production system. In a new setting, you can specify that the system contains confidential data. It means that you can only run a test on a secured system and when viewing the content it will all be scrambled. We see a secured system as a test system, where you have the option to set up blocking of messages and that will not send data to remote systems.

Once we sent a message thru the system it should also be blocked in the adapter. We are using the Figaf test module for this. So the message will just be canceled and not delivered to the adapter.

In most cases, you don’t need to see the payloads for testing. If everything is good the only thing that you are interested in is to see what field/XML node there is something wrong with. Then you can evaluate if it is a timestamp that you can ignore.

We, therefore, build a masking system that would only allow users to see payloads in a masked form when doing the comparison. The comparison is done on the real payload, not the masked.

In the following image, you can see how it is possible to see the output of the comparison in masked mode. Numbers are replaced with 9 and characters with x and X. From the masked payload, you can see there is a difference in the Time segment.

If you have the correct role you can get to view the real payloads, so users with special access have the ability to see the specific payload.

Blocking access to the system

In our terms, a system is secured if it does not give users access to view the test payloads. The easiest way to enable this would be just to block all users from viewing payloads. In most cases, it would be nice to view the payloads. The way we found to solve the problem was to add a prefix to the message GUID when we sent it, that way we would be able to find the bug.

We had considered building our own monitor but we found we could just handle filtering with the Web dispatcher. The web dispatcher has a good way to set up filtering on when the user opens a specific page. We could deploy our own servlet on the page and then set up some filter rules for when users open the page.

If messages could not be split we where able to just use the standard filters, but because a PI message can have chield messages and they will have a “normal” GUID then it was not possible. Therefore we could add the filter in servlet to find the messages and allow users to see the normal ones.

I’ll share the code and the web dispatcher script in the next blog.

Roadmap

We still have some work to do with this.

One of the next things we will approach is to enable the same when you are testing SAP CPI. Here you have a lot of HR data that you need to test. We also have a monitor already for SAP CPI, so it would be pretty easy to implement this. You just need to remove the Business viewer role from the user. This will be in one of the next patches.

Then the biggest challenge probably becomes if we can test synchronous interfaces on SAP PI/PO and instead of calling the remote system calls the Figaf system.

What is the security problems

The solution has some gaps, that could lead to giving to much information to a user. In this term, it is a good idea to be wair of this.

There are some trade-offs being made about the masking. There are some things that you are able to determine with it.

• Number of employees based on the XML or employees with a certain tag like fired
• Salary if it is 5 or 6 digits

If the mapping is using lookup then we are not caching lookups, so there may be performed a lookup to a remote system with information. If the receiver system is saving this it could cause some problems. We could put a check in the code to see if there are lookups and then block those requests.

With our approach, if you are able to logon to the SAP PI system you can bypass the restriction, but then you anyway have too much access.

Once the tests are running if someone is removing the IRT module then the messages may be delivered to the receiving system. I do though recommend to use the Figaf system to handle the transport then we can help eliminate this processing.

If you see more problems do let me know. 

Learn more

In the release, we have also added support for fetching messages from Dual Stack systems. Which is really useful for migration projects. We have tested that we can fetch messages from a 7.1 system, so that makes the migration process a lot easier.

You can view a video on the security flow at the release page. Here you can also signup for a free trial.

Updated 2020-02-21: Link to the new post on blocking with webdispatcher added.