Develop Reference

Java Server and client/ RMI or Socket?

I'm developing a Desktop LAN base java server and client application
where a Client must login and also to pass some data to server.
assuming i have 10 clients that inserting record simultaneously to server.
which is the best approach in this kind of situation, should I use RMI for login and record insertion? or Sockets?
if sockets please provide a key idea for me to start with.
key points to consider
-Multithreading
-able to send back data on client

If you want to connect your server via internet (and/or firewalls) it is probably a hassle to do this with plain RMI. In the past I have used Java Simon for such tasks which is very easy to implement. However if you plan to support other clients than Java clients, then you should have a look at Apache Thrift or Google Protocoll Buffers

Writing a secure RMI server-client application

I'm writing a server-client application where communication is done over the internet and I have several questions and concerns regarding security. I have done some research and found some posts here useful, but I would like more information. Some related questions I read were:
Secure authentication of client over RMI
java rmi authentication & security. exportObject makes it public?
Is communication in java rmi secure?
I have 3 parts to consider:
Information exchanged between the client and the server.
Authentication of the client.
Exploiting a running RMI server (hacking etc.).
What I know:
RMI over SSL. Using SSL sockets instead of the default socket would encrypt all information passed between the client and the server. This includes the objects exchange and method calls.
Authentication using username/password combination over SSL before RMI connection has been established. To my understanding there was supposed to be a way to authenticate inside the RMI connection but it was voted down.
Not too sure what can or needs to be done here. I do know that you can't just write your own client and ask to connect to the server since you need an ObjectID and the remote interfaces. However, is it not possible to decompile the classes \ interfaces you need since they are sent in RMI anyway? I also saw this Youtube video [http://www.youtube.com/watch?v=otjllNaBxiw] while researching and it got me worried with how easy it is, although I don't know if the server was not setup correctly.
All in all, are there other security issues I need to consider in RMI over the internet? Am I missing a solution I need to look at? Is what I already know wrong?

Information exchanged between the client and the server.
RMI over SSL.
Authentication of the client.
Authentication of the client is done by SSL. You mean authorisation, which is 'relatively' easy. Define your own RMIServerSocketFactory that returns an ServerSocket override whose implAccept() method wraps the socket in an SSLSocket, to which you add a handshake listener and set needClientAuth to true on it (and clientMode to false). Your handshake listener should then get and check the client certificate from the SSLSession, to see if the identity it authenticates is authorised, and simply close the socket if non-authorised.
Authorising the server, in the client, is on the other hand baroquely complex. You really need the JERI API in Jini to do it properly.
Exploiting a running RMI server (hacking etc.).
I won't go so far as to say it's impossible, but it's extremely difficult, and there are several strong lines of defence. You need the ObjectID, which is random, and can be made securely random, and you need the classes. Classes and interfaces aren't sent in RMI unless you specifically enable it, and they are sent by a side channel that you can secure arbitrarily strongly, for example with two-way-authenticated HTTPS. So you can't get those. Then you need to get yourself authorised, which basically requires compromising the server. And if that's possible, anything is.

How to secure communication in client-server app?

I've got backend running on the tomcat server and client running in the browser. Application is built on Spring 3 MVC + Spring security framework. How to secure the communication ? Is there other option than just to set the server to be accessed only via HTTPS ? I've got no experience with this so it might be a stupid question, but will this affect my application and do I have to set something up in my app, when the server shall communicate with client via GET/POST request via https ?

It depends somewhat what you mean by "secure." If you want privacy, you must use TLS (SSL) as a transport.
If you're only concerned with authentication, then you have another option: Digest Authentication.
Digest Authentication allows the client (browser, usually) and the server to exchange authentication credentials in a secure manner without securing the entire communication. If you use Digest Authentication, then third parties can still:
See what data the client and server exchange
Insert themselves between the client and server and alter the exchange
What third parties cannot do is spoof the authentication or steal username/passwords in transit.
If that's not secure enough, you need TLS. You do not necessarily have to purchase a certificate. You can use OpenSSL to generate your own. This certificate will not automatically be trusted by browsers, however, so you can't really use it for public sites.
You will need to consult your server documentation for how to set up HTTPS or Digest Authentication, depending on which fits your needs.

Your application should not be affected by switching from HTTP to HTTPS, Tomcat handles this or maybe an Apache in front. It's important to understand, that HTTPS is a server-thing, not an application topic, because the client makes a connection to the server (Tomcat), not to your application. Check out the Tomcat documentation, it's pretty clear about how things work.
And, like the others said: From what you've said it's best to use HTTPS (TLS/SSL). Certificates are a bit frightning at the beginning, but it's worth to invest the time.

HTTPS is the (S)ecure form of HTTP, since you have an HTTP client server application I would certainly used HTTPS. All you need is to create an SSL certicate for your website and restrict access to your website to HTTPS only, then you are 99.99% secure.
Your certicate can be either commercial from Versign or equivalent or some open source engine.
for the clients nothing needs to be done to support HTTPS

Non-blocking SSL server using Thrift

Thrift provides several different non-blocking server models, like TNonblockingServer, THsHaServer, and TThreadedSelectorServer. But, I'd like to enable SSL on the server. It seems SSL only works on blocking servers in Thrift.
Anyone has any clues of a non-blocking SSL server in Thrift? Java example would be highly appreciated.

One alternative to worrying about SSL in your Java App is to stand up something like nginx (http://wiki.nginx.org/SSL-Offloader) as a reverse proxy.
This has the upside of your application not needing to care about SSL but does require one more layer in your stack.
Clients will connect to the nginx server instead of directly to your client and nginx will forward those connections to your Thrift server.
You don't necessarily need two different servers for this approach, just configure your Thrift server to only listen on localhost (127.0.0.1 for ipv4) and have nginx listen on your external interfaces and forward to localhost.
Edit: client -> server in last paragraph

Implementing a IM platform in Java

If creating an IM platform in Java, which would be a better way to implement communications between the clients and server?
I was thinking either RMI or just a socket connection...
Advice please,
Thanks

I would use straight socket connection, using a well known protocol such as XMPP. You can use a library (like smack) to avoid implementing the whole protocol yourself.
The main advantage of XMPP over RMI or your self-made protocol is that is a well established protocol used for exactly that purpose: IM.
Some chat services already using XMPP include Google Chat (GTALK) and Facebook.

I already did this using Smack API, using XMPP protocol.

CometD has been specifically designed for use cases such as Chatrooms. Differently from other protocols, it works over HTTP port 80, which means (nearly) no hassles with Firewalls.
Listen to a recent podcast with Greg Wilkins about the project, which goes into some details of issues with implementing Chatrooms and how it gets handled by CometD.
I believe there is a Java client for CometD if you need to have client on both sides of conversation (normally frontend is JavaScript).