Hot Topic - Remote Agents or Agentless

Reliable, secure connectors to managed systems are an important basis for the successful operation of Security Provisioning and Identity Management solutions.
When discussing possible connector architectures, the question arises as to whether remote agents on the target platforms should be used, or if other, agentless types of connections are to be preferred.
SAM Jupiter takes an undogmatic approach and supports agents, gateways or agentless connections depending on functional needs, security and available communications channels.

The Situation
To connect with target systems, Identity Management (IdM) solutions try to rely as much as possible on the standard interfaces or APIs that the target systems are offering.
For some systems, a small agent program residing on the target platform is technically the only way of executing the necessary commands for that environment.
Other environments offer alternatives:

  • Some target systems (like LDAP directories) can be controlled to a certain extent without a proprietary agent.
  • A gateway server may be used as the single point of administration for target systems of one type.
  • Remote access, combined with techniques like screen scraping, can be used to interface with the remote platform.

These alternatives are sometimes marketed as an agentless approach.
At first sight, agentless may seem a very attractive technical approach to take. It promises lower maintenance costs, especially when a large number of target systems are involved.

Drawbacks and limitations of a pure agentless approach
However, the cost argument is not as significant as sometimes supposed, and there are serious drawbacks and limitations that the agentless approach imposes:

  • Functional Support: The richness of administrative functions which the administrator can use is sometimes rather limited when relying on agentless connectors
  • Number of target systems: For most system types, for example Windows domains or mainframe security systems, the number of target systems to be maintained is low. In these cases agent distribution requires no relevant effort.
  • Scalability: The option of using scripting technology in agentless connectors is unlikely to be truly robust in a large multi-platform environment and will not scale in a sustainable manner, especially in the case of bulk data processing.
  • Effort for software deployment and maintenance: agentless is not “effort-less”: Remote platforms have to be configured to enable communication. Tools have to be deployed and scripts have to be maintained.
  • Security: An agentless solution appears to be inherently less secure. Technologies like SSL or Secure Telnet have to be added, and additional firewall ports may have to be opened.

SAM Jupiter takes an undogmatic approach to agent technology.
In SAM Jupiter, the use of agents or agentless connectors depends on the specific target system architecture and its technical features and constraints. In SAM Jupiter, the functional principles (e.g., bi-directional synchronisation, transaction processing) are the same for both approaches.
The following criteria form the basis for the choice of connection type:

  • Type of interface(s) which the target system offers and the functional support of the interface.
  • The possibility to use a single gateway offered by the target system vendor for a secure connection to multiple target system instances.
  • Available communication protocols, their performance and security features.
  • Number of target system instances usually deployed in a company.