Chapter 2: Building the pgAdmin 4 dispatcher logic

The development of the pgAdmin 4 dispatcher was divided into 10 critical stages, each addressing a separate technical challenge.

Preventive execution environment isolation

One of the first technical barriers was library conflicts. PSM servers often maintain their own OpenSSL configurations, which may differ from the versions expected by pgAdmin. To eliminate instability risks, we implemented an environment sanitization stage: the script forcibly clears the OPENSSL_CONF and OPENSSL_MODULES environment variables immediately before launching the process. This ensures that the application runs in a “clean” environment using only its own verified components.

Dynamic interface waiting (PixelSearch)

Since pgAdmin’s web-rendering speed depends on server performance and current load, relying on fixed timeout delays (Sleep) would be a critical mistake. Instead, we implemented dynamic scanning logic. The script enters a waiting loop and uses the PixelSearch function to detect the appearance of specific colors at defined interface coordinates. Only after the system confirms that the interface is ready for interaction does it proceed to the next stage.

Action emulation and navigation

Navigation within the application window was implemented using a combination of hotkeys and context menus. Since we do not have direct access to buttons, the dispatcher simulates right-click actions within predefined interface zones to open the server registration menu, then executes complex sequences to navigate among the address, port, and credential fields.

Chapter 3: The hybrid DBeaver approach — CLI and UI

With DBeaver, we took a different approach by leveraging the command-line interface (CLI). However, even the presence of a CLI does not make development trivial.

Method combination

The DBeaver automation approach differed significantly from the pgAdmin case. The primary tool here became the command-line interface, but this decision was driven not only by the desire for stability — it was primarily dictated by strict security and session hygiene requirements.

With a standard “bare” launch, DBeaver attempts to save every new connection profile into the user’s local configuration by default. In a PSM environment, where a single server serves hundreds of users, this creates a serious risk: without additional controls, the next administrator could potentially see artifacts of previous connections — database names and server addresses.

Attempting to solve this problem solely through UI emulation (such as navigating settings menus to disable saving) would be unreliable. Java application interfaces often behave unpredictably, and even minor client-version updates can break the cleanup logic.

That is why we used CLI initialization, generating a complex launch string based on Vault data:

"name=" & $ConnectionName & "|driver=" & $Driver & "|host=" & $TargetAddress & ... & "|save=false|savePassword=true"

The key advantage of this approach lies in the use of specific flags, particularly save=false. This allowed us to:

As a result, CLI integration became the mechanism that enabled a level of security impossible to achieve through traditional UI emulation alone.

Handling “noisy” windows

DBeaver is a Java-based application that may generate numerous pop-up dialogs upon launch, such as update notifications, “tip of the day” messages, or database driver download prompts. Our dispatcher was designed to monitor these windows in real time. If a Driver settings window appears, the script automatically presses the Download button, waits for it to complete, and then proceeds with connection monitoring.

Chapter 4: The golden rule – verification and input control

One of the most important aspects of the project was the principle of controlled privilege handoff. In standard (less secure) systems, users can observe and interfere with the automation process, often causing errors or attempting to bypass security controls.

Input block

We implemented logic where the user remains a “viewer” throughout the entire login process. Using the Hardware Input Lock mechanism, CyberArk blocks keyboard and mouse interaction while the dispatcher is running. This guarantees that the automation sequence cannot be interrupted by accidental user input.

Connection success verification

The verification stage is the key part of the workflow. After the password is entered and “Enter” is pressed, the dispatcher does not immediately complete execution. Instead, it switches into success-monitoring mode.

Only after the system verifies a successful connection does the dispatcher send the PSMGenericClient_SendPID signal. This signal instructs CyberArk to:

This approach eliminates scenarios where users encounter an “Access Denied” window and attempt to manually enter passwords or modify connection settings.

Conclusion

Developing custom CyberArk connectors is the art of combining deep infrastructure expertise with strong engineering and programming skills. The pgAdmin 4 and DBeaver cases demonstrate that, even without official plugins, the CyberArk architecture enables organizations to build solutions that match the capabilities of native integrations in both security and usability.

Key lessons learned:

Building such systems requires not only CyberArk expertise, but also hands-on experience solving non-standard engineering challenges. The BAKOTECH team is ready to provide professional support in developing and implementing custom solutions of any complexity, helping you secure every corner of your IT infrastructure.