Azeez, my main point was not about security and my bad for misleading u with the wrong example. The point I am trying to make is that the whole purpose of clustering is to keep a set of related nodes in a consistent state. My examples was more geared towards integrity and not security.
If u only remove state from one node and not on the anothers then u are going to have an inconsistent cluster. Consider the same example node A,B and C. If u logout from A and before any cleanup is run, what if your cluster goes down?? Now when the cluster comes back up and u are trying to recover. Now u have 2 nodes (B & C) which thinks the session is alive and one node (A) which thinks the session is dead. If u apply quorum the consensus in the cluster will be that the session is alive, which is totally wrong. Now u endup with an unreliable cluster. This may or may not do any harm , but this is beside the point. It's conceptually wrong!!!! In my previous example the point of confusion was "Now some other entity can point to Node B or C" which gave u the impression that it was a security breach. Lets say the client logs out, but for some reason retries some operation (after the session destroyed) due to a bug in the client code and if the requests gets routed to Node B or C it will continue to work. Even though these are rare events these things should be prevented. And if there is a security breach then it should be plugged no matter how small it is. Yes we don't rely on this for security and yes we want WS-Security ..etc, but still it's a loop hole and it should be closed. It's not an excuse to have something conceptually wrong for the sake of performance. When u try to deploy this at a bank etc, this will fail a security audit. These people are paranoid and will require u to close every loop hole they see no matter how big or small they are. I am telling this through experience. Also what about this point? "Further any cleanup associated with the lifecycle of the session (ex resource release) will not be executed on Node B and C." Why are we holding on to resource when they are not needed? Sometimes the performance savings that u are suggesting will come at a greater cost than u think. We need to look at the bigger picture and we shouldn't compromise integrity/reliability etc for performance. whats the purpose of having clustering if your cluster is inconsistent? Regards, Rajith On 6/4/07, Afkham Azeez <[EMAIL PROTECTED]> wrote:
On 6/2/07, Rajith Attapattu <[EMAIL PROTECTED]> 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. > Rajith>> 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 requirement. -- Thanks Afkham Azeez http://www.wso2.org GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
