RMI security policy

[polaris]

Hello everybody,

Im using RMI to connect java applet with a remote server.
The client looks up the server successfully but when I press
any button in the client applet interface which performs remote
method invocation this message is displayed in java console:

Exception in thread "AWT-EventQueue-23" java.lang.RuntimeException:
java.security.AccessControlException: access denied
(java.net.SocketPermission 10.0.0.2:4411 connect,resolve) at
ClientApplet$ButtonHandler.actionPerformed(ClientApplet.java:153)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)

I don't use any security policy to run the registry or in the server or
client.
This is the client look up code:
remoteReference = (RemoteInterface)
Naming.lookup("//localhost/"+RemoteInterface.REGISTRY_NAME);

and this is the server rebind code:
Naming.rebind(RemoteInterface.REGISTRY_NAME, remoteReference);

do i need to use any specific security policy or what?

 

[R]

May consider to use JAAS to create a subject to pass username password
to the server.

Or I use the following cod in my weblogic server:
private Context getInitialContext() throws NamingException
{
Hashtable h = new Hashtable();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
h.put(Context.PROVIDER_URL, "t3://"+ EAI_Server+ ":7001");
h.put(Context.SECURITY_PRINCIPAL, "username");
h.put(Context.SECURITY_CREDENTIALS, "password");
return new InitialContext(h);
}

main()
{
Context ctx = getInitialContext();
Object home = ctx.lookup("ejb.MyEJB");
}


Regards,
Ray,

 

[Andrew Thompson]

polaris wrote:
....

Im using RMI to connect java applet with a remote server.

Is the applet coming from the same 'remote server'?

do i need to use any specific security policy or what?

I did a quick Google and ..failed to confirm that
an untrusted Java apptet can do RMI back to it's
'home' server.

An applet that attempts RMI (or just about anything
else) on another server, would need to be trusted.

There are two ways to give trust to an applet, the first
is impractical for anything beyond testing, the second is
to sign the applet code and get the user to accept the
signed code.

Andrew T.

 

[EJP]

Hello everybody,

Im using RMI to connect java applet with a remote server.

This is the client look up code:
remoteReference = (RemoteInterface)
Naming.lookup("//localhost/"+RemoteInterface.REGISTRY_NAME);

If the server is remote why are you looking up the local RMI registry?

The only host an unsigned applet can connect to is the host the applet
was loaded from.

 

[Nigel Wade]

polaris wrote:
...

Is the applet coming from the same 'remote server'?


I did a quick Google and ..failed to confirm that
an untrusted Java apptet can do RMI back to it's
'home' server.

It can (or at least it used to be possible), I used to have an applet which did
that.

 

[polaris]

polaris wrote:
...

Is the applet coming from the same 'remote server'?

the applet is loaded locally in browser from the web server.
but before loading the applet, it should look up the remote
object in registry. After successful look up the loaded applet
can perfom remote invocation through the GUI buttons.
currntely the look up process is ok but the remote method
invocation which is launched thru applet buttons issues this error.

I did a quick Google and ..failed to confirm that
an untrusted Java apptet can do RMI back to it's
'home' server.

An applet that attempts RMI (or just about anything
else) on another server, would need to be trusted.

There are two ways to give trust to an applet, the first
is impractical for anything beyond testing, the second is
to sign the applet code and get the user to accept the
signed code.

from my weak background in singing the applet, i know
that it involves big user intervention which requires
good knowledge about accepting singed applet.
and this is will limit the application popularity.

 

[EJP]

I am still finding it impossible to believe that an unsigned applet
which is executing Naming.lookup("rmi://localhost/...") can possibly
succeed. There would have to be a Registry running in the same host as
the browser, which there isn't, and the security policy for an unsigned
applet would have to permit the applet to connect to 'localhost', which
it doesn't.

So, is this your real code?

 

[Andrew Thompson]

EJP wrote:
.....

So, is this your real code?

A very good question.

I meant to mention the other day, that your first post
looked like it cracked the basic problem - but forgot.

Andrew T.

 

[polaris]

EJP wrote:
....

Now Im running this code in my local host for testing and further
deployment will make
the server in different host. With this code the applet is displayed to
the user means
lookup("localhost,obj) succeeds successfully. In fact I was not able to
connect to the registry when the applet try to connect to localhost but
i did some changes and the connection has succeeded. the is the old
code:

Registry registry = LocateRegistry.getRegistry(getCodeBase().getHost(),
RemoteInterface.REGISTRY_PORT);
remoteReference = (RemoteInterface) registry
..lookup("//localhost/"+RemoteInterface.REGISTRY_NAME);

The differece is the Registry class which i was using in old version.
But when i remove
localhost from above code the connection will established correctly.
Really i don't
know why the connection is established with Naming class but not with
Registry but
at least that what is happening.
The problem now is the applet can't do remote method invocation to the
looked up object.
Now should i sign applet which may need end user intervention and is it
the only solution.

 

[EJP]

Registry registry = LocateRegistry.getRegistry(getCodeBase().getHost(),
RemoteInterface.REGISTRY_PORT);
remoteReference = (RemoteInterface) registry
.lookup("//localhost/"+RemoteInterface.REGISTRY_NAME);

Aha. When you use Naming.lookup/bind/rebind/unbind you have to supply a
URL so that Naming knows the host and port of the Registry you want to
search.

When you use Registry.lookup/bind/rebind/unbind, the host/port are
already known from when your LocateRegistry.getRegistry() call so you
*don't* supply a URL, just the binding name you are interested in. If
you *do* supply a complete URL, the Registry will be searched or bound
with that entire string. Cure: remove the hostname/port part.

Just bind and lookup with RemoteInterface.REGISTRY_NAME.

In fact I prefer to use RemoteInterface.class.getName(), because (a)
it's already there, and (b) it's package-structured so less likely to
cause a name clash.

 

[polaris]

Aha. When you use Naming.lookup/bind/rebind/unbind you have to supply a
URL so that Naming knows the host and port of the Registry you want to
search.

When you use Registry.lookup/bind/rebind/unbind, the host/port are
already known from when your LocateRegistry.getRegistry() call so you
*don't* supply a URL, just the binding name you are interested in. If
you *do* supply a complete URL, the Registry will be searched or bound
with that entire string. Cure: remove the hostname/port part.

Just bind and lookup with RemoteInterface.REGISTRY_NAME.

In fact I prefer to use RemoteInterface.class.getName(), because (a)
it's already there, and (b) it's package-structured so less likely to
cause a name clash.

ok now i understand the difference between Naming and Registry but
still the main question is not resolved: after successful remote object
look up, the remote method
invocation issues the following error:

Exception in thread "AWT-EventQueue-2" java.lang.RuntimeException:
java.security.AccessControlException: access denied
(java.net.SocketPermission ***.***.***.***:1432 connect,resolve)
at ClientApplet$ButtonHandler.actionPerformed(ClientApplet.java:156)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)

do u really need to sign up the applet which may need intensive end
user intervention
or there is another way to get over this problem?

 

[Andrew Thompson]

polaris wrote:
....

do u really need to sign up the applet which may need intensive end
user intervention

Nope. The 'intensive intervention' is the developer signing the
code. If the user is in a position to 'accept' trusted code,
it is as simple as clicking 'yes' at the right time.

or there is another way to get over this problem?

I am not yet convinced that you understand that if
the applet is being *served* from the same
'remote server', it does *not* need to be signed.
(According to Nigel's info., which rings true)

Can we visit this applet? Is it publicly available?

Are you uploading the applet to the server, and
downloading it from there? Do you know how to
flush the class cache of your browser?

Andrew T.