jnp+http[s] != invocation via http - bug ?

[elkner]

Hi,

just tried to tunnel jnps via ssh and found out, that it seems to have real security issues:

1) the initial context lookup is done via https, ok
2) but any consecutive ctx.lookup is done via plain http://{serveraddr}:80/...
3) every ejb3 invocation is done via a plain aka unencrypted socket://{serveraddr}:3873

So either jnps aka https aka jnp+https is totally bogus or its name is totally misleading :(

I already solved problem 2) incl. the [stupid] RMI behavior of returning always the server address instead of the actually used one (which makes tunneling possible without the need to fake a DNS server, use local NAT wrt. portmapping):

./varia/src/main/org/jboss/invocation/http/servlet/NamingFactoryServlet.java:
...
protected void processRequest(HttpServletRequest request, HttpServletResponse response) ... {
...
 InvocationContext ctx = ((ClientContainer) Proxy.getInvocationHandler(namingProxy)).getInvocationContext();
 String url = ((HttpInvokerProxy) ctx.getValue(InvocationKey.INVOKER)).getExternalURLValue();
 log.debug("rewriting {0}", url);
 int idx = url.indexOf(':');
 idx = url.indexOf('/',idx+3);
 url = request.getScheme() + "://" + request.getServerName() + ":"
 + request.getServerPort() + url.substring(idx);
 log.debug("new URL: {0}", url);
 ctx.setValue(InvocationKey.INVOKER, new HttpInvokerProxy(url));
 response.setContentType(RESPONSE_CONTENT_TYPE);
...
}

Unfortunately problem 3) is still unresolved: the JMXInvokerServlet always returns a StatelessRemoteProxy, whome's InvokerLocator is set to socket://${serveraddr}:3873 :(

And I'm not sure, where to tackle that problem. Actually I think, it must be possible to have a look at the request and if it comes in via http[s], it should be possible to set the uri to http[s]://request.getServerName()+ ":" + request.getServerPort() + /invoker/EJBInvokerServlet

Any hints, where one could start fixing it ?

[starksm64]

The ejb transport is independent of the naming service transport. The ejb remote binding being looked up has to be configured to use ssl.

[elkner]

The ejb transport is independent of the naming service transport.

OK, but it is involved/used to create the InvokerLocation for the ejb transport. That's what I wanna tweak wrt. the request.

The ejb remote binding being looked up has to be configured to use ssl.

Well, ssl or not is not really my point.

I assume, that I can make ejb3 transport service available via several transport mechanismen (at least that's my limited clue of Jboss remoting) and even by using the "default" servlet container via EJBInvokerServlet aka HttpInvoker.java. Is this correct ?

If so, my problem is simply to find a way to set or modify the InvokerLocation (which gets send back to the client) wrt. to the received request. So can you give me a hint, where it gets generated?

[starksm64]

Moved to the remoting forum. SSL is the point as your asking about having this requirement along two separate transport channels. If you can't find the config info for this in either the ejb3 or remoting docs raise a feature request to get this added.

http://labs.jboss.com/portal/jbossremoting/docs/index.html
http://docs.jboss.org/ejb3