We'd have to test the behavior of the system if the token is
changed while the agent is connected. I *think* we check the token on ?> every message
we get from the (not sure about this) - if this is true, the agent will probably be stuck
receiving "unauthenticated" > errors until it switches to another server or
it is restarted.
I was trying it yesterday and it worked, I've tried the "get live button" on
the monitoring tab and there were no errors in the log event the token was invalidated. I
guess, it depends on the type of the communication between agent and server, I mean
availability report needs authentication for example.
2)
you are right Mazz, I just wanted to be sure about it.
3) Jay:
It may happen theoretically in the CoreServerServiceImpl.registerAgent() method. If two
different agents with the same name pass all the "iffs" and try to create new DB
record by calling agentManager.createAgent(agentByName). But I guess, there is a
constraint on the Agent table requiring the unique name, so Hibernate should protect it.
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Tuesday, December 18, 2012 3:15:13 PM
Subject: Re: Purging the agent's security token
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?
We'd have to test the behavior of the system if the token is changed while the agent
is connected. I *think* we check the token on every message we get from the (not sure
about this) - if this is true, the agent will probably be stuck receiving
"unauthenticated" errors until it switches to another server or it is
restarted.
I think it would be best that the user be told to shutdown the agent, unless the agent can
self-correct in this situation.
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).
It should be irrelevent if the agent's token is that special token - that is only
meaningful if coming from database. In other words, if the agent sends us @reset@, it will
fail to authenticate if the token in the DB is a real token (so that's good). It will
potentially pass authentication if the token in the DB is @reset@ - but 1) by the very
nature of the case, the user wants the agent to pass by the fact the user reset the token
and 2) the server code shouldn't get that far - once it sees @reset@, it will have to
generate a new token and send it back to the agent.
So, I don't see how someone setting the token on the agent to that @reset@ token would
help circumvent security. Unless I'm missing something.
3) Possible race condition when registering the different 2 agents
with the same name when the token is invalidated for this name.
don't know.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel