This approach may pose some security concerns, because theoretically anyone could send a query to the agent process and obtain the readings. There are several possible solutions to this problem. One would be to use some sort of authentication mechanism whereby the requestor identifies itself and the agent responds only to the authorized parties. Another approach, much simpler to implement, is to decouple the request-response dialog into two distinct parts: the request or command phase and the response, which in fact is the action initiated by the agent component.
Therefore, we're not going to enforce any restrictions on who can connect and send requests for actions to the agents. That would add another layer of security, but it would bring some complications as well. If you're interested in improving the security model, you may want to consider adding a two-way SSL certificate, so only the applications that possess the SSL key and have their key deployed on the agent can connect.
When the command is transmitted, the agent will respond with the default confirmation message, saying that the command is accepted and terminate the session. It will then go and perform all the actions that are associated with the received command.
If the action implies that a connection has to be made to a central server, the agent will use server details that are stored locally in the configuration file. This ensures that only the registered and trusted parties will receive the data.
To keep track of all commands, the server stamps each command with a ticket number and sends it along with the command request. When the agent finishes processing the command and sends the results back, it will include the same ticket number in the response. This mechanism serves two purposes. First, the server knows what has been requested and from whom, so it minimizes the data that needs to be transferred. It also acts as an additional security mechanism, whereby only the responses with valid tickets are accepted, so no one will be able to inject wrong data into the master server without knowing the ticket numbers.
Was this article helpful?