Point taken. Thanks Azeez
On 6/5/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
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 >
-- Thanks Afkham Azeez http://www.wso2.org GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
