On 12/18/2012 8:49 AM, Jiri Kremser wrote:
Hi,
I would like to implement this feature Jay originally proposed. The idea is that it
should be possible, for the authorized user (MANAGE_SECURITY), to invalidate an existing
security token for any reason (mostly agent/db upgrade). Invalidating the token means
setting its value to something like @#$reset$#@, and storing it to the DB for an agent
with name "A". Next time the agent "A" tries to register, server finds
out the token in the DB is willing to be updated with the agent's actual token. And
stores it into DB instead of temporary marker "@#$reset$#@".
There are still some questions to discuss:
1) When clicking on the button for purging the existing token, should be the agent
disconnected/reconnected or is it ok to continue in this quite undef state?
I would
guess that if a reset is necessary it is because the agent can't
connect in the first place. But, if the agent were connected I think
the reset could take place anyway.
2) Are there any edge cases in this approach? For instance if
attacker provides -Drhq.agent.security-token=@#$reset$#@ on purpose (this can be easily
handled).
I'm not sure I understand the need for system property to be involved
in
this workflow. The reset mechanism can be internal, I think.
3) Possible race condition when registering the different 2 agents with the same name
when the token is invalidated for this name.
..
Here is the BZ for it
https://bugzilla.redhat.com/show_bug.cgi?id=888016 I
don't think this is an issue. The first to register should succeed,
the second should fail, not unlike standard agent-token storage.
JK
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel