If you send access credentials via request headers, and don't use lower snake case for the app ID (e.g., you send "App_id" instead of "app_id"), you may not receive the expected fields in the response. This is due to how our DataPower fine grained authorization appliance identifies accounts with access to redacted fields.
Explanation:
While all field names should be case-insensitive (see RFC 9110, 5.1 Field Names), a current misconfiguration in the new gateway is causing a subtle problem when "App_id" is used rather then "app_id" when providing access credentials in the header.
Both gateways are configured to set an "app_id" request header when forwarding a request in order to support fine grained authorization for both header and Basic auth. If you're using headers for authentication the "app_id" is already there–this step is needed for when Basic auth is used. If you're using header auth and set the app_id header with capitalization that is not lower snake case (e.g., "App_id"), the upstream request will end up with both the "App_id" header you've included and the "app_id" the gateway added.
If the API you're calling is subject to data redaction, DataPower sees both "app_id" and "App_id" headers and consolidates them CSV style. So if you include a header "App_id: 12345678", the DataPower policy will use the value "12345678,12345678" as the app_id for data redaction identification purposes. Since this isn't the app_id configured for access, the response will follow the default redaction policy.
Resolution:
We've added logic to only set an "app_id" header when Basic Auth is used to avoid possible duplication.