Bug 888016 - RFE: Purging the agent's security token from UI
RFE: Purging the agent's security token from UI
Product: RHQ Project
Classification: Other
Component: Agent, Core UI (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: Jirka Kremser
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2012-12-17 15:21 EST by Jirka Kremser
Modified: 2013-01-14 07:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-01-14 07:42:00 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jirka Kremser 2012-12-17 15:21:03 EST
Providing the security token by passing the "-Drhq.agent.security-token=<your token>" parameter when running the agent is not very convenient. The authorized user should be able to reset the token in the DB to some predefined value from UI. It is a marker for the agent, and if the agent with the same name is trying to connect to the server, and the token in the DB is now set to the predefined value, it should take the agent's token (not the one in the DB) and put it to the DB and allow the registration.

Just for sure, there is some simple use case:
1. User reinstalled/updated agent and my security token is no valid anymore

2. User logs in to the RHQ as a user in role with MANAGE_SECURITY permission

3. On Administration -> Agents -> "Agent's detail view", click on purge token icon (it is not there yet)

4. User runs the agent again

5. Server allows to register to the first agent who tries to connect and has the same name and in the DB there is some predefined value in the row rhq_agent.agenttoken

6. The agent's token is persisted into DB

7. If other agent with the same name tries to register, the row in the DB now contains the real agent's token, so it will be refused if the token differs.

Version-Release number of selected component (if applicable):

How reproducible:

Related to bug 782612
Comment 1 Larry O'Leary 2013-01-07 14:02:51 EST
For security reasons I think what is described here is too risky. The window of opportunity for a malicious act is too large.

Instead, the token should be passed into the agent using the existing (or an enhanced version of the existing) method. Which is to pass the new token into the agent manually during agent startup. Because this scenario should not happen under normal circumstances, a manual copy and paste of the token as found from the admin page of the server UI should be sufficient. This process would only be needed in the event that the existing agent's inventory is to be retained. 

In the more normal case of re-installing an agent during development, simply purging the agent's inventory from the server is sufficient to cause a 're-registration' of a new installed or re-installed agent--again, assuming the inventory for the affected agent does not need to be kept.

Note You need to log in before you can comment on or make changes to this bug.