Unexpected responses when "app_id" header key is capitalized

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.


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.


We've added logic to only set an "app_id" header when Basic Auth is used to avoid possible duplication.