So, I'm rolling-my-own Java-based application server (because Glassfish, et al, aren't for non-web-based apps), and, of course, encryption is an absolute must. So, I coded up a basic ssl solution using the standard SslRMIClientSocketFactory, and SSLRMIServerSocketFactory. So far, so good. I've got some other issues with it, though, such as permitting but not requiring use of client-side certificates (much as when you ssh into a system), but I am willing to consider that an exercise for another day.
However, along the way I noticed that since 2005 or so with the advent of "Java 5.0", we have apparently some help for using xinetd on 'nix based solutions. It appears to me that the "new" help in doing this is the ability to get the socket information "inherited" from a lower level, like xinetd - via System.inheritedChannel.
I figured I needed an example of using the encryption and xinetd together in an RMI solution and found a great writeup here The New RMI - or, at least, it would be great if it weren't that the example code that's supposed to accompany that article was missing. Bit rot, I guess. (Anybody have a copy?!) The example visible in the article is too incomplete, and the text relies on the fact you have the example code. Oh well. Simply, I don't quite get it - using System.inheritedChannel clearly isn't as simple as just plugging it into your existing RMI Registry-related code - you apparently have to create a socket factory, or maybe I just don't get it - hence, looking for an example.
So I went hunting. I found that the Apache folks did something similar, and it's described here RMI Service Exporter, however, it's using technology I'd rather avoid - SpringBeans, if you will. And, as it's a non-trivial example, frankly, I'm a bit lost on how I'd use that type of solution in my work.
I kept looking and found what at first blush looks like a great solution named InitializeRegistry, but it doesn't have any reference to SSL at all, and I get lost right off the bat. For example, it describes itself as:
Creates and exports a registry (using an inherited channel, if any, as specified below), and binds the specified name to the specified proxy in that registry.
My issues here are language. In particular, I'm not using a proxy, and even if I were, I don't know why that would matter. And I thought I bind objects to the RMI Registry, not just names. Perhaps if someone can just clear up what they're doing, this is a fine example...
Finally, I stumbled across a GREAT reply - one of the most awsome ever - right here on StackOverflow, talking about Java RMI, SSL, and compression. Compression doesn't play into my needs, but it's an illuminating discussion. Still, I don't see how it helps me understand how to use RMI with both SSL and xinetd at the same time...
Thank you.
UPDATE:
In response to EJP's proposed answer (for which I am grateful), I started with the InitializeRegistry.java example cited above. I updated the accept() method to read:
.
.
.
/* Here we wrapper our socket with SSLSocketFactory.createSocket()
Some open questions I have are whether the arguments to createSocket()
are all _inbound_ in nature. Here's the basic call:
SSLSocketFactory.createSocket(socket, host, port, auto-close);
I PRESUME args are for the REMOTE host, not "us?"
REMOTE: serverSocket.getInetAddress()
LOCAL: serverSocket.getLocalAddress()
REMOTE: serverSocket.getPort()
LOCAL: serverSocket.getLocalPort()
Who Knows about auto-close?! I'll try it and see if it works OK.
*/
boolean autoClose = true;
return (Socket)SSLSocketFactory.createSocket(serverSocket.accept(),
serverSocket.getInetAddress().getHostAddress(),
serverSocket.getLocalPort(),
autoClose).accept();
//return serverSocket.accept();
}
However, this code fails to compile, complaining that:
createSocket() can't be called from a static context - and I couldn't find any solution to that.accept()" - the second of the two.Removing the final .accept() gets the error count down to just the inability to use the "non-static method createSocket()" from the static context of this code. But when I try and remove "static" from the class, it falls all over the place, unable to use the ubiquitous "this" reference. OTOH, I'm not sure how to make SSLSocketFactory.createSocket() static!
...Is it safe to presume that the one accept() used to get access to the passed socket (!!) is sufficient and that the subsequent one I tried to include isn't needed? Hmmm...
I'd be happy to try it out and see if only I could get it this built.
BTW, I would suppose I shold use setUseClientMode(false) at some later point... Yes?
THINKING FURTHER....
I realised that perhaps InitializeRegistry.java was a bad starting point, and went back to "first principals", found that perhaps it went astray when it first takes the channel it was given via System.inheritedChannel and converts it into a ServerSocket, so the idea of overriding ServerSocketFactory is, well, "a lot of work". And then it hit me:
The whole point here is to try and ensure an unsolicited connect request reaches a target that's listening. But more than that, there must be an object IN the registry for it to be useful, and for that, one needs whatever it is that creates that going, too. Therefore, it would be just as well, and easier, to ensure the code that creates the object is run as a SYSTEM SERVICE instead of worrying about solving this as a NETWORK SERVICE.
Thus, I'm punting. ...It seems a shame to delete the question, though, as this may provide guidance to someone else - it's the ONLY query in all of StackOverflow that touches on this subject.
Thanks again.
I can't see the point of the DelayedAcceptServerSocketFactory, that's just a bit of overkill, but the essential technique is as follows:
Write an RMIServerSocketFactory that returns an override of ServerSocket whose accept() method is overridden to delegate to the ServerSocket that came from the inherited channel.
Before that accept() method returns, wrap the accepted Socket in an SSLSocket, via SSLSocketFactory.createSocket(Socket, ...), and call setUseClientMode(false) on that socket.
Voila! Your RMI Registry now gets started by xinetd, and speaks SSL to your Registry clients. Assuming that's what you wanted, your clients can now lookup that registry, as long as they access it via LocateRegistry.getRegistry(host, port, csf).
Similarly, your servers can bind to it as long as they access it the same way.
Now, create your remote objects, using the SslRMI* socket factories, and bind them to the Registry as usual.
Done.