RMI - Design of the application

Hello,

i have created a Server-Client application with RMI. But there are many questions:

I want, that only clients could connect to the server who have authenticate at the server. By this reason i only bind the Login-Method at the registry. In the Login-Method i check the Name and Password. If the Login is OK then i return a reference of the "secure" methods.

Thats my code, how i try this (only the important parts):

This is the class with the methods i want protect:

publicclass MySaveMethodsImplextends java.rmi.server.UnicastRemoteObjectimplements MySaveMethods, Serializable{

public String sayHello(){

return"Hello, world!";

}

}

The interface to the class:

publicinterface MySaveMethodsextends Remote{

String sayHello()throws RemoteException;

}

This is the Login-class:

publicclass RemoteLoginImplextends java.rmi.server.UnicastRemoteObject

implements RemoteLogin, Serializable{

public MySaveMethodsImpl login(String Kennwort躡ergeben)

throws RemoteException{

MySaveMethodsImpl sm =null;

if (KennwortAmServer == Kennwort躡ergeben){

//Instanz der gesch黷zen Methoden zur點kgeben

sm =new MySaveMethodsImpl();

}

return sm;

}

}

The Login-Interface:

publicinterface RemoteLoginextends Remote

{

MySaveMethods login(String Kennwort躡ergeben)throws RemoteException;

}

This is the server, which only bind the Login-class at the registry:

publicclass Server{

public Server(){

try{

System.setSecurityManager(new RMISecurityManager());

//Registry starten und Objekt an Registry binden

RemoteLogin rl =new RemoteLoginImpl();

Registry registry = LocateRegistry.createRegistry(1099);

registry.bind("RemoteLoginService", rl);

System.err.println("Server ready");

}catch (Exception e){

System.err.println("Server exception: " + e.toString());

e.printStackTrace();

}

}

}

This is the client:

publicclass Clientimplements RemoteLogin{

publicstaticvoid main(String[] args){

try{

System.setSecurityManager(new RMISecurityManager());

Registry registry = LocateRegistry.getRegistry("192.168.0.2");

RemoteLogin stub =null;

stub = (RemoteLogin) registry.lookup("RemoteLoginService");

MySaveMethods server = stub.login("kennwort");

if (server !=null){

//Login am Server erfolgreich

server.sayHello();

}

}

I hope, i posted all the important parts of the code:)

Now the questions:

Can i be safe as houses, that the "secure" methods could only be called from clients who have logged in successfully. Or are there perhabs a posibility that the client could "create" a reference and call the secure methods. Or should i implement in every "secure" method a query, if the server knows the client? I hope you understand the problematic i have:)

More questions:

If the client has logged in successfully, i return a reference of the "secure" methods. When the "return sm" at the server has performed, does the server keep also the reference (i don磘 think so)? Or is the reference only at the client?

How can i detect at the server, which clients lost the connections and which still connected?

Questions about questions... Where can i find tutorials or more infos about such questions? Is there a very good book which everyone should read after a rudimental "RMI-Server-CLient application is standing"?

Best regards

cu

George

[6143 byte] By [soroscha] at [2007-11-27 8:31:05]
# 1

>MySaveMethodsImpl sm = null;

>if (KennwortAmServer == Kennwort躡ergeben) {

>//Instanz der gesch黷zen Methoden zur點kgeben

>sm = new MySaveMethodsImpl();

> }

>return sm;

This is OK, but I would have this throw an Exception of some kind rather than return null if the authentication fails.

> Can i be safe as houses, that the "secure" methods

> could only be called from clients who have logged in

> successfully.

Yes.

> Or are there perhabs a posibility that

> the client could "create" a reference and call the

> secure methods.

1 chance in 65536. You should set -Djava.rmi.server.randomIDs or whatever it's called at the server JVM to make triply sure of this.

Or should i implement in every

> "secure" method a query, if the server knows the

> client?

IMO it is unnecessary. If you really want to be sure, use SSL with needClientAuth=true.

> If the client has logged in successfully, i return a

> reference of the "secure" methods. When the "return

> sm" at the server has performed, does the server keep

