> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > It seems to me that half of the Java world is using JMX for > some kind of > COP stuff, regardless the fact that they are exposed or not. Seems as > they regard JMX differently from what it was designed for. > > IT also seems that JBoss makes this assumption... or maybe I'm just > wrong. Does it make sene to make this distinction in the > interfaces at all?
If you even remotely care about security, yes. We all know that a completely secure system is the "Holy Grail" of enterprise systems, and it is only a theorhetical dream. However, by applying the principles of secure programming, it is ludicrous to expose any functionality that is not necessary to expose. You are only increasing the number of points where failure can occur. You need to design with a secure architecture in mind, IoC fulfills *part* of this role. You need to keep things inaccessible if there is no present need to make them accessible. You need to fail securely. Etc. etc. Software Development Magazine is doing a whole series on the topic, and they are in the middle of it right now. Nevertheless, when I see this whole-scale blind use of a technology without studying the ramifications of it makes me nervous. Consider the case of Java RMI--a proven case of insecure failure. The fact that it creates and recreates connections without authenticating the server (susceptible to Man in the Middle attacks) and will fall back to unencrypted communication when either the client or the server does not support encrypted RMI, makes it completely unusable for any application that is serious about security. The best compromise that I can tell you is only expose what you intend to expose, and provide an authentication layer if you cannot trust one that is part of the communication mechanism. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
