I work about swing clients connecting ejbs.
I invoke my ejb over the internet without rmi.
I use remoting (proposed by bright side framework) : Http invocation
maybe I answer to your question
As far as I know, invoking through HTTP is just tunneling RMI.
Whether you're sending the data over RMI directly to the server or sending it over http to the server makes little difference from a security point of view.
Both times, an attacker may send arbitrary untrusted data right inside JBoss. Certainly the HTTP invoker does not check the data that it passes along to the inner parts of JBoss.
in fact client have only a reference of ejb.
I send jndi name to a servlet which calls ejb and send to client a reference. Just that..
About security point of view I don't know...
The only benefit tunnelling over http gives you is that there is a mechanism for connection level security. RMI does not have such an option by default, but you can do it yourself using custom client/server socket factories. I'm personally not a fan of shoving everything over http simply because that is the only port open.
One poster noted that you can obtain a CMP data source via JNDI (1099). A reply noted that you can secure it with a SecurityManager, but I'm not sure I understand how this works with remote connections. Until I fully undestand how to implement container security across a remote connection, I consider 1099 something to be firewalled.
Even if you can secure your EJB API (which I already did with tokenized security) and secure the data source with container security, what about the default JBoss features of JNDI? What about undocumented or rarely understood queries?
I think we need a comprehensive guide to securing JBoss, particularly JNDI/RMI.
so we switched over to HTTP-based JNDI which seems to work as ports 1099 and 1098 (RmiPort) are not used any longer.
But the actual data communication seems to go over port 4444 still!
Any ideas why this is so?
Your are looking up the stub over HTTP. But your bean is still configured using the standard RMI invoker.
Thank you all.
Now we have everything running over HTTP plus the HTTP invoker servlet is secured properly.