axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Afkham Azeez" <>
Subject Re: [Axis2] Clustering: No need for ContextManager contextAdded & contextRemoved methods
Date Mon, 04 Jun 2007 04:54:29 GMT
On 6/2/07, Rajith Attapattu <> wrote:Azeez>>

> Similarly, there is a cleanup mechanism which runs whenever a new contexts
> gets added. Hence there is no need to send out a removeContext message.


This is not good enough. We need to remove a context ASAP as soon as a
> client logs out. Consider this. Client logs into Node A and does some work.
> All information is replicated to Node B & C. The client logout from Node A.
> We don't replicate the remove command and no new contexts are added, hence
> no cleanup mechanism is executed.
> Now some other entity can point to Node B or C and continue the session as
> those contexts are still available in those nodes. Further any cleanup
> associated with the lifecycle of the session (ex resource release) will not
> be executed on Node B and C. These kind of situations will make the cluster
> unreliable.
>  We can't compromise integrity for the sake of performance. We need to
> achieve both without compromising each other.
What about the situation where a session has been created on behalf of a
client and this session is replicated, and the session is still active? A
malicious entity can get hold of the session id and connect to any node. In
Axis2, there are 2 types of sessions; soapsession & transportsession. In the
case of the soapsession, the session is tracked using the service group
context id in the addressing header. If proper security is not used, anybody
can capture this id and masquerade as the legitimate client. Similary, in
transportsession, the SessionContext is associated with the session
management mechanism of the transport. Even in such a case, if proper
security at the transport level is not used, a masquerading attack can take
place. My point is, removing the session from the nodes is not the solution
for securing the system. We must use WS-Security to properly handle this

Afkham Azeez
GPG Fingerprint: 643F C2AF EB78 F886 40C9  B2A2 4AE2 C887 665E 0760

View raw message