> also the reference (i don磘 think so)? Or is the

> reference only at the client?

The server has an ObjectTable which maps exported servers to their stubs, so yes the server has a copy.

> How can i detect at the server, which clients lost

> the connections and which still connected?

Implement java.rmi.server.Unreferenced

> Questions about questions... Where can i find

> tutorials or more infos about such questions?

See the Javadoc/Guide to Features/RMI

> Is there a very good book which everyone should read

> after a rudimental "RMI-Server-CLient application is

> standing"?

Of course. My book ;-) http://www.telekinesis.com.au/wipv3_6/java.rmi.A21

ejpa at 2007-7-12 20:26:24 > top of Java-index,Core,Core APIs...
# 2

> > >MySaveMethodsImpl sm = null;

> >if (KennwortAmServer == Kennwort躡ergeben) {

>

> >//Instanz der gesch黷zen Methoden zur點kgeben

> >sm = new MySaveMethodsImpl();

> > }

> >return sm;

>

This is OK, but I would have this throw an

> Exception of some kind rather than return null if the

> authentication fails.

>

Can you please explain why i should throw an exception rather return null?

> Of course. My book ;-)

> http://www.telekinesis.com.au/wipv3_6/java.rmi.A21

Not bad:) Is this still informative for Java 1.5 or 1.6 (I hope so...)? Or would you perhaps actually write a revised book with the new features:) Or isn磘 this necessary because the main features haven磘 changed?

Thank you very much for your help.

cu

George

soroscha at 2007-7-12 20:26:24 > top of Java-index,Core,Core APIs...
# 3

> Can you please explain why i should throw an

> exception rather return null?

Because it forces the application to deal with the exception. Your way there is a distinct risk of a NullPointerException.

> Not bad:) Is this still informative for Java 1.5 or

> 1.6 (I hope so...)? Or would you perhaps actually

> write a revised book with the new features:) Or

> isn磘 this necessary because the main features

> haven磘 changed?

The main features have barely changed at all. There are a couple of new system properties and there is a new 'dynamic stubs' feature, that's it.

ejpa at 2007-7-12 20:26:24 > top of Java-index,Core,Core APIs...
# 4

> Can i be safe as houses, that the "secure" methods

> could only be called from clients who have logged

> in

> successfully.

>

> Yes.

>

> > Or are there perhabs a posibility that

> > the client could "create" a reference and call the

> > secure methods.

>

> 1 chance in 65536. You should set

> -Djava.rmi.server.randomIDs or whatever it's called

> at the server JVM to make triply sure of this.

First you say, that the "secure" methods are save. Then there is a chance of 1 to 65536 (trys or years? if trys then it is "quite easy" -or?). Can you please explain this to me, what do you mean? And what's the option "randomID" . Do you mean that the classes should have a unique serialVersionUID -something like that:

private static final long serialVersionUID = -3790762653917500433L;

soroscha at 2007-7-12 20:26:25 > top of Java-index,Core,Core APIs...
# 5

(a) 1 chance in 65536 and a lot of specialist programming would be required as well as access to the remote interface and the stub. No it isn't secure; yes it is safe within those limits. If you want security use SSL.

(b) No I don't mean serialVersionUID, I mean java.rmi.server.randomIDs. See http://java.sun.com/j2se/1.5.0/docs/guide/rmi/javarmiproperties.html.

ejpa at 2007-7-12 20:26:25 > top of Java-index,Core,Core APIs...
# 6

(a) 1 chance in Integer.MAX_VALUE actually, not 65536, and a lot of specialist programming would be required as well, also access to the remote interface and the stub. No it isn't secure; yes it is safe within those limits. If you want security use SSL.

(b) No I don't mean serialVersionUID, I mean java.rmi.server.randomIDs. See http://java.sun.com/j2se/1.5.0/docs/guide/rmi/javarmiproperties.html.

ejpa at 2007-7-12 20:26:25 > top of Java-index,Core,Core APIs...
# 7
Hello ejp,thank you very much for your help.Best regards and a beatifull day)cuGeorge
soroscha at 2007-7-12 20:26:25 > top of Java-index,Core,Core APIs...