Improved Error Handling in CyberArk AAM Connector (Agentless Mode)

Products Identity Manager Ideas
,
1

What is a one sentence summary of your feature request?

Enhance the CyberArk AAM connector to properly handle and expose non-JSON HTTP error responses (including status codes and raw messages) instead of masking them behind generic JSON parsing exceptions.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

Hello,

Following a recent analysis related to the use of the CyberArk AAM connector (agentless mode), an improvement opportunity has been identified regarding error handling.

:magnifying_glass_tilted_right: Context

While retrieving credentials through the connector, the following error was reported:

Unexpected character encountered while parsing value: <. Path ‘’, line 0, position 0.

After investigation, it appeared that:

  • The remote API was returning a non-JSON response (most likely an HTML page generated by a proxy or intermediary component).
  • The connector systematically attempts to deserialize the response as JSON.
  • When the response is not in the expected format, only a generic parsing exception (JsonReaderException) is raised.
  • The actual HTTP response content is not exposed in the logs.

This significantly complicates troubleshooting, especially in cases involving proxy configuration, firewall restrictions, network settings, or certificate issues.

:warning: Identified Issue

The connector currently:

  • Does not explicitly handle HTTP responses that are not in the expected JSON format.
  • Does not log the returned HTTP status code in error scenarios.
  • Masks the root cause behind a JSON deserialization exception.

:bullseye: Enhancement Request

We propose enhancing the connector so that:

  1. Non-JSON responses are detected before attempting deserialization.

  2. The returned HTTP status code is systematically logged.

  3. The raw response body (or a safe excerpt) is logged when an error occurs.

  4. Error messages clearly distinguish between:

  • JSON parsing errors,
  • network errors,
  • proxy-related errors,
  • authentication failures,
  • or functional errors returned by the remote provider.

:white_check_mark: Expected Benefits

  • Easier and faster troubleshooting of integration issues
  • Better visibility into infrastructure-related errors
  • Reduced support analysis time
  • Improved robustness and observability of the connector

Thank you in advance for reviewing this enhancement request.

How do you currently solve the challenges you have by not having this feature?

None.